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."
they coined the term "viral" with respect to software licenses, and now everyone's using it.
:\
good stuff.
I know a way they can handle their GPL model..
Just ask SCO!
"If it is not OUR's then it must be Viral"
Just switch to the BSD license, like the Vorbis project did.
Please read that again. And again, until you get it. The GPL is not viral. It's pretty simple, really. If you're going to use [L]GPL'd code, follow the terms of the license, or don't use it.
You have a choice. The [L]GPL is not a little bug trying to worm its way into your code. If you chose to use GPL code, then you follow the terms, or don't use the code. It's simple.
If you find some really neat library under the [L]GPL that you want to use, and you don't want to follow the terms, well: tough luck. Offer to compensate the author; perhaps he or she will license it to you differently. Otherwise, write your own code.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
I can see how you could be confused since commercial licensing issues are only relevant to those that don't live in momma's basement.
A Pirate and a Puritan look the same on a balance sheet.
I am a Java developer, and I have used the LGPL on work (and also used work that HAS been LGPLed).
My intent in using the LGPL is pretty simple: If you want to use my library, go ahead. If you make CHANGES to my library, those have to be released back into the wild, so the library can be improved by everyone's improvements. I'm not a 'Free Software' zealot - I'm an open-source pragmatist.
If the LGPL does not meet this intent with Java, then we should find or write a license that has this intent. Perhaps one of the ones at Creative Commons would work...
The post states that you cannot import or "lift" any lgpl code * code * code into another project unless that project becomes lgpl'd also. This is correct; however, the resulting lgpl'd library (binary) can be called / used by a non-lgpl'd project. It is really not that confusing.
This viral stuff is backwards. I think the BSD license is actually more
viral than the GPL. Here's why:
If I decide to write a program and contribute it to free software, the
GPL assures me that it will stay free software forever. I'd be bothered
if somebody made it non-free, effectively stealing my work for their
own remuneration. The GPL is effectively a vaccine against that.
The BSD license lets people apply almost any license to my software,
including most non-free licenses. If I wrote work under the BSD license,
someone could modify it and sell the result with no source code, and
I'd have no recourse at all. Anyone who wants can infect my BSD software
with the non-free license virus.
So, which license is more viral? It sounds to me as if the GPL is getting
a bum rap here.
By the way, the BSD license allows you to apply the GPL to a modified
BSD work. I've thought about organizing a GPL-ed thread derived from the
body of existing BSD-licensed work, just to illustrate a lesson about
the BSD license. That would really piss people off, but it would be legal.
I'm not Seth.
b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
So what you should do as a LGPL library developer is:
1. Define interfaces for all the objects.
2. But these into their own Jar files. Tag these as the interface.
3. Both the Implementing Jar and the calling program refer to eah other through the interfaces only. Somewhere in the interface Jar is a Factory the various implementations can regster themselve with to provide dynamic loading.
This is how Databse and Cryptography stuff works in Java. If it can't be done this way, it is probably not a library.
Note that doing:
List l = new LGPLList(); is probably Illegal but
List l = (List) Class.forName("org.gnu.LGPLList").newINstance();
Is probably OK. Note that I say probably. I'm not a lawyer, nor do I play one on TV.
Open Source Identity Management: FreeIPA.org
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.
You have a choice. The [L]GPL is not a little bug trying to worm its way into your code. If you chose to use GPL code, then you follow the terms, or don't use the code. It's simple.
You seem to miss the entire point of the LGPL. The whole point is that you should be able to use LGPL code in a non-LGPL project. To quote from the website:
"The choice of license makes a big difference: using the Library GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs."
So whereas the GPL is intended to be somewhat "viral" -- i.e. software using GPL code must also be GPL -- the LGPL is not supposed to. This is why the viral-ness of the LGPL is news, since it's contrary to much of the community's understanding and intent regarding the use of LGPL code.
Cheers,
IT
Power corrupts. PowerPoint corrupts absolutely.
The problem here is that the technicality of this section of the LGPL and the FSF's interpretation of it are not in sync with 98% of the people using and releasing code under the LGPL. I've used LGPL code and seeing as the jars were libraries it didn't even occurr to me that this would be an issue.
This causes uncertainty over the nature of LGPL software right now. Would a court of law agree with this interpretation? Now I'm left with an odd decision. Do I gut my code under the presumption that this FSF lawyer is right, or do I take my chances that a court will interpret this as the vast majority of the community has.
Open source software lives by the certainty of the licensing it uses. If we can't trust the interpretation of the licenses, then we can't feel confident in working with this code. The FSF is risking a serious blow to the open source community.
This sig has been temporarily disconnected or is no longer in service
One example of one such non-standard interpretation is the "Lisp LGPL", used by Franz for their open source libraries. Parts of the LGPL don't make much sense for non-C-like languages such as Common Lisp, so they added a preample which explains their interpretation.
Another real-world example is Pine. Early versions of Pine had a BSD-like license, which allows "modification and distribution". The University of Waterloo interpreted this to mean that you could modify Pine, or distribute an unmodified Pine, but not distribute a modified Pine. This was contrary to everybody else's interpretation, but they owned the copyright so they got to decide. (More recent versions have a different license).
We get statements like that all the time from the FSF and there's no validity to them.
The FSF writes their licenses. Any subsequent ambiguities are to be decided in court. There is no basis for post-facto "decrees" about what a document is supposed to mean -- the author has the opportunity to write it to cover whatever case, and has the responsibility to make his intentions clear then.
What I'm listening to now on Pandora...
What about languages like PHP where the application is never compiled? The only way to use someone else's PHP is to #include it into your application - merge the code into your application.
Seems to me like the [L]GPL is sorely lacking in many areas - I'm developing a library and application in it, and it's very confusing to me to have to understand how to combine code that is not mine with code that is, without violating the license. I can't possibly write everything myself, and I want to be able to collaborate with other people... but any code of mine that is LGPL, can only be used in LGPL applications, and any code of mine that is GPL can only be used in GPL applications. And if my friend wrote a function that is GPL, I can't use it in my LGPL library without making it GPL, even if he wants me to! (He has to relicense his code under the LGPL for me if I actually am going to use it!)
I don't know if that's Viral or not, but it sure sucks.
using namespace slashdot;
troll::post();
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.
Open source software lives by the certainty of the licensing it uses. If we can't trust the interpretation of the licenses, then we can't feel confident in working with this code. The FSF is risking a serious blow to the open source community.
So why not just draft your own license that's basically the LGPL, except that it is built specifically so that it will work as most people expect it to with Java libraries (and maybe other languages, like Objective-C libraries)?
Make sure that the license is compatible (as much as possible without destroying the intended modification for Java code) with the FSF's LGPL, GPL, etc licensees. Then find some way (I have no idea how to do this) to get people to know about this. Maybe bribe on of the Slashdot webmasters to put it on..
I'm not a GPL fantic or anything but...
GPL backers typically don't like the adjective "viral" to be used to describe their work because it has a negative connotation. ie. The set of associations implied by a word in addition to its literal meaning. ( dictionary.com ) To me, that position is very understandable.
There's always more than one way to say what you mean. You can call someone "Stubborn" or you can call them "Strong willed", almost the same thing? Marketing, politicials use this type of thing very often.
In fact 'viral', as an adjective is, I'd say, blatantly demeaning. There is absolutely nothing good about a virus, and that connotation sticks with the adjective.
Would you tell your girlfriend "your love for her is spreading through your system like ebola"? or I love you like flies like sh**?
Both those statements I believe express great unyeilding passion. But it may not go over that way.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
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....
Okay, if I make a piece of java code, like a class, and provide methods to use that class, and wrap this up in a jar file and say it's now under LGPL, then here's what somebody should be able to do (IMO):
1. Create java code which uses my library (jar file) with the library as a separate jar file (ie., none of my code is in their code, they're just calling methods and classes from my code).
2. Not have any requirements placed upon their code at all in any way.
As I see it, this is exactly what the LGPL does. Section 6 never comes into play whatsoever, because their code falls into section 5. They haven't actually combined my code into theirs, it's totally separate, sitting right in that jar file (aka library).
Granted, if they modify my code and distribute the modified version, then they must distribute the modifications they made to my code as well. That's what the LGPL is for in the first place.
But I fail to see how section 6 applies in any way whatsoever. None of my LGPL'd code is included in their code in any way. It's separated because it's in a separate jar file.
Lookie here:
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
To me, this exactly describes someone calling classes or other code that resides in my jar file. They're not copying the code into their own jar, they're linking to it. But let's look at section 6:
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library...
This never happens if done properly. My jar is sitting alone, their jar is sitting alone. At runtime, their jar loads, says to the java interpreter "hey, make a class from that other jar", then my jar loads and a class gets created.
So, am I wrong here? I see no normal situation in which section 6 would ever apply to Java libraries, unless someone was straight up ripping my classes off and including them in their own jar file along with their own code.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
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
You are so dead on with this comment and it's the one thing that all GPL zealots don't seem to get. Just because you release some code for free, be it BSD or public domain or whatever, and some commercial entity hyjaks the code, how did your initial contribution become "less free?". Everyone can still use YOUR free code. In fact, another commercial corp can hyjak your code again and be a competitor to the first commercial hyjak. Who cares? YOUR CODE IS STILL FREE!
Don't get me wrong, I like the GPL as well, but I see the GPL as applying Intellectual Proprety Rights to free code. Whereas the motive may be good, the purpose is to limit it's useability. Sure you can say GPL is more free because it virally mandates that all derived works must be free, hence this increases the overall amount of free code availible on the net. That's great and you'll save the world by putting a few commercial programmers out of a job. BSD code can be said to be more free because you can do whatever the hell you want to do with it. A larger audience can use it and hence more free.
It depends on your perspective, but I like the BSD definition of free and it's more meaniful. In regards to protecting a personal free project from being hyjaked, the GPL is a good vehicle. Just don't lie and think you're doing a better service to the world because you use GPL. People who use GPL do it for themselves and no one else.