12 May 2009

Python’s hidden poisoned apple for GPL applications

I’d like to make people aware of something my colleague Daf pointed out to me: one cannot use Python‘s SSL code (this also applies to other Python projects such as M2Crypto) in a GPL licensed application because it uses OpenSSL.

The problem resides in OpenSSL’s license which requires :

3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
“This product includes cryptographic software written by
Eric Young (eay@cryptsoft.com)”
The word ‘cryptographic’ can be left out if the routines from the library
being used are not cryptographic related :-) .

and (because of its dual license)

3. All advertising materials mentioning features or use of this
software must display the following acknowledgment:
“This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)”

This requirement as been marked as GPL incompatible.  Therefore, any GPL application using it is in license violation. While the OpenSSL FAQ stipulates that you can use it with GPL applications, this opinion is not shared by everyone. This is a quite big unadvertised licensing problem.

Now, I am not a lawyer but I can point to some existing solutions to this problem:

  1. Fix Python to not use such a poisonous (to GPL) licensed library.
  2. Do not use Python’s SSL code and use other implementations such as python-gnutls.  This solution less appealing as replacement libraries often don’t completely cover python’s API.
  3. Relicense your GPL application to “GNU GPL  with the OpenSSL special
    exemption.” (as wget did) and add mentions to OpenSSL in your advertising materials. This solution is sometimes hard to implement as you have to contact all past contributors.

Comments (16)

  1. 12 May 2009
    A said...

    jUST PORT PYTHIN CRYPTO TO QCA2 -> http://delta.affinix.com/download/qca/2.0/

  2. 12 May 2009

    Doesn’t fall Python’s SSL code under this definition of the GPL?

    The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

  3. 12 May 2009
    Mark Wielaard said...

    Maybe it is possible to port to gnutls, which has a GPL-compatible license of course, and has a minimal openssl compatibility layer:
    http://www.gnu.org/software/gnutls/manual/gnutls.html#Compatibility-with-the-OpenSSL-library

  4. 12 May 2009
    Tester said...

    You can also use RedHat’s python-nss that is triple-license (GPL/LGPL/MPL) and so should be compatible with anything under the sun.

  5. 12 May 2009

    Or even anything under the Oracle, which is now a strict superset of anything under the Sun.
    (SCNR)

  6. 12 May 2009
    Simon said...

    I don’t see how this applies, because you’re not actually using OpenSSL yourself – you’re simply coding to Python’s SSL API. That the standard Python runtime uses OpenSSL to implement that API is nothing to do with you…

  7. 12 May 2009
    Patrick Morris said...

    This is a total non-issue for Python API users. If you use Python in your own code, you need to make sure you adhere to Python’s licensing requirements.

    If the guys who wrote the code you are using use OpenSSL, then yes, they need to make sure they’ve adhered to OpenSSL’s requirements, but that’s not your responsibility as a Python API user.

  8. 12 May 2009
    James Henstridge said...

    If you write an application from scratch using Python’s SSL module and license it under the GPL, you’re giving users an implicit permission to use the application with that module. Providing an explicit permission is nice but not required.

    The place where this does become a problem is if you want to integrate third party GPL code that hasn’t given you an explicit or implicit permission to link with OpenSSL.

  9. 12 May 2009

    [...] hidden poisoned apple for GPL applications http://ur1.ca/498e !gnu [...]

  10. 13 May 2009
    Holger said...

    In fact, this has nothing to do with Python, but applies to any program relying on OpenSSL, directly or indirectly.

    That hard thing about your third solution is that the licence exception is also required for any GPL’d code (or library) that you are using.

    This is a well know problem, and e.g. why the Debian project didn’t ship GnuCash with HBCI support for ages.

  11. 13 May 2009
    Some dude said...

    This fails so hard I don’t know what to say. Just because you use an SSL library doesn’t mean your code has to say, “Eric Young is a 1337 h4x0r”.

    Example. You write a networked multiplayer tetris-like game with little bombs that blow up blocks and paint buckets that really don’t do anything except make the game more colorful…ANYWAY you write this game in Python, and for some totally bizarre reason, you decide to use OpenSSL to encrypt the game data sent between the players.

    You can license this game, your creation, anyway you like. BSD, GPL, even a proprietary EULA, and you can (try) to make people pay for your game *even though it uses OpenSSL*. This is because your license covers the Python code you wrote, which only contains commands that direct the OpenSSL component to perform certain operations. Your work is not a derivative of OpenSSL.

    Try to learn something about how software components work together before you start banging out your blog posts.

  12. 14 May 2009
    blalajo said...

    GPL is incompatible with a lot licenses and this is by design! It’s even incompatible with a lot of free software licenses: CDDL, APL, MPL, the old Apache and others.

    So don’t complain! If you want to use the GPL as license suck up the consequences! GPL is the poison not the other licenses.

  13. 15 May 2009
    Np237 said...

    You can’t say the GPL vs. OpenSSL licensing issue is hidden. It’s one of the most common licensing issues. And it is not really related to Python, apart from the fact they choose to include this API in the default module set. This is true for any program that uses OpenSSL, regardless of the programming language.

    We should all be using NSS instead. That’s the most useful thing that ever came out of Netscape/Mozilla. It is more complete, more secure, and better thought-out than both OpenSSL and GnuTLS, and it has a permissive licensing scheme.

    @James: there’s nothing like implicit permissions when distributing code. If you don’t include a GPL exception for OpenSSL, distributors are doomed. This is not a problem for users who simply download the program from the developer, since only the GPL applies to the source. However, a binary package of that program that requires the OpenSSL runtime to work cannot be distributed.

    @Simon & Patrick: Bullshit. The licensing doesn’t apply to an API, it applies to a program. And in the end, everything that matters is the notion of derived works. A program using OpenSSL APIs is a derived work from OpenSSL, regardless of whether it is written in Python or in C.

  14. 21 May 2009

    [...] Pierre-Luc Beaudoin » Blog Archive » Python’s hidden poisoned … [...]

  15. 9 August 2009
    JanC said...

    Python applications are programmed to run on a Python VM, using an implementation of the Python standard library.

    Saying that a Python application that uses the secure socket features in the standard library depends on OpenSSL is only true if that application won’t work on other Python implementations that are not based on OpenSSL.

    (Some people seem to confuse python-the-language with cpython-the-implementation.)