Slashdot Mirror
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."
I have had physical relations with other humans and even *I* know what this is. It's the GNU Lesser General Public Licnese...
You can read about here: http://www.gnu.org/copyleft/lesser.html
Now if you'll excuse me I need to go back to my mundane life of co-mingling with other humans...
Oh and they're female in case you're wondering...
Polymorphism -- It's what you make of 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...
I am TheRaven on Soylent News
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.
The more I learn about the Internet, the more amazed I am that it works at all.
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.
Visualize the world of wine
I think a simple separate jar of the LGPL ought to be enough. The reason is simple, what you propose is a runtime instantiation. Thanks to the Java class loading mechanism this already happens.
.Net however could be more on the problematic side here, since it uses as far as I recall some kind of mem dump, a real linking more or less.
Lets look at the basic mechanisms of java
a) A library simply is a class file nothing more nothing less
b) A jar file is a collection of libraries bundled to a compressed zip file + optional execution info
c) Java does nothing than to uncompress the libraries already present on the disk on the fly.
d) The linking to this library happens after program startup at the first time a class is called, hence the singleton pattern really does lazy instantiation even of a class and therefore of a library.
Ever library/class has to be decompressed from a jar or loaded directly from the disk. It is copied into memory and this is done at the first time the class is called in a program. It has to pass an already running class loader (which is a java class itself) and the program already has already entered main at this stage if I interprete my runtime and debugging experience correctly.
Now lets look at the problematic sections:
>A suitable mechanism is one that (1) uses at run time a >copy of the library already present on the user's computer
>system
This describes exactly the class loading mechanism for class files lying around on the file system or for separate jar files, maybe even LGPL code bundled into a jar can be applied to it
(this is very vague however)
Whoever did the analysis did not know what a class loader is.
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.
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.
Become a FSF associate member before the low #s are used
This material should be considered akin to shouting fire in a crowded theatre when there isn't a spark around for miles.
../lib/ext directory just for the explicit purpose of dropping in your libraries and any third party libraries.
../lib/ext directory the library is effectively shared for any Java program utilizing this particular JRE installation.
../lib/ext directory.
../lib/ext directory.
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
BTW, once in the
2. Put your own libraries in the
3. Put the third party library in the
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.
Caution: Contents under pressure
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.
Isn't the issue that for security reasons java requires the exact version of the jar linked against to be present and fails if you compile your own modified version?
No, you can drop in updated jars (pace usual API compatibility issues). You might be thinking of serialisation issues that can crop up (but even then they can be worked around).
Slashdot looked deep within my soul and assigned
me a number based on the order in which I joined
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.
That's not true. FSF can only enforce the (L)GPL for programs on which FSF holds copyright.
Become a FSF associate member before the low #s are used
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).
Nonsense. The GPL is intended to do exactly what you say it doesn't: it's intended to make all software free. It's a tool intended to destroy copyright from within.
BS. The GPL is intended to force a give some take some trade agreement on people who use free software. If you want to make your job easier by using somebody else's code, then the GPL forces you to do a favor in turn by making your code available to make somebody else's job easier (if you want to distribute it, that is).
It is not intended to destroy copyright (or intellectual property), it uses copyright. Without copyright there is no way it could exist. It doesn't "infect" people. And you can't "catch" it unless you want it. So aside from the idea that the license forces itself onto developers who want to distribute derivatives of GPL'd code, the term "viral" is not an accurate description. It is propaganda invented by Microsoft during their FUD campaign. All licenses have terms (BSD license included: you have to include the copyright statement). The GPL license just has more stringent terms when it comes to distribution.
Import is provided so you don't have type out whole package names. It is a common misconception that it has something to do with linking. Everyone keeps saying things like "if you use import then...blah blah", but you don't have to use import - ever. You can just always use the fully qualified name: like "foo.myclass". Or you can say "import foo;" and simply refer to "myclass". That's it - no magic - it is more like a preprocessor. What about using reflection? hehe...
There are effects on your own code, or rather 'responsibilities':
- you must allow for reverse-engineering in your license
- you must allow linking against other versions of the library
The problem is that these clauses are considered viral. Apache gives these rights, but doesn't require transferrance of these rights for projects which use Apache code. Once an Apache project uses LGPL code, those using the Apache project have to make these provisions in their products.
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.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
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
Turner explained himself further in subsequent posts. You simply need to follow the rules for LGPL in Java as in C (ie, package your app so that the LGPL library can be replaced simply). You state that:
the LGPL works virtually the same as the GPL for Java code.
Certainly you can use the LGPL for C. Therefore, what is in fact true is that
the LGPL works virtually the same for Java as for C.
Someone tell me the difference between a BSD license and just putting your code into the public domain, 'cause I would really like to know what that difference is.
BSD style licenses require evil companies to give credit to the original copyright owner.
-- Sigs are for losers
I believe the issue is that Apache wants to make sure downstream distributors aren't forced to comply with more restrictive licenses than the ASL.
If I create a product based on Apache products that need to include LGPL code, I have to worry about whether my code has to be released under LGPL or else force my end users to download and install separate packages to make my product work.
Apache doesn't want to pass the buck by not distributing LGPL code, but requiring its end users to use it themselves. Avoiding LGPL dependencies altogether is the cleanest way to ensure that the benefits of the Apache license are passed down to its users.
Note that this isn't a feature of the Apache license, but an Apache policy. So downstream users are free to use GPL if they like, whereas GPL users aren't free to use the ASL license.
-- Sigs are for losers
Uhm no. Read the GPL. You are allowed to have private code. You, only have to release the code if you distribute the binaries. If you don't distribute binaries and keep everything in-house, you won't have to release the source code either.
They were specific that the restriction is *not* that the code would have to be LGPLed, but rather that section 6 would be in effect. Section 6 does not LGPL the code. Section 6 does place restrictions. Not the same thing. What appears relevant (besides user notification...) is "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."
David Turner summarizes, "Section 6 of the LGPL is not the same hereditary 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, for example."