LGPL is Viral for Java 717
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."
great, microsoft succeed again (Score:5, Insightful)
good stuff.
The GPL is like a Vaccine (Score:3, Insightful)
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 lic
Re:The GPL is like a Vaccine (Score:5, Funny)
Re:The GPL is like a Vaccine (Score:3, Interesting)
1. Recognize the need for a GPL'd library
2. Write generic interfaces for the type of external functionality you need in your classes, and write code for your new classes to interact with those generic interfaces.
3. Create wrapper classes for the GPL'd code implementing those generic interfaces, and distribute as a seperate GPL'd plugin.
Done. Whats so hard about that people? I am currently writing some remote authentication code using a GPL'd SA
Re:The GPL is like a Vaccine (Score:5, Informative)
Re:The GPL is like a Vaccine (Score:3, Informative)
David Turner summarizes, "Section 6 of
Re:The GPL is like a Vaccine (Score:5, Interesting)
Nope; if every copy disappears or becomes useless it's not free software (perhaps it's free, but it's arguably not software). That happens all the time with many different programs -- although by definition few of us have heard of them. (There's a LOT of them on Sourceforge right now.)
Neither BSD nor GPL protects against that -- although the BSD license does have the possibility of attracting more users and developers due to the fact that it can be used as part of proprietary work. The only problem is that these developers can be invisible, never releasing their improvements; but that's a problem with not understanding the benefits and uses of open source.
The BSD license lets people apply almost any license to my software, including most non-free licenses.
Nope! It lets people apply almost any license to _derivative works_ of your work (including the trivial derivative work of simple redistribution). Your original work is yours until your copyright expires; they can't take it from you.
Some of these pro-GPL arguments are as bad as the RIAA. "Help! They're STEALING OUR CODE!!!" At least you're not as bad as SCO: "We own all licensing rights for all derived works, but WE get to decide what's derived."
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.
The price of freedom is having to put up with knaves.
Frankly, I'd be pissed if you forked my project, but it would be the needless fork that pissed me off, not the license (that doesn't apply to me because I'm BSD).
Anyone who was pissed off would probably be so because you substituted a less freely usable license for a more free one.
-Billy
Re:The GPL is like a Vaccine (Score:3, Insightful)
The only one you should be pissed on is yourself. If you chose to release your project as open source and someone forks it and you don't like it, then it's entirely your fault.
This is a farce (Score:3, Interesting)
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 yo
Re:This is a farce (Score:3, Insightful)
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
Re:The GPL is like a Vaccine (Score:5, Insightful)
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.
No dumbass, they can't steal your code if it is BSD licensed. What are they going to do, break into your house and remove the source from your HD? And do the same to every person who downloaded it? Repeat after me: YOU CANNOT STEAL WHAT IS FREE. As long as someone out there has a copy of your BSD code it will always be free.
The next point is that if someone copies your free BSD code and charges money for it they are NOT MAKING MONEY OFF OF YOUR CODE. Your code is FREE remember? They are making money off of whatever they added to your code (be it more code or a service contract or shiny packaging). If Microsoft takes your free BSD code, adds one line to it and charges $100 for it they are charging $100 for that one line of their code.
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.
Why would you want recourse? How have they wronged you? You released your code under a free license, and people are using your code. Hooray! Wasn't that the point of releasing your code?
Anyone who wants can infect my BSD software with the non-free license virus.
How can they "infect" your code? You still have your code sitting on your harddrive. What they have done is create an entirely new "thing" out of your code and their code.
By the way, the BSD license allows you to apply the GPL to a modified BSD work.
Correct. Isn't that nice and free of them?
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.
Perfectly legal. That's the point of the BSD license: allow as many people as possible to use the code for whatever purpose they imagine. I doubt the authors of the BSDed code would be bothered at all. They will probably be happy it is being used - that is why they released it under the BSD license.
Re:The GPL is like a Vaccine (Score:4, Insightful)
I'm convinced that the vast majority of people who release code under GPL have a hero fantasy in which Microsoft gets caught stealing their GPLed code and is thus forced to release the source for Windows, destroying them and sending Bill to the poorhouse. Then our brave coder will become a geek folk hero, showered with adoration for all time. I can see them on Letterman now: "Aw shucks, Dave, I just like writing code. I didn't plan on changing the world."
A very small group don't have this fantasy but foolishly believe that the GPL helps "free software" (whatever the hell that means).
An even smaller group understands what the GPL is actually for. These are the diehard RMS zealots who think nobody should be allowed to keep code private.
Re:The GPL is like a Vaccine (Score:5, Insightful)
Re:The GPL is like a Vaccine (Score:3, Informative)
Re:great, microsoft succeed again (Score:4, Informative)
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...
GPL model (Score:3, Funny)
Just ask SCO!
"If it is not OUR's then it must be Viral"
No problem. (Score:4, Insightful)
Re:No problem. (Score:5, Insightful)
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...
Re:No problem. (Score:3, Insightful)
We should worry about intent, not physical locading of the class into memory.
A minor modification would address the issue (Score:3, Insightful)
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 load
Irrelevant (Score:3, Interesting)
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
Re:No problem. (Score:5, Insightful)
refer to the GPL as viral.
If I spend years writing a program using no code other than my own, I
can release it under any license I want. If I incorporate BSD licensed
code into my program, I can still use any license I want, so long as I
preserve copyright notices. 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. This is where the term `viral' originates
with regard to the GPL.
The BSD license does not affect code and cannot affect code since it
can always be placed under another license. If someone makes proprietary
enhancements to my BSD licensed code on his own time with his own money,
the only code that has been infected with a non-free virus is his. My
code is still perfectly free. I can give it to whoever I want and it
is still as free as ever. The only thing I can't do is give away the
other person's proprietary enhancements made with his own time and his
own money and which could possibly completely overshadow the features
provided by my small amount of code.
Although the BSD license encourages the reuse of code for *any* purpose,
including in projects released under non-free licenses like the GPL or one
of the dozens of proprietary software licenses, doing it to piss people
off will not get you very far, and it will make you look foolhardy,
especially in the eyes of the people who wrote the free software (free
for *any* purpose) that you would be making non-free. I guess you think
no one understands the BSD license.
All in all, a fine spirit to take in the name of free software....
Re:No problem. (Score:5, Insightful)
In all honest the BSD license is the "Ultimate Opensource Freedom". You release your code in hopes of the good will of future coders seeing your code. You bank on the fact that if you had the heart to release it to the public that future developers may feel the same way. But you also realize that they may not even explore your code if it has a license that forces them to release their code.
So corperate america is willing to take a look at the possibility if their hands aren't tied. Eventually it's the hope that they will see the benifit of the source being released in the first place and let their modifications benifit the whole as well, possibly a little later after there has been a corner on the market from the secondary developers.
Perfect example? Macintosh OS X and FreeBSD. Apple saw that the FreeBSD system was solid and they added to it to make it a system they thought was overly viable for them and then later released an entire project (darwin) back under the BSD code it was incepted with.
So is BSD dying? Who knows, it's a wonder what exactly BSD code is doing right now as there is no obligation for the developers to release their modifications source. It's like a behind the scenes world where everyone uses the stuff but no one admits it. But yet we still see great projects come out of it, anyone ever used OS X?
The GPL is not viral. (Score:5, Insightful)
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.
Re:The GPL is not viral. (Score:3, Insightful)
Sorry, but that's like saying cholera is not bad as long as I don't catch it.
The term "viral" pisses people like you off because it's convenient to think that it's a term invented solely for the purpose of turning people off from using it, and that's not the case. In cases like this one (and many others that I won't dredge up right now) the adjective is perfectly applicable - it implies a lack of knowledge as to how the license works and how to use it, but it doesn't make it a
connotation (Score:5, Insightful)
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.
Re:The GPL is not viral. (Score:3, Interesting)
Balls. [There's good logic for you ;-)]
If you are a professional developer and you come across some neat free code that you decide to use, but you don't fully read and understand the license terms, then you are a total moron.
To continue your analogy, that's like saying "I decided to drink the water from the river, but no-one told me that I could catch cholera". Ah, bloody diddums.
J.
Re:The GPL is not viral. (Score:2, Interesting)
I think you missed the point. The LGPL does not do what it was designed to do and what most programmers who use it think it does with their code. That's a problem, it's not a complaint that you can't use the code for whatever you like, it's a complaint that you can't use the code in the way that the original aut
Re:The GPL is not viral. (Score:2, Insightful)
No, the point is that calling the GPL or LGPL viral is wrong, whether or not it acts correctly in this case. Using the term "viral" is merely FUD-spreading. Saying "the LGPL has bugs when used with Java" would be far more accurate.
Besides, my point stands: you're responsible for knowing the actual terms of the license, not just thinking you know what it m
Re:The GPL is not viral. (Score:3, Insightful)
Saying that it's viral is mere shorthand for that, and you obviously know that (since you define viral in that way).
Now, your prescription to deal with the viralness is quite on-target -- money talks, and coding your own dang solution also works. But this doesn't change the facts about how the GPL works, and how it's intended to work.
Grin... T
Re:The GPL is not viral. (Score:5, Insightful)
The GPL is a tool to make YOUR software free, not someone else's software. It's not designed to "destroy copyright from within". If you think so, you are a retarded assmonkey who needs to shut up and read what Richard Stallman has to say about the goals of the FSF and the GPL.
Unlike certain EULAs and NDAs, the GPL is not viral. Looking at GPL'd code is permitted, no strings attached. You just can't copy GPL-licensed code into your program unless it's also GPL-licensed. I don't see how this is viral.
Re:The GPL is not viral. (Score:3, Insightful)
1. The GPL does not prevent you from copying GPL'd code into a non-GPL'd program. You are completely free to do that. The GPL prevents you from distributing that code as part of a non-GPL'd program. A company, for example, could create their own proprietary software based in part on GPL'd code and distribute it throughout, but not outside of, the organization.
2. Like it or not, viral is not an unreasonable
Re:The GPL is not viral. (Score:4, Interesting)
It is intended to make all software free. That is the goal of the FSF and the GPL. Eric Raymond of the Open Source Initiative takes a more moderate view, and explains that some categories of software should not be free... but that's not the GPL's goal.
By use of the GPL, RMS hoped to make all software Free by providing quality GPL code as an incentive for new programs to be GPLed too. Otherwise, they'd be missing out on many cheaply available features. The idea was that GPL use would snowball- at some point, when the preponderance of useful libraries are GPLed, then creating a non-GPL program that can't use them would be an exercise in futile money-wasting.
RMS doesn't like the LGPL [gnu.org] for this reason- he does not want people to be able to link to Free libraries without Freeing up their code. That's why he renamed it from "Library GPL" to "Lesser GPL"- to emphasize disapproval.
The word "viral" to describe the GPL is of course incorrect- unless one also agrees that the copyright system is viral itself (according to the legal definition of a derived work, which are "infected" with the copyright of the previous author).
Re:The GPL is not viral. (Score:3, Insightful)
Can you quote him on that? I always thought he was encouraging software to be free, not eradicaing any commercial programs. How can you 'eradicate' commercial software, anyway? I don't think Stallman is trying to get laws passed that prohibit charging money for software.
So that "information can be free".
Stallman was talking about software, not 'information'. Again, can you cite a source for that "quote"?
Do you contend that?
Yes, s
Re:The GPL is not viral. (Score:3, Insightful)
Yes, basically, and no, I didn't say it wasn't.
Precisely wrong. The idea is to provide a great deal of high-quality software that's Free(tm) such that's it's easier (and perhaps cheaper) just to write more Free(tm) so
Re:The GPL is not viral. (Score:4, Interesting)
Your complaints against the word "viral" would hold a lot more if you didn't then go and describe the GPL using language that describes how viruses work and kill things. . .
Yeah, unintentional, I know. But that's why people use the word "viral." It is these subtle things most people aren't that familiar with that makes GPL so insidious. Perhaps Slashdot readers are familiar with the endless debates over GPL. However not everyone is. When some manager finds these things out.
I agree with those who say it is the users duty to read the license restrictions. But realize that those who then reject GPL software likely are doing it because they don't want this "anti-copyright" virus. If some do and see some benefit from the virus, more power to them. Lots of things that are negative to some are positive to others.
The virus metaphor is so apt because what uses the GPL code is "contaminated" in a way that most libraries don't do. I'm all for open software, but prefer licenses like BSD's which doesn't have these hidden anti-capitalist or anti-copyright policies.
Re:The GPL is not viral. (Score:3, Informative)
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
Re:The GPL is not viral. (Score:5, Insightful)
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.
That's right. GPL'd code reaches up, grabs you by the throat and makes you insert it into your project.
Oh, you mean it doesn't?
Then, it must, by itself, open your code in your favorite editor, and type itself into your code?
Oh, it doesn't?
Gee then you must be a fucking dumbshit, since your code got the GPL-ness in it because you included GPL code in your code. Because that's the only way it can happen.
CHrist, how many times does it have to be said? If you don't wnat your code GPL'd, don't use GPL'd code in your code. Even a moron like you should be able to undestand that.
Now this issue of using the LPGL .jars, it looks to me like you escape your whole work being LGPL' if you "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, if you dind't actually incorporate the libraries into your code, ocne again you are OK.
Big difference between GPL and LGPL (Score:5, Insightful)
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 [gnu.org]:
"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
Re:Almost.. (Score:3, Insightful)
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.
I have to agree (Score:2, Insightful)
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.
Re:The GPL is not viral. (Score:3, Insightful)
Obviously if you don't use GPL'ed code, then you have no problem. Equally obviously, then, that can't be what people are talking about when they say it's viral.
The GPL has the property that, if you derive a project from code covered by it, your own code must also be covered by it. Most licenses don't have that property. So, if your 10,000 LOC project has 50 LOC covered by the GPL, you must license the whole thing under the GPL (in which case the GPL has effectively tra
It means what it means (Score:2, Insightful)
OK, so we need a new license (Score:4, Insightful)
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...
And I suspect most of us feel the same way... (Score:4, Insightful)
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.
Re:And I suspect most of us feel the same way... (Score:3, Interesting)
We now have official confirmation that this is the case, even if that is not what people who released LGPL java code intended. Maybe those people need to rerelease their code as GPL to formalise the outcome.
The effective result is that Apache Java projects are forbidden from linking to LGPL libraries, so we either go without the code or reimplement it -a loss eith
Re: New license - JLGPL ? (Score:3, Insightful)
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 c
Re:And I suspect most of us feel the same way... (Score:3, Interesting)
Mozilla's license is a GPL/MPL/LGPL trilicence. This means you can use any Mozilla code under any of those licenses. The MPL allows withholding modifications.
Now khtml is LGPL -- a stricter license than the above (for obvious reasons). So khtml may borrow any Mozilla code it wants to (and Safari has), while the converse is emphatically not true. So we get the sort of 1-way sharing of code that the GPL is trying to prevent... but in the direction _opposite_ the one
the slashdot story is mis-interpreting the post (Score:4, Insightful)
Re:the slashdot story is mis-interpreting the post (Score:3, Insightful)
You are absolutely wrong. What they are really saying is that the LGPL works virtually the same as the GPL when it comes to Java code because Java code doesn't use early linking, everything is bound at runtime, thus there is n
Re:the slashdot story is mis-interpreting the post (Score:5, Insightful)
The JVM plays the same role as bash does: it loads separately packaged programs into memory, and handles messages being sent back and forth, none of which implicates any right held by the copyright holder of either. I my propietary class calls your GPL'd or LGPL'd class, so what!? How is that different than my proprietary bash script calling grep? As long as I don't modify or distribute your code, or copy parts of it into mine, I don't need a licence.
If you say the method calls are me copying your code, I'll argue back that public method names are a fair use for interoperability.
You are not correct (Score:3, Informative)
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.
Re:the slashdot story is mis-interpreting the post (Score:3, Interesting)
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, and 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
Someone has misin
obWhore (Score:3, Insightful)
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?
Viral? Infected? (Score:3, Interesting)
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
Why I don't use the LPGL for Java (Score:2)
If you are really serious about free software. Then you will never use the LGPL [gnu.org].
Re:Why I don't use the LPGL for Java (Score:2)
If I were to use the LGPL, then you could use my libraries without giving me the source to your program.".
but if the other person made improvements or bug fixes to your LGPL code, then he would (have to) share those changes with you. You benefit.
Re:Why I don't use the LPGL for Java (Score:3, Insightful)
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
The phrase in question seems to be: (Score:4, Insightful)
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.
Re:The phrase in question seems to be: (Score:4, Insightful)
Suppose I write a libarary in Java and place it under the LGPL. I also create a jar file for it. You write some code which uses my library and includes some import statements that name a package in my jar. You compile your stuff into a separate package jar. You distribute your jar which contains none of my code source or bytecode other than calls to public methods. I don't see any reason to think the LGPL places any requirements on your jar.
Java's built in class loader seems ideal as a "suitable shared library mechanism". So long as the LGPL library is on the classpath, it will get loaded at run time, as modified or not, and it will work so long as the public method signitures don't change. This is what the LGPL means when it uses "interface" -- it is NOT talking about a declared interface in the Java sense, but simply the public method calls treated as an API.
The difference between the standard contstructor form and the Class.forName form seems like a distinction without a difference to me. Both use whatever library class is on the classpath at runtime and don't depend on it being unmodified aside from the method signatures.
I'm baffled by this article and the claim that the LGPL is problematic in Java. It seems to me that so long as you distribute your code which uses an LGPL class or jar without including your own copy of that LGPL libary, you are fine. Heck, you could even distribute the LGPL library as long as you do it in a separate download.
In fact, I would go one further. Even if the class you are using was full GPL, how does my program care so long as I don't distribute your code? Because of OO encapsilation, my code does not depend on anything other than the public methods I call, and I'm not sure an API can be copyrighted, or if it can that interoperability is not a fair use. What right of yours would I be violating? I'm not distributing a derivitive of your code (unless you think like SCO), nor modifying it. The only thing that I copy is API call signatures. So what?
What about Perl/Python modules? (Score:2, Interesting)
The issue is late-binding. (Score:4, Informative)
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 issue is late-binding. (Score:3, Interesting)
Ah but my point is that if their interpretation of the rules for Java is correct, there IS NO vice versa. Because everything is late-bound. If everything is runtime-bound, how do you specify what 'direction' the linking is going?
Worthless, no information (Score:2)
Please repost when your article and or references actually contain information worthy of discussion.
I use LGPL on some of my java code. Why ClassForName is supposed to be special I have no idea. I am lost here. a jar file is no different in usage from a DLL, so their really needs to be some support of these ideas...
Re:Worthless, no information (Score:2)
I just re-read clause 6 in its entirety and don't see the problem. But maybe thats because I consider a jar equivalent to a dll. *shrug*
Re:Worthless, no information (Score:2)
-m
Viral... (Score:2, Funny)
What's the issue, exactly? (Score:2)
FSF's interpretation are not very relevant (Score:4, Insightful)
One example of one such non-standard interpretation is the "Lisp LGPL", used by Franz [franz.com] 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 [franz.com] 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).
Courts interpretations might be -- litigated? (Score:3, Insightful)
Re:FSF's interpretation are not very relevant (Score:4, Insightful)
If, for example, SCO got to tell IBM, "well, our interpretation of the license for UNIX means that you can't put code from Sequent into Linux," then IBM would be quite unhappy about the results.
I think the point of confusion here is history. Long ago, Linus made a big splash when he stated his interpretation of the GPL for purposes of binary-only drivers. A lot of folks walked away from that assuming that that meant he had the ability to retro-actively interpret ambiguity in the GPL.
That was not at all the case. What Linus was doing was essentially making a promise to holders of this ambiguous license (and the GPL *is* ambiguous on that point, IMHO) that he was interpreting the license in the most liberal possible way, and thus no one need fear that he would sue them over it.
He could still sue, of course, but his public statements would weigh heavily against the outcome (the scary part for businesses is that you still run into litigation risk regardless of the fact that the cards are stacked in your favor).
On the other hand, if Linus had said, "I'm interpreting the GPL to mean that you can't link your binary-only driver into Linux without creating a derived work which may only be distributed under the terms of the GPL," then the ambiguity would still remain, and no one would be sure if Linus was right or wrong about that until precident was set in court (which it probably has in other contexts outside of the GPL, but I'm not at all sure about that).
The same thing happens if I say, "I interpret the GPL to mean that you [can/cannot] distribute my software on DVD media." My interpretation is just that, and does not affect you at all. You might, of course, think to yourself, "hmm... this guy is interpretting the GPL in exactly the same way a first-class nut-case would... perhaps I should use some other software."
That's fine, you can feel that way, and I would not blame you in the slightest. But that social dynamic does not change the essence of the GPL, nor our agreement as stated in the GPL.
Re:FSF's interpretation are not very relevant (Score:3, Informative)
That's not true. FSF can only enforce the (L)GPL for programs on which FSF holds copyright.
Re:FSF's interpretation are not very relevant (Score:5, Informative)
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).
GPL only covers distribution (Score:2)
Once a user has the code, they can do whatever they want with it, right? So, you can distribute your java code, and it will try to import the library, and they can go get the library, and it will work, right? Even with GPL code... You don't have to have the source for it to work. How can their license affect what you have to do?
Not his call (Score:4, Insightful)
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 about languages that don't compile? (Score:4, Interesting)
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.
Misleading article (Score:5, Informative)
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.
Re:Misleading article (Score:4, Interesting)
Check my history for the last message I posted on this.
Re:Misleading article (Score:5, Interesting)
However, you can use a plugin model to use an LGPL library without directly importing it. You write an interface that your code imports, and write an implementation that imports both your interface and the LGPL library. The implementation of your plugin interface is now LGPL, inherited from the LGPL library. However, your code that that simply imports the interface is not LGPL.
If you are wondering how the implementation class every gets instantiated without refering to it at compile time, then you are not an experienced Java programmer :-) The answer is that your factory class reads a config file to get the name of the implementation class, and then loads it via Class.forName() (or one of the more complex ClassLoader APIs).
Now, your application has avoided becoming LGPL (except for the small class that implements the plugin API). Furthermore, you are conforming to the spirit of the LGPL because users of your application can easily adapt any future version of the LGPL library - or even their own innovation implementation - using your plugin API, and the working source you provide to 'plugin' the LGPL library.
For illustration, suppose there is an LGPL library to translate any text from one language to another. It provides a Translator class (sorry, Slashdot doesn't seem to let me indent the code):
Now, you want to use this in your BSD license UberChat application. You can't just use Translator, because then your app would need to be LGPL as well. Instead, you define an interface:Then, you make a plugin that implements the Translator interface. Your plug in is LGPL because it uses the LGPL library.Finally, you need a factory class to obtain a Translator instance:Finally, using the plugin is simple:And, while none of this is tested, presumably with "fsf.goodies.C3P0" as the value of the "translator" property in your configuration framework (now included with Java 1.4), runningshould result in an output of:Re:Misleading article (Score:3, Informative)
This is where you're wrong. You can always link (2-clause) BSD licensed code with code of any other license, including the (L)GPL, without relicensing the BSD code. It's not like you link with the (L)GPL and suddenly your code is required to be less free -- your code can be released under whatever freer than the (L)GPL license you prefer, and linking wi
Java OOPness is the real issue (Score:3, Interesting)
Yes, that David Turner (Score:5, Informative)
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 (Score:3, Funny)
It's almost scary how non-obvious that is.
Re:Yes, that David Turner (Score:3, Funny)
Google used some GPL code right behind the button "I am feeling lucky". So the button, using the GPL code, is infexted and behave accordingly. It's a perfect illustration that the viral nature of GPL is not bad - it's rather very useful.
Okay, let's hash this out then... (Score:5, Insightful)
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.
Re:Okay, let's hash this out then... (Score:3, Insightful)
Distributing a jar, along with some code which will end up calling code from that jar, is linking to that jar. The actual bindings are resolved at runtime (although as I understand it, the jar needs to be present at compile time too), but it's still linking.
If you use this as your definition of "linking", then "linking" loses all purpose and meaning.
According to your definition, it appears that any two binaries loaded in memory, where on calls the other, are "linked", regardless of wether or not the cod
Oops, revision! (Score:3, Insightful)
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
Re:Yes, that David Turner (Score:4, Informative)
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 (Score:5, Informative)
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.
Re:Yes, that David Turner (Score:4, Informative)
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 (Score:5, Informative)
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:
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 (Score:3, Funny)
The LGPL isn't the GPL. If you want the GPL, you know where to find it.
Bunch of Crap! (Score:5, Informative)
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.
Please, people (Score:5, Informative)
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.
That's not what Mr Turner said (Score:4, Informative)
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 (Score:5, Informative)
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
Re:Clarification from FSF on Section 6 of LGPL (Score:3, Informative)
LGPL: Lesser General Public License (Score:3, Informative)
You can read about here: http://www.gnu.org/copyleft/lesser.html [gnu.org]
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...
Re:Huh? (Score:4, Funny)
Re:we gotta break FSF (Score:3, Insightful)
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