GPL, LGPL, and GHC Linking

Posted by Jon on May 18, 2011

Disclaimer: I am not a lawyer, and don’t really understand the low-level details of linking or copyright law. Do not consider this legal advice and use it at your own risk.

Spoiler: It turns out that the GNU General Public License licenses may require that developers of closed source applications, compiled with GHC and linked against a library licensed under one of the GPL licenses, to distribute their source code along with their software. I don’t know the probability that this is the case, but I personally wouldn’t take any chances if I were writing software that I wanted to be closed source. On the other hand, the majority of the people I have talked to believes that there is no such requirement.

The goal of this post is to summarize my understanding of the issue in a way that is easy to follow, and to open up for a discussion around the topic. Please let me know if you think something is wrong or unclear.

GPL and LGPL

The GNU General Public License (GPL) is the most widely used free and open source software license. Being a copyleft license, it stipulates that derived works of the software (such as software created by modifying the source code) will also have to be licensed under the GPL; copyleft ensures that the free software freedoms are preserved as the software evolves.

One common extension to the GPL license is the LGPL, the “Lesser” GPL. This license slightly modifies the GPL to allow proprietary (non-free) programs to be statically linked against the software, i.e. it allows the application binary to contain the library.

(Most people agree that proprietary programs may link dynamically (not containing the library) against GPL’ed libraries. However, the Free Software Foundation opposes this and states that dynamic linking produces a derivative work. For some different point of views on this topic, see the Linking and derived works section of the GPL Wikipedia article.)

C Linking

Let me start off by talking a little bit about how linking C programs works. Assume that we have a C library and a C application using that library. When the library (or any other binary) is built, is has an Application Binary Interface (ABI). This interface serves as the “glue” between the  library and other software; applications compiled against this library uses the ABI information for calling library functions, allocating memory, and so on. The nature of C ABI’s is that they are stable, which means that if you modify a piece of C software without changing things like the type and function signatures, the ABI would stay the same. This makes it possible for any user to modify a (free software) library, recompile it, and easily re-integrate it with the application.

The GPL licenses are designed to always give users the freedom to rebuild and re-integrate GPL/LGPL libraries. In order to comply with the LGPL, applications linked against LGPL libraries needs to fulfil one of the following criteria:

  • “Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.”
  • “Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user’s computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.”

Corresponding Application Code means “the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work”.

In order words: The application developers must release their source code (not necessarily as free software), link dynamically against the library in a way such that the application will work with a modified version of the library that is (application binary) interface compatible, or release the object code along with utilities that that allows the user to reproduce the application working with the new library. Most proprietary C application developers choose to go with the second or third approach in order to avoid to expose their code. Due to the stable nature of C ABI’s explained above, the typical shared library mechanism is clearly suitable and the object code (.o files) are easily used to reproduce the application.

The same most likely applies for the GPL, with the exception that the linking must be dynamic.

GHC Linking and the Grey Area

When GHC builds a (static or dynamic) binary, it does not produce a stable (or predictable) ABI; two given Haskell function of the same type (say Integer -> Integer) does not necessarily get the same binary interface. Even the exact same source code can get a different ABI every time you compile it. This means that if you’re using a closed source application and want to modify and relink one of its LGPL’ed libraries, you will most likely face an extremely difficult challenge.

The first option mentioned above (providing “Corresponding Application Code”) requires the object (.o) files to be distributed along with the application. It also requires that “any data and utility programs needed for reproducing the Combined Work” are included. Some people argue that a standard tools (like ld) is enough to fulfil this requirement. However, considering the difficulty of reproducing the work with these tools, some people feel that this violates the spirit of the LGPL and that some lawyers may look poorly upon that kind of reasoning.

The same thing is true for the the second option, where the program should “operate properly with a modified version of the Library that is interface-compatible with the Linked Version”. This may be interpreted like it is not the responsibility of the application developers to make this relinking process easy–the program should and will work fine against a library that is “interface-compatible”. Then again, getting an interface-compatible version of the modified library is almost impossible.

An additional layer of uncertainty is that different jurisdiction could have different rulings on how the license should be interpreted.

Final Words

Being able to relink applications is an important freedom, and it’s unfortunate that GHC cannot produce stable ABI’s to (realistically) enable users of (L)GPL’ed libraries to do this. Perhaps GHC could be extended to support stable ABI’s?

If you are considering to license your Haskell library under one of the GPL licenses, I recommend that you to think about what you want the restrictions to be in regards to these closed source applications, and add an exception to your license where you explicitly state whether or not application developers will need to distribute their source code along with their application. This will make sure that the license does what you are intending.

That’s all I had. Please let me know what you think in the comment area below! Finally, I would like to thank John Millikin and the #ghc IRC channel on FreeNode for helping me out in understanding these issues.

7 Responses to GPL, LGPL, and GHC Linking

  1. Will Thompson

    Most people agree that proprietary programs may link dynamically (not containing the library) against GPL’ed libraries.

    Really? I have never heard anyone claim anything this broad before, from free software hackers through lawyers at large corporations making use of free components under various licenses on embedded devices. I don’t think the Wikipedia article you cite really supports this assertion: Linus asserting that userspace applications are not derived works of the kernel is not the same thing at all.

  2. Kevin Jardine

    I am a bit puzzled sometimes by all the legal dance around the GPL. I agree that copyright (and copyleft) law can be complex, but surely the whole point of the GPL is to prevent open source software from being used by proprietary applications?

    People who license their code under the GPL do so because they don’t want their code to be used by non-open-source applications. I think that is a legitimate desire.

    In some cases a different license can be arranged. This often involves payment to the developer.

    If a developer doesn’t care how his/her code is used, he/she should use some other license.

  3. John Millikin

    Really? I have never heard anyone claim anything this broad before, from free software hackers through lawyers at large corporations making use of free components under various licenses on embedded devices. I don’t think the Wikipedia article you cite really supports this assertion: Linus asserting that userspace applications are not derived works of the kernel is not the same thing at all.

    The GPL is no different from any other copyright license, and you can reason about it the same way. Some people are confused or misinformed, so I like to clarify things by using a different (but for this purpose, equivalent) license — BSD 3.

    Lets say you’re writing a text editor, and you want to use a BSD3-licensed library “libsyntax” for syntax highlighting. Your application’s compiled binary dynamically links against /usr/lib/libsyntax.so.1. Do you think you are legally required to include libsyntax’s copyright headers in your application (eg, in the About menu)?

    If so, you hold a rather unusual position that an application can be a derived work of some library even if it doesn’t contain any portion of that library.

    If not, your beliefs are inconsistent.

  4. John P

    @John Millikin
    To what extent linking to a GPL’d library creates a derived work is not at all well tested in the courts (in any jurisdiction, never mind them all); it would be rather brave legal advice to allow your closed app to depend on a GPL library. It’s also abundantly clear that this is not the intent of the library creator who didn’t have to give you any permission to use their work in the first place; going against that is very unlikely to make you a lot of friends in the development community.

    Either way, relying on such an exception is only possible if you don’t intend to distribute any version of the GPL library with your application at all. Once you want any permission to copy or distribute the (L)GPL library then you need to to agree to the terms whether your code is legally a derived work or not. I think the position given in the post is a little misleading.

    There are cases where there is more than one implementation of an API under different licenses (such as with libedit and readline); now you can distribute your closed application dynamically linked with a non-GPL version, yet the user choice to link with the GPL’d version.

    Regarding the topic of GPL vs LGPL in the blog post: It is not so uncommon for propriety software to be written in scripting languages, where the source is of necessity distributed. There are even cases where source is supplied (or is available) for applications in more traditional compiled languages, usually in more specialist niches rather than mainstream commercial software — just because you have the source doesn’t mean you can ignore any proprietary license you’ve signed. In these cases it would be perfectly possible to make use of an LGPL library but not a GPL one.

    Another case is where you have haskell code under an open source, but GPL incompatible, license. You could combine and distribute such code with an LGPL library, whereas not a GPL one.

  5. John Millikin

    To what extent linking to a GPL’d library creates a derived work is not at all well tested in the courts (in any jurisdiction, never mind them all); it would be rather brave legal advice to allow your closed app to depend on a GPL library.

    This problem is not specific to the GPL, and it’s disingenuous to claim it is. Whether an application is a derived work of its does not depend at all on what licenses the libraries are published under. To be clear, if linking against a library’s public interface requires copyright permission from the library’s author, then every Linux distribution is committing infringement on a massive scale. I do not think there are any groups except the FSF who would push this claim.

    It’s also abundantly clear that this is not the intent of the library creator who didn’t have to give you any permission to use their work in the first place; going against that is very unlikely to make you a lot of friends in the development community.

    It’s a bit presumptuous of you to assume what the library creator intends, isn’t it? For example, I publish most of my software under the GPL, and my intent has never been to use false claims about it as a legal cudgel against other developers.

    Either way, relying on such an exception is only possible if you don’t intend to distribute any version of the GPL library with your application at all. Once you want any permission to copy or distribute the (L)GPL library then you need to to agree to the terms whether your code is legally a derived work or not. I think the position given in the post is a little misleading.

    It’s important to know what you need to comply with. If you distribute somebody’s GPL’d library along with your application, then the question of whether simple linking implies a derived work under copyright law becomes very important.

    For example, a proprietary software vendor might distribute their application with a set of plugins, one of which is licensed under the GPL. Most people would say that this is OK, so long as the source code to that plugin is distributed alongside (or as otherwise allowed). To think otherwise implies the application is a derived work of every plugin it ships with, which makes legal distribution practically impossible.

    Regarding the topic of GPL vs LGPL in the blog post: It is not so uncommon for propriety software to be written in scripting languages, where the source is of necessity distributed. There are even cases where source is supplied (or is available) for applications in more traditional compiled languages, usually in more specialist niches rather than mainstream commercial software — just because you have the source doesn’t mean you can ignore any proprietary license you’ve signed. In these cases it would be perfectly possible to make use of an LGPL library but not a GPL one.

    I can’t believe anybody would take this statement seriously. If any author seriously claims that using his GPL’d software in a proprietary script, I would happily host as many “infringing” scripts as I could. It is not in the Free Software community’s interest to spread fear about the GPL, and we ought to speak out against anybody trying to do so (no matter to which side they pretend to belong).

    Another case is where you have haskell code under an open source, but GPL incompatible, license. You could combine and distribute such code with an LGPL library, whereas not a GPL one.

    The only significant GPL-incompatible open-source license is four-clause BSD, which is also incompatible with the LGPL. It is possible that someone might create such a license, but I cannot think of any motivation to do so.

  6. John P

    It’s a bit presumptuous of you to assume what the library creator intends, isn’t it?

    Probably, but I do find it hard to believe that if someone is keen for their code to be used for propriety applications, that they would choose to publish it under GPL without any further clarification. Just because not everything might be enforceable by law (in any particular jurisdiction), it doesn’t stop the developer making their view of how they’d like people use their code known. It’s quite common for developers to include requests that are not legal licenses, nor enforceable (such as letting people know when they use code, or even sending them postcards).

    Anyway, it seems to me (given the abundance of other options) that publishing code under GPL is a fairly strong steer that you don’t wish it to be used in proprietary code. (Of course, that’s not the same as going around making Stallman-like comments, or threatening others where you don’t have a legal basis.)

    I have actually chosen python over haskell for a task due to your dbus libraries being GPL. Was I wrong? Were you expecting me to use your dbus library in non-open code? I am curious why you choose GPL3 for your code.

    If any author seriously claims that using his GPL’d software in a proprietary script, I would happily host as many “infringing” scripts as I could.

    Sorry, I guess this was unclear: I wasn’t referring to a closed application that calls a GPL tool in a bash script — I was merely noting that I have seen commercial software written in perl where (of necessity) the source does ship with the product. I.e. while not the norm, it’s not unheard of for proprietary vendors to provide source. Nothing more was intended.

    The only significant GPL-incompatible open-source license is four-clause BSD

    I was thinking of the problems with GPL2 and Apache (not about copyright interpretation, but patent clauses). That is resolved by GPL3, but there’s still plenty of GPL2 code around.

  7. John Millikin

    I have actually chosen python over haskell for a task due to your dbus libraries being GPL. Was I wrong? Were you expecting me to use your dbus library in non-open code? I am curious why you choose GPL3 for your code.

    This is somewhat tricky to answer, due to the current technical problems with GHC.

    As you can see from my posts, I am fine with proprietary applications dynamically linking against external libraries. This preserves the user’s control over their system, because they still have full control over the Free parts of their system. So in theory, linking a proprietary application against my GPL’d libraries is fine.

    Unfortunately, GHC’s current implementation breaks this because users cannot run existing binaries against modified libraries. Furthermore, based on my understanding of GHC’s optimizations, it is not possible for either the application or library developer to fix this.

    So I think that for the moment, using a GPL’d Haskell library in a proprietary Haskell program is not OK, but it’s purely a technical issue. IMO there’s no moral/ethical reason against it, and if/when GHC gains support for proper dynamic linking, I will strongly advocate its use.

    I was thinking of the problems with GPL2 and Apache (not about copyright interpretation, but patent clauses). That is resolved by GPL3, but there’s still plenty of GPL2 code around.

    Ah, yes, I’d forgotten about that problem. Fortunately, it only applies to code marked “GPL2 only”. Most GPL’d code I’ve seen has the “GPL2 or later” escape hatch, which can be used with Apache.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>