New LGPL should work with Java

The first discussion draft of LGPLv3 was recently released to little fanfare. It should finally put to rest the uncertainties of using LGPL for Java libraries. But as always, you should make sure you agree with all the provisions and agendas of a license (and its steward) before applying it to your own code.
Written by Ed Burnette, Contributor

In all the fanfare accompanying the 2nd draft of the GNU Public License version 3, one might have overlooked the release of the 1st discussion draft of its little brother, the "Lesser" GPL, or LGPL version 3. Originally called the "Library" GPL, LGPL is important to open source developers because of its pragmatic approach. The key is LGPL section 4 which says:

You may copy and convey a Combined Work under any terms of your choice that, taken together, effectively do not prohibit modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications...

In other words, LGPL code can be combined with code using any other license, whether free, open, or proprietary. Unlike LGPLv2, this version makes it very clear that linking or combining in any way is allowed. This should finally put to rest the uncertainties of using LGPL for Java libraries.

This draft also exempts LGPL code from the DRM provisions of GPL section 3. However LGPL code would still be subject to the controversial encryption key provisions of GPL section 1 (the ones Linus is objecting to). This might preclude using LGPL code in a locked down device like a cell phone, voting machine, or cable modem.

When selecting a license, I think it's important to keep in mind the motivations of the license steward, in this case the Free Software Foundation. For example, in a 1999 article called "Why you shouldn't use the LGPL for your next Library", Richard Stallman wrote:

"Proprietary software developers have the advantage of money; free software developers need to make advantages for each other. Using the ordinary GPL for a library gives free software developers an advantage over proprietary developers: a library that they can use, while proprietary developers cannot use it."

By way of disclaimer, I should note that I write proprietary software at my day job, though I do try to encourage the use of and contribution to open source whenever I can. But if you're like me and you don't care so much about the FSF's political activism in this area, you might want to consider a different license like EPL or ASF. See my previous articles on open source licenses for more information.

Editorial standards