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.
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
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
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
Sorry to rant here, but I quickly checked section six, no big deal here
:-)
:-)
Either use a separate jar file for the library then the thing is not linked and used like a shared lib (according to the section six definition it must reside as a separated interface compatible lib)
Or just bundle the binary with the LGPL code and add I will allow reverse engineering to my code clause to your own code license. I don't really see the problem, there is no way stated that you have to deliver the source from your own code there is an explizit "and/or" there and even the usage of obfuscators aren't prohibited as long as you allow reverse engineering and alteration of your own binary files.
Btw. separate class files must fall into the same shared library section as separated jar files
As I see it this is nothing but self inflicted fud
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...
This is an interesting topic, but the way the submitter phrases it is 100% pure flamebait.
The GPL (and to a lesser extent the LGPL) is a vaccine for the body of free code (a little bit of benign IP law to save us from the ravages of truly malignant IP law), not a disease you catch accidentally.
microsoftword.mp3 - it doesn't care that they're not words...
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?
The Java import statement does not alter the compiled class in any way. The import statement is esentially a compiler directive, which tells the compiler in what packages to look for classes.
For example:
import java.util.*;
public class Bob {
Vector v = new Vector();
}
and...
public class Bob {
java.util.Vector v = new java.util.Vector();
}
produce the same exact bytecode. In the first case the compiler would search for class Vector in the packages specified in the import statements.
I does not actually import anything from those packages/classes into the class.
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..
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
Linking is a step done by the final user, who executes the program/applet.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
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.
I would do that, except that the FSF doesn't believe in freedom. The freest you can get source code is the public domain, but the FSF does not want you to release code under the public domain, particularly their specially copyrighted stuff.
In fact, the FSF doesn't even want to achieve their goals. You see, if they got their stated wishes, and all copyright laws were rescinded, the whole concept of copyleft would instantly evaporate. You would no longer be required to distribute the sources to gcc on demand to those you gave the binaries to. You could link to libreadline without placing your application under the GPL.
It's sort of like an organization arguing against land ownership, who came up with a boilerplate deed called "propertyleft" that attempts to abolish the building of fences. But if they ever got their way, their deeds would be meaningless and people would be free to build fences all over the place, including on land that was previously owned by the Free Property Foundation.
A Government Is a Body of People, Usually Notably Ungoverned
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.
Just a wrong headline on slashdot. The whole thing apparently started by somebody believing "since we use Java, we don't have do follow the LGPL", and the FSF clarified that the LGPL works exactly the same for Java as it does for C or C++.
Constructing a headline from an out-of-context quote in the middle of a long thread... Is slashdot trying to copy CNET or MSNBC?
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.
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.