It's Time to Fork the LGPL

July 17, 2003 9:17 PM

Update: Wow, it's Charles' big day for being wrong about stuff. See also A moment of Reflection

Not only did I misread LGPL Section 6 once, I then went back and misread it a second time, and then a third time. Honest, I used to be able to read legalese. I studied Law for three years. I wasn't doing to badly at it until it started boring me to tears and I stopped going to classes.

So, the FSF have decreed that when it comes to Java, making reference to an LGPL'd library will actually cause that library to virally infect your code with GPL-ness. The problem basically comes from the language of the LGPL: it was written with early binding languages in mind, so its application to a late-binding, message-passing language is quite a thorny legal problem.

The FSF's official view is really no surprise. If you look at the GNU site, the license is heavily deprecated, and in a typically RMS fit of pique has even had its name changed (from “Library GPL” to “Lesser GPL”) to make it clear it's Officially Frowned Upon. I can imagine that they relish any opportunity to move the meaning of the LGPL closer to that of the GPL.

The problem is that this runs totally counter to the expectations of the people who are actually using the licence. People choose the LGPL because it keeps the library ‘Free’, but allows people to use the library without the license infecting their client code1. This is a perfectly reasonable expectation, and it's stupid that the legal weasel words of the licence itself allow this to be the case for C programs but not for Java programs, merely because they have different compilation models.

What the FSF should do, is fix this bug in the LGPL. The standard LGPL copyright notice allows new versions of the licence to supersede old ones, so if the FSF were to do the right thing, this would retroactively fix the problem across the entire spectrum of Java LGPL code.

This is what the FSF should do, but I somehow doubt they will.

The obvious next step is to do the following:

  1. Find a friendly lawyer
  2. Have that lawyer draft a Java-friendly LGPL variant
  3. Have that variant approved as an Open Source licence
  4. Any Java project that wants to, can switch their code to the new licence that actually does what they thought the LGPL was doing in the first place

Step 4 might be a problem. Unless you have had all contributors transfer copyright in their contributions to the program's maintainer, (I can't find the URL any more, but I seem to remember that to do this in a watertight, legal fashion involves actual paper documentation being mailed around, which most projects dont' bother with) you legally have to get the explicit permission of every contributor to change the licence of the code. If you can't find them, you'd have to rewrite their modifications out of the codebase before you can re-licence. That's annoying.

1 And please, don't start a debate on GPL vs Apache Licence. It's irrelevant. If someone chooses a particular licence for themselves, we should respect their intent.

4 Comments

why re-invent the wheel?

there are several licenses that coudl be used..for example CPL for one..

It's worth noting that the GPL and LGPL are not themselves free (the licenses, that is). This is more to prevent tons of variants, I suspect. Your friendly lawyer will have to start from scratch, possibly using the (L)GPL as inspiration.

But like Fred says, why not choose from one of the dozens of already available, approved, well understood licenses that already exist?

It's a mind-share thing.

As far as licenses go, there's GPL, LGPL, BSD/Apache, and then "All those other ones we don't really know much about". I don't even know what the CPL is, and I've been following Free/Open Source software for almost a decade now.

Rather than just quietly moving projects to another less well-known licence, a particular licence needs to be visibly and widely annointed to be "That one which means exactly what we thought the LGPL meant". Or if one doesn't already exist that has that precise meaning, we need to make one to fill the suddenly-formed vacuum.

As you mention, it seems unlikely that the FSF would "fix" the LGPL for Java, because their mission is really that *all* software should be free.

By the way, it turns out that the LGPL does not actually infect your code with GPLness. There are just a few specific things that you need to allow for as per section 6 of the license. More here:
http://www.blueskyonmars.com/archives/2003_07_16.html#000938

I'm not sure how one would "visibly and widely" annoint some other license without just having projects switch to that license. If the OSI were to list "recommended" licenses for certain purposes, that might help people work through the quagmire. As Fred mentions, there are definitely good licenses in existence already.

BSD provides basically free access to do anything with the code.
Apache provides free access, but includes a clause requiring attribution.
The CPL (invented by IBM, this is the license for Eclipse and other tools) allows for commercial use and provides protection for the open source authors so that they don't get sued.
The Mozilla Public License has a provision that requires changes to the code that comes in the Mozilla package to be released under the MPL, but does not make any such requirements of code that uses the Mozilla code base.

My guess is that MPL-type licensing is what many open source library developers want... So, I wonder what the odds are that OSI could put together a well-researched page on this topic?

Comments are no longer being accepted for this blog entry. If you really want to make your voice heard, you can always email me.

Previously: Stack Overflow

Next: Meet Melvin