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"
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.
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.
It's worth pointing out that no-one (except a court) is really in a position to 'decree' what the LGPL clause 6 means if it really is a close call on more than one interpretation. If it turns out to be ambiguous or contentious, the best move could be to debate a clarification and campaign for the adoption of that instead.
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.
Subject: Re: [Followup] RE: Possibly Include HTMLParser Jar in contribcode?
From: "Andrew C. Oliver" <acoliver <at> apache.org>
Date: Wed, 16 Jul 2003 08:12:12 -0400
Newsgroups: gmane.comp.jakarta.poi.devel
You cannot. Though the FSF has stated that the Apache interpretation was correct and that importing classes from LGPL jar files in Java does indeed cause the "viral clause" to apply to Java.
Please stop saying "lift the code" or other things that imply violating the copyright.
Under no circumstances can any LGPL code be used as it would require us to LGPL our code per section 6 of the LGPL license and the statement I received from the Free Software Foundation's Dave Turner (the man behind licensing <at> fsf.org):
" Me:
DT: This sort of linking falls under section 6 of the LGPL. "In short, Sam was right, I was wrong.
-Andy
On 7/16/03 4:55 AM, "EPugh <at> upstate.com" <EPugh <at> upstate.com> wrote:
--Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
Sig:Why copyright isn't a fundamental human right
Please, why do we need to hear these words in relation to the (L)GPL? Apart from the fact that they have a very negative tone, they don't even properly describe the nature of the GPL.
:)
There are few ways you could _accidently_ end up in a situation where your code is in violation of the GPL (i.e. a situation where you are required to release your code under the GPL or remove GPLd parts of it). Of course, if you don't know what you're doing you could use for example GNU readline for your program and not discover until the end of development that you are required to distribute your program (a derivative work in legal code) under the terms of the GPL, but since when does negligence make something viral?
If something were viral, you could end up "catching" it even if you didn't want to, but the only way to get yourself into a situation where your code must be distributed under the GPL is if you want that to happen, or if you don't bother checking the terms of use+distribution of the software you're using.
A better word might be "self-propagating". Technically it is of course developers using GPLd code who propagate the license, but that's just semantics.
As you know, there are _no_ restrictions of using GPLd software, so there's no risk of "infection" there.
[end rant mode]
I'm not saying here that everyone who doesn't understand the GPL is an idiot and deserves to have their code affected, only that viral is an inappropriate word.
As for the LGPL+Java thing, well my post has nothing to do with it
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
So does that mean if I have a Perl or Python module under the LGPL that is used/imported into a project, the LGPL applies?
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
Did anyone else read this as LGPL is Vital for Java. Guess thats what happens when you're half asleep
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
Run Windows Update.... it now has an antivirus patch which removes all GPL and LGPL software from your system. Ain't that nice and tidy!!
Has the GPL or the LGPL ever been litigated? With the opportunity for interpretation being what it is, you would think someone would push the envelope and wind up in court. Have they?
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.
You know all this license stuff is way to much for a simple coder like me. I can now see where the BSD license is coming from:
"Here, just take the god damn code. If it breaks I don't care!"
You don't gain anything by GPLing your software except for the satisfaction that no one will probably ever make a profit off of it.
If the program's useful then there's every chance that people will profit off of it. To suggest otherwise is just silly. Companies large and small all over the world use GPLd software in their businesses. The GPL does not seek to prevent this.
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..
They think 1) open source code's quality is much less than commercial closed source code
2) the open source code has malicious intentionally hidden 'backdoors' and 'viruses' and 3) that open source could threaten our projects from a legal standpoint (intellectual property etc)
Recently our company has been making small strides in changing our client's attitude. News like this kills our efforts (giving more power to ignorant people against open source) and only slows down open source's adoption...
Hell, I can't use anything from Apache - like Struts or anything else from Jakarta! Reading some of the posts (and my initial reaction to the main one) it sounds like many people are happy because of this... well for me this sucks!
Those are both fair uses. The LGPL does not permit users to link with LGPL'd code if their license explicitly prohibits fair use -- in fact it goes out of its way to ensure that linked LGPL code can be replaced with other linked LGPL code.
--
BitTorrent in C -- LibBT
http://www.sf.net/projects/libbt
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
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...
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....
There is the Free Software Foundation. When will we have a Freer Software Foundation? Then when will we have the Freest Software Foundation? Rise up! Revolt! Distribute gcc, et al., with the GPL removed. Go ahead!
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
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.
Note: this was also an issue in the design of the 2.5 kernel with driver developers "overwriting" large portions of the kernel in their closed drivers by calling a lib properly but then "redirecting" all the stuff internally to their own stuff. [a certian GPU developer may get bit by this]
I say, "I use the GPL to encourage open source development. If I were to use the LGPL, then you could use my libraries without giving me the source to your program.".
They still can -- the GPL only requires a party to provide their changes to your code _if_ they redistribute the code. And then, they only have to provide it to the people they redistribute the binaries to.
You may never see their changes if they don't redistribute your code, or if they decide to redistribute it only to those people they've redistributed their binaries to (which doesn't have to be publically online -- they could do it via postal mail if they wanted to).
You've chosen a bad reason to not use the LGPL license...
Yaz.
As I understand it, the Java issue seems to be almost identical to the static linking problem.
While I label a lot of my code as LGPL, I have absolutely no problem with static linking the code. I don't see how a few linker options are relevant to licensing of source code.
This has always been a nitpick that has baffled me about the GPL and LGPL. Why does everyone have such an issue with static linking? Static linking doesn't change the code I release, and nor should the implementation of byte code loaders and Java runtimes.
I do not fail; I succeed at finding out what does not work.
Let me rephrase that last statement:
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, without getting the most definitely undesirable stigma of section 6 attached to the code.
The whole point of the LGPL is to create libraries that are open source but which can be used by closed source programs, requiring only that any modifications to the *library* be distributed back into open source. Your definition requires more than that, and thus the LGPL doesn't do what everybody has thought it did for the past X years.
- 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.
If, however, I want to include GPLed code in my program, the GPL forces me to release my program under the GPL. It has *infected* my program.
Wrong. You have infected your program by including the GPL covered code. No one held a gun to your head and demanded that you include it, nor did the code sneak in through an open window and jump into your source repository. That was your choice. Calling it viral is ungracious at best.
[...] under non-free licenses like the GPL [...]
That you prefer the BSD terms to those of the GPL does not make the latter non-free in any meaningful sense and your claim to that effect is nothing more than religious zealotry. Learn to accept that not everyone will genuflect at your church and get over yourself.
Not all those who wander are lost.
Anyone who was pissed off would probably be so because you substituted a less freely usable license for a more free one.
A BSD licensed piece of code is only more freely usable from one persons point of view: the next developer.
Once he commercializes it, it will certainly become less freely usable to the end users who ultimately receive it.
So in the balance, BSD code is LESS freely usable than GPL. The GPL is the same free to everyone. There are tons of BSD bits that are free to almost nobody.
Its your prerogative to license things as you like, but dont say its "freer as BSD" because its just not true, unless you dont care one whit for the end users of a commercialized version.
My point is that it's my source code I want kept free and up to date.
I don't care if you use some of it, all of it, or none of it. I don't care what compiler you use, how you link the code, or what kind of applications you are building.
If print media comparisons are the problem, then software should be under a seperate set of laws. Software is not print media.
Source code is more like a blueprint or a recipie. It would be absurd for me to post a recipie for everyone to use, then complain about the way people were eating the food their chef produced. The chef's preparations are analagous to compiling the code, while linking is whether the consumer chooses to eat with their fingers, a knife and fork, chopsticks, etc.
My only legitimate cause for complaint is if they change the recipie, don't tell anyone what they changed, and either claim it as their own or fail to let others know it's not quite the same (don't publish changes.)
Static linking is a very common QA requirement for production applications. Trying to ban static linking is just plain ignorant, and there is no way you can convince me otherwise.
I do not fail; I succeed at finding out what does not work.