GPL, LGPL, and GHC Linking

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.

Categories: Haskell | Tags: , | 7 Comments