#46700: ffmpeg: add openssl variant --------------------------+---------------------- Reporter: eirnym@… | Owner: devans@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: ffmpeg | --------------------------+---------------------- Changes (by mf2k@…): * owner: macports-tickets@… => devans@… * cc: devans@…, openmaintainer (removed) Comment: Please do not Cc openmaintainer because it is [wiki:MacPortsDevelopers#special not a valid email address]. -- Ticket URL: <https://trac.macports.org/ticket/46700#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X

#46700: ffmpeg: add openssl variant --------------------------+---------------------- Reporter: eirnym@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: ffmpeg | --------------------------+---------------------- Comment (by devans@…): I'm not sure why you want to do this. OpenSSL is considered a second choice for a couple of features due to its (nonfree) license restrictions. Because of this any +openssl variant would require the +nonfree variant as well (enforced in ffmpeg's configure). Features involved are * tls protocol -- ffmpeg can use either gnutls or openssl for this, currently configured using gnutls. * rtmpe protocol -- ffmpeg has two versions of this, one using openssl (ffrtmpcrypt) and one using librtmp (rtmp*). Currently the openssl version is disabled and the librtmp version can be activated using existing variant +librtmp. So I don't see that using openssl would add any functionality and it definitely adds licensing restrictions that do not come into play if gnutls and librtmp are used instead. But maybe I'm wrong. What advantage do you see? -- Ticket URL: <https://trac.macports.org/ticket/46700#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X

#46700: ffmpeg: add openssl variant --------------------------+---------------------- Reporter: eirnym@… | Owner: devans@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: wontfix | Keywords: Port: ffmpeg | --------------------------+---------------------- Changes (by devans@…): * status: assigned => closed * resolution: => wontfix Comment: Replying to [comment:5 eirnym@…]:

The rtmpdump depends on OpenSSL with GPL-2+ licence, so linking with OpenSSL doesn't add any restrictions for ffmpeg itself.

The ffmpeg developers don't agree with you: they consider OpenSSL to have a nonfree license. This is reflected in their configuration file. {{{ enabled gpl && die_license_disabled_gpl nonfree openssl }}} which causes configure to die with the following message if --enable- openssl is asserted without --enable-nonfree. {{{ openssl is incompatible with the gpl and --enable-free is not specified. }}} MacPorts generally agrees with this unless a specific exception has been granted by OpenSSL and refuses to distribute binary archives of ports if GPL is combined with OpenSSL.

I know people who want licence purity on their systems and they don't

want OS on their computers like Mac OS X or *BSD. Since most of ffmpeg is GPL licensed, adding OpenSSL decreases license purity rather than increasing it. The ffmpeg port supports Darwin which may or may not include Mac OS X.

I don't want to build anything which duplicates functionality if it

possible: I don't like GnuTLS when it possible to replace it with OpenSSL, I don't like build SVN client if I we don't need to link with SVN libraries, etc. In this case, MacPorts, as it stands, probably doesn't meet your expectations but you are welcome to modify ports as you like for your own use. I'm going to pass on this request for the reasons stated above: for ffmpeg, as a whole, openssl complicates rather than simplifies licensing issues and adds no additional functionality over gnutls and librtmp. -- Ticket URL: <https://trac.macports.org/ticket/46700#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X