In this case, you will need to ask ffmpeg very closely why
they think linking to OpenSSL makes it "nonfree and
unredistributable", then run the result by your legal

In particular, you need to pay attention to:

1. The SSLeay and OpenSSL license clause that you cannot
redistribute OpenSSL under GPL, LGPL etc.

2. If ffmpeg is GPL or LGPL, and which version of same,
then get a copy of that license text for your legal

3. If any part of OpenSSL is linked into the same DLL or
EXE as ffpmpeg.

The situation sounds like it is much more complicated
than I initially thought.

On 5/25/2012 10:23 AM, Antti Peuhkurinen wrote:
Thanks for the information again.

If enabling OpenSSL usage on FFmpeg when configuring it, there is need
to enable also flag "non-free". This makes the configuration say:
"License: nonfree and unredistributable" and makes the legal guys bit
nervous here. When asking from #ffmpeg-devel about the redistribution,
their answer is to ask permission for redistribution from openssl

If I got your points right the "License: nonfree and
unredistributable" mentioned by FFmpeg is actually unnecessary and so
it's OK to redistribute the FFmpeg .so under LGPL when it uses the
OpenSSL .so from platform?


On Thu, May 24, 2012 at 8:09 PM, Jakob Bohm<>  wrote:
Since there is misinformation on this floating around, even in the FAQ itself, here are the GPL+OpenSSL, and LGPL+OpenSSL

1. Code under LGPL (any version) can link to OpenSSL with each of
  part (OpenSSL and the code under LGPL) remaining under its own
  license.  LGPL considers OpenSSL as "a program that uses the
  library".  This is why there is no problem linking OpenSSL to
  GNU libc (which is LGPL and/or GPL+general library exception).

2. Code under GPL plus a special exception (from the GPL) to allow
  linking to OpenSSL or other similarly licensed libraries, can
  link against OpenSSL.  Note that all the copyright holders on
  the specific code under GPL must agree to add the exception, and
  they cannot cut/paste code from other GPL projects that don't
  include the exception.

3. Code under GPL version 2 can be linked to OpenSSL only if both
  the following are true:

   A. OpenSSL is included "with the kernel, compiler or other major
     OS component"

   B. The GPL code is NOT included "with the kernel, compiler or
     other major OS component"

  This combination triggers the GPL rule about linking GPL to
  non-open-source libraries that might be part of an OS, such as
  the built in libraries on Windows or AIX.

  The OpenSSL FAQ has (or used to) have this backwards.

4. Code under GPL version 3 may have other options under some
  clauses of the GPL version 3 license, I have not studied this
  closely enough to know this.

(I am not a lawyer and this is not legal advice, you should read
the original license documents carefully, then ask a real lawyer
if you don't understand them completely).

On 5/24/2012 4:31 PM, Antti Peuhkurinen wrote:

Binary we include from FFmpeg uses OpenSSL's .so and so FFmpeg can't
be "just" LGPL anymore. Seems that many programs having this case list
FFmpeg with LGPL license without any clause and list OpenSSL
separately with OpenSSL's license. Might be that we do the same :)


On Wed, May 23, 2012 at 6:22 PM, Jakob Bohm<>    wrote:
On 5/23/2012 4:47 PM, Antti Peuhkurinen wrote:

I am using both FFmpeg and OpenSSL in my project (FFmpeg uses
openssl's .so on Android platform). Which kind of license text should
be put to marketing etc. material? Is "This software is using FFmpeg
<LINK>      and OpenSSL<LINK>" enough?

For ffmpeg I have no idea.

For OpenSSL, the OpenSSL license contains 3 very specific sentences
that you need to copy verbatim, even though they all sound similar.
You typically need to use all 3 statements. No link is required I
think, though in our product we do link to  We also
duplicate the full two-part license text in an appendix to the
form of the acknowledgements included with the product, as that
seems to be required too.


Jakob Bohm, CIO, Partner, WiseMo A/S.
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.

WiseMo - Remote Service Management for PCs, Phones and Embedded

OpenSSL Project                       
User Support Mailing List          
Automated List Manager                 

Jakob Bohm, CIO, partner, WiseMo A/S.
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 <call:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
OpenSSL Project                       
User Support Mailing List          
Automated List Manager                 

Reply via email to