ffmpeg: add openssl variant

[eirnym (Eir Nym)]

ffmpeg can be linked with GnuTLS and OpenSSL libraries. this path add this variant.

[eirnym (Eir Nym)]

Same patch can be applied to ffmpeg-devel. I'll fill another ticket if you need this.

[mf2k (Frank Schima)]

Please do not Cc openmaintainer because it is not a valid email address.

[dbevans (David B. Evans)]

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?

[eirnym (Eir Nym)]

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

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.

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.

[dbevans (David B. Evans)]

Replying to 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.

[eirnym (Eir Nym)]

Sorry for some delay, but I've found some information about licences. To have less conflicts I also updated patch to require nonfree variant.

You can read following pages:

• ​https://people.gnome.org/~markmc/openssl-and-the-gpl.html (2004 year)
• ​https://github.com/JulyIGHOR/QtBitcoinTrader/issues/27 (2013 year)

[eirnym (Eir Nym)]

Require nonfree variant for openssl

[mascguy (Christopher Nielsen)]

Reassign ffmpeg-related tickets to Jeremy

[eirnym (Eir Nym)]

is there any chance to accept it?