Rich Unger's Blog

Sun's inconsistent attitude towards the LGPL

Man, I feel like I've done nothing but complain on this blog lately! I promise, I'll get back to posting netbeans RCP coding tips and stuff.

However, John Reynolds posted a link to an article inviting comments on Sun's OSS strategy. I couldn't resist sending along one of my little pet peeves...

Mr. Phipps:

I saw your invitation to comment to this email address on John 
Reynolds' blog.  There is one aspect of Sun's OSS strategy 
that's been particularly bothersome to me and others on the 
NetBeans project.


Lots of stuff done by Sun employees and posted to java.net are 
LGPL'ed.  Examples include SwingLabs, JDIC, and the SwingWorker 
backport to JDK 1.4.  Presumably, the intention is to allow other 
projects to use these libraries (both OSS and proprietary), while 
forcing back any improvements into the library.


It doesn't work.


Both proprietary software companies and many OSS projects 
(including NetBeans) won't touch LGPL'ed libraries.  Whether 
their concerns are valid or not (I think they are), we're left in 
the rediculous scenario where one Sun OSS project (NetBeans) 
cannot make use of other Sun OSS projects.


Sun Legal really needs to decide what it thinks of the LGPL.  It 
should either be eliminated in favor of the SPL or similar, or it 
should be allowed to be used by non-LGPL Sun projects across the 
board.


Thanks for listening :)

Cheers,
Rich Unger
NetBeans Governance Board

Comments

• Wow. You mean NetBeans will happily use whatever bizarrely licensed non-free jars someone can get their hands on, like Sun's JavaHelp and javac, but won't touch Sun's own open source LGPLd code !?
  That ... is ... fascinating ... in so many ways.
  Please take a chance to read through http://www.fsf.org/licensing/licenses/lgpl-java.html and the recent discussions on ASF's legal-discuss regarding the LGPL: the LGPL does not magically force people to license their own, independant source code or source code using the LGPLd library under sane source code licenses. The LGPL has been designed to draw a line behind which 'software hoarders' can do whatever they feel the need to do as long as they do not limit the freedoms on the LGPLd library.
  That's what *every* copyleft license does, btw, be it CDDL, SPL or LGPL.
  And before someone goes off in nutty ways ranting how the LGPL prohibts proprietary crap to be written, I'd like to point out that Sun's own J2SE implementation can (and presumeably does) include LGPLd software. See

  http://java.sun.com/j2se/1.5.0/J2SEv5.0.THIRDPARTYLICENSEREADME.R2.txt

  "%% The following software may be included in this
  product: Common Unix Printing System API Libraries
  (CUPS API library); Use of any of this software is
  governed by the terms of the license below:
  
  GNU LIBRARY GENERAL PUBLIC LICENSE TERMS AND
  CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
  ..."

  cheers,
  dalibor topic

  Posted by: robilad on August 19, 2005 at 12:40 PM

• Well, I think you're overstating the case a bit. javahelp and javac aren't "bizarrely licensed". Every java programmer on the planet has comingled their products with a similarly licensed library: the JRE.

  I'm well acquainted with the discussion around the LGPL and its usage with java code. My intention was not to spark off that discussion again, just to tell sun to make up its own mind one way or the other.

  To my mind, it doesn't matter that the FSF's position is that the LGPL is fine for java libraries. What matters is what the lawyers of all the entities creating and using such libraries think. If the consensus is that the LGPL is badly written and doesn't match the FSF's intentions, then it should be improved, or eschewed in favor of another license. Personally, I've read the license, and I think it's rather underspecified with respect to inheritence and other issues.

  Basically, I just want some consistency. I want to know where I stand when selecting OSS libraries for my work. And, I want the authors of such libraries to know, so they don't choose a license with one intention, and get a completely different response.

  LGPL authors want me to use their code, and I can't. That's the mismatch.

  Posted by: richunger on August 19, 2005 at 01:05 PM

• I'm guessing that as you've posted this here you're not too worried about using the confidential and anonymous Ombudsman process I'm establishing!

  Thanks for the input. One of my top priorities for the Open Source Office at Sun is to encourage license consistency and reduce the range of licenses in use. I'd personally want to see as many of Sun's libraries as possible use CDDL as that's equivalent to SPL and MPL but more modern, well-thought-out and compatible with almost all open source licenses including the Apache license, thus maximising opportunities for rework.

  As Dalibor points out, LGPL is actually not a license that should be feared by corporate legal advisors as much as it is. Its philosophy is still fundamentally project-based rather than file-based, though, so I hear those concerns and will take them into account.

  Posted by: webmink on August 20, 2005 at 02:57 AM

• People say 'Proprietary companies won't touch LGPL' like it is a bad thing - that is the whole point of LGPL i.e. to give the open source players an advantage.

  Even so MySQL is LGPL and it is when I last checked the most popular open source database - so it doesn't seem to harm uptake.

  As Sun own the LGPL copyright they can use their own LGPL code in netbeans, it just means that nothing non-sun can then be derived from the included LGPL stuff - which could indeed be problematic.

  Posted by: c_armstrong on August 22, 2005 at 06:06 AM

• If the author didn't want proprietary companies to make use of such libraries, they'd use the GPL. MySQL is GPL.And, while Sun could use LGPL code in netbeans, particulary code they own the copyright to, they don't. This is precisely my point. There's no consistency in the way the LGPL is interpreted, even within Sun.

  Posted by: richunger on August 22, 2005 at 07:53 AM

• You are right about MySQL - they changed from LGPL to GPL last year apparentlly.

  http://www.internetnews.com/dev-news/article.php/3358061

  I get the impression the issues between SwingLabs and Netbeans are more deeply political than just the license. Both teams seem to be looking for every excuse they can find not to work together. You are obviously better placed to judge that. Unifying the license would remove one excuse though.

  Posted by: c_armstrong on August 22, 2005 at 08:44 AM

• OK, so what license should we all be using, and more importantly what should my company and the Java Robotics community be using? Is there a good URL for a discussion of pros and cons of LGPL (my current favorite so far, but maybe this is just due to my ignorance). JBoss uses LGPL... can't we all just get along?

  Posted by: bboyes on August 22, 2005 at 09:48 PM

• c_armstrong: As I have a friend at Sun who works on JDNC/NetBeans integration, I'd say the cooperation between the two projects is pretty good. They demoed what they had so far at JavaOne, in fact. I'm not aware of any political rough edges, though admittedly I'm pretty green about such things.

  bboyes: It's not my intention here to choose sides. I'm no lawyer, though I have been convinced by one that there's enough ambiguity in the LGPL with respect to OO programming in general and Java in specific that convincing the industry at large that it's okay to use such libraries seems to me unlikely.
  There are several solutions, though. Folks could settle on one of the MPL-like licenses (SPL, CDDL, CPL, etc). The LGPL could be amended to address its current ambiguities.
  Also, I'm not running down the GPL. I firmly believe people should choose how to license their own code. I just wish it were easier to match the author's intent with the proper license. Something like what the Creative Commons folks did. They made it very clear what each license allows and disallows.
  Another example of where the current system falls down is JGraph. They've licensed different versions under several different licenses, and eventually settled on the LGPL. However, they also sell closed-source licenses, similar to the MySQL business model. They're essentially charging for JGraph, but only to companies with conservative legal departments :)
  Seems a strange business model to me.

  Posted by: richunger on August 23, 2005 at 12:02 AM

• You can only re-license a software if you have the right to do so. Does Sun have the right to re-license NetBeans or SwingLabs? Did all contributors, each and every one, grant Sun the right to re-license the software under a different license?

  If not, then forget it.

  Posted by: ewin on August 23, 2005 at 03:02 AM

• That's exactly what http://www.netbeans.org/about/legal/ca.html is for. Most organizations and companies that host large open source projects have such agreements.

  Posted by: richunger on August 23, 2005 at 10:28 AM

• c_armstrong: That I'm not working closely with the Netbeans team is a news to me! Rest assured, there are no political problems between SwingLabs and NetBeans; we work very closely together, have our priorities aligned, and are focused on one thing: making it easier for folks to write Java applications.

  Richard - SwingLabs Lead

  Posted by: rbair on August 23, 2005 at 01:07 PM

• rbair - indeed there does seem to be quite a lot of co-operation going on now - I haven't looked at the SwingLabs stuff since last October. So is the licence difference a problem or not - and if not then what point was richunger trying to make - what did he mean by 'And, while Sun could use LGPL code in netbeans, particulary code they own the copyright to, they don't'. - What has not been used that could/should have been?

  rbair - it seems you owe me that beer over the direction the data binding ended up taking....

  So if you've got netbeans/swinglabs sorted that just leaves JSR 227 ;)

  Posted by: c_armstrong on August 23, 2005 at 02:09 PM

• ooops - I'm out of date on JSR 227 as well - looks pretty dead huh?

  Posted by: c_armstrong on August 23, 2005 at 02:15 PM

• My understanding (any maybe it's incorrect) is that there will be some sort of re-licensing before any release is made that co-mingles netbeans and swinglabs.
  I do know for a fact that NetBeans won't ship a JGraph-based module because it is LGPL.

  Posted by: richunger on August 23, 2005 at 02:50 PM

• For a pretty obvious side effect of the bizarrities of BCL, see the need of the NetBeans build system to descramble the BCLd JARs and the requirement to click through a ton of license agreements. See also the whole "is NetBeans open source or what" confusion that has been going on for a while, largely due to people being confused by NetBeans IDE's current & unfortunate hard dependency on proprietary BCL-licensed software.
  Having re-read the LGPL, I think it suffers from the same problem that many other licenses, like Apache License 2.0 or the CDDL suffer: it tries to be too precise for its own good. In LGPL's case, it tries to explain things in the license (including code from header files, static linking), that would better be explained in a FAQ, like the GPL does it. Those explanations in the license using then state-of.-the art technology can confuse the heck out of people who are not familar with what header files or static linking are, in the first place. That's not too uncommon if one has learned to program using Java, and stuck to it.
  That does not mean that the LGPL is hard to apply for object oriented languages & use through inheritance, or that it suddendly turns into the 'oh so mean ;)' GPL when used for Java libraries. As Sun's legal deparment will probably confirm to you, if you take some time t ask, even though "every programmer on the planet" uses Sun's JRE using an Object Oriented programming language, which in turn includes an LGPLd component, acessible through inheritance, even, that does not make each and every program in Java magically forced to open up their source code.
  It would would be fun if the LGPL had such effect, as then Sun would be forced to release J2SE under an open source license today, rather than tomorrow, and all that funny stuff of dreams and nightmares, but .... that's not how the LGPL works.
  I've never seen the proponents of the funny "LGPL == GPL in Java" myth hasten to open up their proprietary source code to comply with what they believe is the effect of the LGPL, if they are using Sun's JRE, after all. It would be funny if they did, but somehow ... they'd seem to rationalize that mythical LGPL effect a bit differently, when it comes to their source code. Funny how rational people can be, when they have to. ;)

  The urban legend that LGPL somehow magically affects Java libraries in a different way from libraries in other programming languages, is rooted in a comment David made to an apache list, and then it got onto Slashdot, and then it took a life of his own.Sure, some lawyer may have said something to that effect to someone. I don't think that legendary legal analysis has ever been published, it's just hearsay, afaik.
  If you are following the OSI license-discuss and the Apache legal-discuss mailing lists, you'll notice that ocassionally, the quality of conclusions the lawyers there (and there are a few) debating software licenses reach can highly depend on the quality of information they have, and their familarity with the respective technology. Lawyers, like other humans, also can only give you "Garbage In, Garbage Out" if one gives them bad information.
  As for industry not accepting LGPL, I'd very much doubt that. Just about any major operating system vendor is selling GPLd and LGPLd software as part of the operating system offers, including Sun Microsystems and Apple. LGPLd software like Gnome is one of the selling points of the Java(TM) Desktop System. The two officially certified open source J2EE(TM) implementations, JBoss and JOnAS are both largely licensed under the LGPL. And so on, ad infinitum. The industry at large is, afaict, convinced that the LGPL draws a clear line, behind which it can do its proprietary things, if it desires so.
  Like any other copyleft license, say CDDL or MPL, the LGPL comes with the obligation to not remove the freedoms on the library, and to allow recepients to get the source code somehow. I'd guess that some companies prefer not to pass on those obligations to their customers, or prefer to keep their modifications of the libraries away from their customers. They can then pay the authors of, say, JGraph for that privilege.
  That would not be much different if JGraph was under CDDL, by the way: if those companies wanted to escape the effect of copyleft, and to take the code out of the commons, they'd still have to negotiate a separate license from the authors. Just like if Microsoft wanted to release a ClosedSolaris, and take their fork of the OpenSolaris code out of the commons, would have to negotiate a separate license with Sun. There is nothing really surprising or shocking to me about that.

  All copyleft licenses have such provisions. They differ in some details, of course. For example, as Simon said, the CDDL draws the line at at file level, where the LGPL draws the line at the library level. In practice, if you are just reusing a jar from a third party through inheritance, the effect is pretty much the same.
  The CDDL, being partly drafted around the need to release OpenSolaris under a Free Software license, also includes various explicit provisions for dealing with software patents. The LGPL otoh deals with patent usage rights in an implicit fashion. In practice, if you are reusing a jar from someone who does not own any software patents on the code, the effect is pretty much the same: no software patents, no problems.
  Dealing with patents in the CDDL explicitely was necessary for Sun, as contrary to your typical open source developer, say the FSF, or ASF, Sun actually has software patents. In order to make it possible for people to actually use OpenSolaris source code without infrnging on Sun's patents, Sun had to license their necessary software patents somehow. Rather than licensing the respective software patents for free use by anyone for any purpose for ever, Sun chose to give an explcit, limited patent grant, in order to try to form a patent commons around the CDDL, and to include a patent retaliation clause. The wording of the latter, afaik, is what makes the CDDL incompatible with the GPL.
  That's a big deal if you (or others) want to write GPLd software and be able to reuse your library. That's one advantage the LGPL has over some GPL-incompatible licenses.
  Whether that turns out fo be a big deal within Sun, will remain to be seen. While Sun publishes a lot of GPLd software, even in Java, the CDDL has just started to be applied for Sun's own software this year. Within after a few years, if Sun continues on the bold course to make their software availble either as Free Speech or as Free Beer, the GPLd Java projects will need to interact with GlassFish & friends somehow, and then a way will be found to fix that issue. I am sure Simon is aware of it, and I couldn't think of anyone better suited for that delicate task then webmink.

  cheers,
  dalibor topic

  Posted by: robilad on August 26, 2005 at 11:00 AM

• A few, maybe somewhat late, comments about JGraph.

  The JGraph business is not to do with licensing JGraph, it's about JGraph services and licensing products that build on JGraph. Providing a closed-source version of JGraph simply enables the closed-sourced product business.

  I'm curious about Netbeans refusing to ship modules based on JGraph because it's LGPL. For one, I had a phone call several months back from one of the Netbeans project managers asking for permission to use JGraph under the MPL license (specifically for a Netbeans module), I confirmed this in an email to them. The other thing is Java Studio Creator which ships with an LGPL cut of JGraph in it.

  I must say, I read far more about JGraph licensing in various blogs than is actually said directly to us. Just count yourself lucky I didn't get my way on JGraph 5.0, I wanted it GPLed.

  But really, if people actually connect us we're pretty flexible, if anyone would just talk to us directly.

  Posted by: bensond on October 09, 2005 at 12:43 PM

• I'm as mystified as you are. That was the whole point of this post. It's all a very weird state of affairs, and completely against your intentions with JGraph. For whatever reason, rational or not, the LGPL is very problematic for java libraries. I'm certainly not blaming you. And let me tell you, there are a lot of corporate lawyers who would accept that you have no intention to sue them and force them to open up their code, and they'll still not allow their engineers to use it. I don't like it any better than you do. I just wish we could do something about synching up licenses with author intent (both in the mind of end users and their corporate lawyers). Something like what creative commons has done.

  And as to Sun, your guess is as good as mine. I've heard a few things through the grapevine, and considering what you say here, there's obviously some disconnect somewhere. Clearly, they were off-put enough to make their own JGraph competitor, which they've used in the NetBeans Mobility pack, and are now releasing as a separate library.

  Don't blame me, I don't even work for Sun.

  Posted by: richunger on October 09, 2005 at 08:44 PM

• ...and, by the way, I love JGraph, and use it in V-Builder.

  Posted by: richunger on October 09, 2005 at 08:47 PM

• Interesting, do you know what the library is called / where it's available?

  Thanks, David

  Of course you love JGraph ;)

  Posted by: bensond on October 10, 2005 at 10:14 AM

• OK, I found it. Thanks for the pointer.

  Posted by: bensond on October 10, 2005 at 11:35 AM

This work is licensed under a Creative Commons License.