LGPL is Viral for Java

carlfish writes "According to this post to POI-dev, Dave Turner (Mr License) of the FSF has decreed that the steps required to use an LGPL'd Java library will actually infect client code with substantial GNU-ness via Section 6 of the LGPL. (The "Lesser" GPL is supposed to protect only the Library, without infecting code using the library) This, as you might imagine, puts a few LGPL Java projects that previously thought they were embeddable without being viral in a bit of a bind. Various weblogs have further coverage." Update: 07/18 02:44 GMT by CN : The FSF's Executive Director, Brad Kuhn adds "LGPL's S. 6 allows you to make new works that link with the LGPL'ed code, and license them any way you see fit. Only the LGPL'ed code itself must remain Free. Such 'client code' can even be proprietary; it need not be LGPL'ed."

Comments

Re:great, microsoft succeed again

[TheRaven64]

[microsoft] coined the term "viral" with respect to software licenses, and now everyone's using it.

Are you sure? My 1992 copy of the New Hacker's Dictionary contains a reference to the `General Public Virus', and I don't recall MS even having heard of the GPL back then...

The issue is late-binding.

[carlfish]

The general "nerd on the street" understanding of the LGPL is that so long as you don't make any changes to an LGPL Library, then making use of that library doesn't place your own code under any further obligation.

Section 6 contradicts that understanding. However, Java programmers have generally believed that Section 6 does not apply to them, because Java is a late-binding language. The LGPL talks about "linking executables", but Java doesn't perform the linking step until runtime, supposedly freeing Java of the Section 6 responsibilities to give an offer (valid for three years) to distribute the LGPL'd library source themselves, plus anything you would need to make the app work with a modified version of the library.

The advice that Section 6 actually _Does_ apply to late-binding languages places a significant burden on projects making use of LGPL'd libraries that until now they didn't think they had to meet.

Re:The GPL is like a Vaccine

[mjmalone]

Ok, I'm not quite sure you understand what they mean by "viral" here. I think what they are saying is that code written that includes the LGPL'd Java libraries inherets the LGPL. So basically, if you include one of these libraries your code MUST be LGPL'd. This is obviously a problem.

Misleading article

[timsuth]

This slashdot article is misleading. It gives the impression that if your Java code uses an LGPL library then you must provide your source code, permit changes/redistribution etc.

This is not the case. What the FSF guy way saying is "With respect to the LGPL, 'import' in Java is equivalent to linking in C." This means that if you make changes to an LGPL library you use via import in Java, you must make the changes to the LGPL library available to others. This is exactly the same situation which applies in the C world.

The reason the Apache people don't want to use the LGPL (for any language) is that they want their libraries to be under a more permissive license which allows the libraries to be modified without requiring the users to make the changes available.

Some people were suggesting that there was a loophole in the LGPL which meant that they could 'import' a library in Java and avoid having to make changes to the LGPL library available.

The "news" is that the loophole does not exist - the LGPL applies to Java in the same way as it does in C.

Yes, that David Turner

[prizog]

Hi. I'm that David Turner who is quoted. I'm not the David Turner who works for Microsoft, and I do not hack on Freetype.

First, I'm upset that CowboyNeal didn't contact me -- as the article says, I work at the Free Software Foundation, and you can find our phone number on our web page by searching for "s" on Google and clicking "I Feel Lucky."

Now, if you read section 6 of the LGPL, it's not the same hereditary [1] thing as section 2 of the GPL -- what it says is that your program, which links against the library, does not need to be licensed under the LGPL. But you do have some obligations -- you need to allow people to relink your code with new versions of the library.

[1] I think hereditary is a much better analogy than viral, and I thank the person who came up with it and whose name I forget.

Re:Yes, that David Turner

[prizog]

The problem is that CowboyNeal didn't call me first.

As a result, the article gives the wrong impression -- it implies that the LGPL is broken with respect to Java. In fact, it is not. Section 6 works for Java in the more-or-less the same way it works for C.

Re:Yes, that David Turner

[prizog]

I cite the greater good that this will hopefully increase awareness of the obligations created under the LGPL.

Instead, you have confused the issue further.

Most people believe that using an LGPL library does not place any additional obligations on the person using it, so long as they don't modify the library itself. Section 6 contradicts that popular belief.

I agree that this is a common false belief. However, Section 6 is far from secret, and anyone who distributes software should read the license before doing so.

Similarly, people might quite reasonably believe that using a late-binding language is a way out of being considered "linked" to the library.

FSF has always had the same views on this -- it's not really a surprise.

Re:Yes, that David Turner

[prizog]

Oh, wait, now I actually read your post, and realize that you are still completely confused. Sorry.

Let me make it clear: Section 6 is not what you think it is.

You think section 6 says:

You must cause any work that you distribute or publish, that links to the Library, to be licensed as a whole at no charge to all third parties under the terms of this License.

Section 6 actually says: ...distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

Note that this does not require the provision of source code, nor does it require allowing the original program or modifications thereof to be distributed.

Re:Yes, that David Turner

[prizog]

1. Make sure your licensing follows the simple requirements in the 1st para of section 6.

2. Provide the LGPL library in a separate jar, and allow that jar to be replaced by newer versions of the library. This is only one of the possible ways to comply, but it's certainly the easiest.

3. Make available the source code for the LGPL library.

Bunch of Crap!

[OYAHHH]

This material should be considered akin to shouting fire in a crowded theatre when there isn't a spark around for miles.

Anybody who works regularly with Java will understand the mechanics of how professionals work with provided libraries and that those same mechanisms fit perfectly with the requirements of Section 6, Part B of the LGPL.

It's pretty obvious that the writer doesn't understand Java programming or Java systems configuration.

To explain how Java works, basically if you want to utilize a third party library all you need to do is:

1. Distribute Sun's (or a suitable facimile) Java Runtime Environment to your target clients.

Note that the standard JRE comes with a ../lib/ext directory just for the explicit purpose of dropping in your libraries and any third party libraries.

BTW, once in the ../lib/ext directory the library is effectively shared for any Java program utilizing this particular JRE installation.

2. Put your own libraries in the ../lib/ext directory.

3. Put the third party library in the ../lib/ext directory.

4. Run your Java program. Note how long it takes to "load up".

My guess is that one of the things the JRE is doing is reading those libraries to "know what it has available" and storing that info in some sort of a hashtable.

5. During your program's execution create a object from the third party library.

Note, that the Java interpreter merely looks up the class in the hash via an internal call that anybody can duplicate. But why when all you are duplicating what is already built-in the Java interpreter.

If some client/end-user wants to substitute in a modified version of the third party library then there is nothing stopping them.

They can drop in a modified or a substitute library just so long as the class names and method names, etc.. stay the same.

Whether the program continues to work is a totally different matter.

But the key point is is that the entire process is all dynamic. And from one run of the program to another run nothing guarantees the calling program that the third party library is actually the one that was originally installed.

Please, people

[Fnkmaster]

Go back and read the LGPL again. The terms in Section 5/6 are not the terms commonly used with Java, sure, but the intent is pretty much crystal clear. If you use material from header files (read: interfaces or general class descriptions - the stuff that goes in header files in the C world) to make calls into the classes falls outside the scope of the license. The LGPL is no more or less befuddling with respect to Java then it is with respect to other languages. Likewise, the relationship elucidated between your object code and the LGPLed object code, whether it be in JAR or DLL format, isn't terribly different. If you contain or reuse too much of a library in your code, there's always a fuzzy, slippery slope of what constitutes a derived work. Again, this is really no different from the way the LPGL would apply to C/C++.

So Section 5 applies just as it does with non-Java code. Likewise, Section 6 is pretty darned clear. Section 6b still applied for Java - Java runtime linking meets all the requirements of 6b. What's the big deal? As long as the LGPLed library (or it's "modified form" you distribute under your own terms, per section 6) is distributed in a separate JAR, it can be replaced by another, recompiled version of the JAR. You can change one line of code, and recompile the original library to a JAR file, distribute it under your own terms, just provide source for your "modified" version of the library, and you have complied with section 6. Voila. There's no need to jump through these hoops though, section 5 still applies, let's not get our panties in a bunch, the sky has not fallen.

Re:FSF's interpretation are not very relevant

[alienw]

Technically, when you "LGPL" your code, you sign away license rights for that software release to the FSF. That is why if someone violates the license of your GPL'ed program, the FSF can step in (with their lawyers) to defend your licensing rights. You are still the program's copyright owner, and you can reissue your program under another license if you like (though you can't "retract" your original release).

Pretty much everything in that paragraph is WRONG. First, unless you EXPLICITLY re-assign your copyright rights to the FSF, they do not own the copyright and cannot defend your rights. That certainly does not happen automatically. Unless your software says "copyright (C) 2003, the Free Software Foundation", it's not theirs and they cannot enforce your copyright.

Second, if you do re-assign the rights to the FSF, you are no longer the owner and may not reissue the program under any other license. You would only have the rights afforded to you by the GPL.

Third, you may not modify the LGPL or the GPL in any way. It violates the FSF's copyright and is not allowed. Read the license -- "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." (emphasis mine, obviously).

That's not what Mr Turner said

[p3d0]

I quote Mr Turner's statement in its entirety:

DT: This sort of linking falls under section 6 of the LGPL.

He does not answer in the affirmative, nor in the negative. He merely points at section 6. He does not even offer any interpretation.

How could this be construed as saying that "LGPL is Viral for Java"?

Maybe there's more to it in that one link that's Slashdotted.

Clarification from FSF on Section 6 of LGPL

[bkuhn]

LGPL's Section 6 allows you to make new works that link with the LGPL'ed code, and license those new works any way you see fit. Only the LGPL'ed code itself must remain Free. Such 'client code' (as mentioned in the story posting) can even be proprietary; it need not be LGPL'ed. LGPL's Section 6 does place some requirements on what you do, but that is only to make sure that people can effectively exercise their freedoms to copy, modify, and redistribute the LGPL'ed code.

-- Bradley M. Kuhn, Executive Director, Free Software Foundation