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."

great, microsoft succeed again

they coined the term "viral" with respect to software licenses, and now everyone's using it.

good stuff. :\

Re:The GPL is like a Vaccine

It all depends on which side of the coin you're looking at. Commercial software venders see the GPL'ed code as a risk to their IP. Alas, viral is a bad word to describe this any ways. Recursive licensing sounds better :)

Re:The GPL is like a Vaccine

Ok, I'm not quite sure you understand what they mean by "viral" here. I think what they are saying is that code written that includes the LGPL'd Java libraries inherets the LGPL. So basically, if you include one of these libraries your code MUST be LGPL'd. This is obviously a problem.

Re:The GPL is like a Vaccine

If I decide to write a program and contribute it to free software, the GPL assures me that it will stay free software forever.

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

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.

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

You ever get the sense that some of the people who post about the GPL have absolutely no idea what they're talking about?

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

You forgot the group that wants to release their code but they also want the assurance that anyone making additions shares back.

Re:great, microsoft succeed again

[microsoft] coined the term "viral" with respect to software licenses, and now everyone's using it.

Are you sure? My 1992 copy of the New Hacker's Dictionary contains a reference to the `General Public Virus', and I don't recall MS even having heard of the GPL back then...

GPL model

I know a way they can handle their GPL model..

Just ask SCO!

"If it is not OUR's then it must be Viral"

No problem.

Just switch to the BSD license, like the Vorbis project did.

Re:No problem.

I am a Java developer, and I have used the LGPL on work (and also used work that has been LGPL'ed).

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.

Perhaps you need to make an effort to understand the reasons people
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.

I know the other comment-replies to this post have been marked -1 for one reason or the other, but in all honesty I couldn't agree with you more.

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.

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.

connotation

...That's what viral means. It doesn't mean that the license in and of itself is evil or incorrect or otherwise wrong....

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.

What are you smoking? I want some of that.

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.

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.

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.

It's a tool intended to destroy copyright from within.

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.

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

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 [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

OK, so we need a new license

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...

And I suspect most of us feel the same way...

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.

the slashdot story is mis-interpreting the post

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.

Re:the slashdot story is mis-interpreting the post

But there is a clear distinction. The LGPL library is loaded from one jar on the classpath at runtime and the rest of the code is loaded from somewhere else. They're clearly separable. If you modify anything in the LGPL jar (or class) and distribute it, you must include full source to everything packaged in that jar, but if you don't do that you are fine, even if you're dealing with full GPL java code.

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.

obWhore

The site's awfully slow already; I suspect it's going down soon, so here's the content:

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:

Brett Smith referred me to you regarding a question regarding the Lesser Gnu Public License (LGPL) in regards to Java. It is the interpretation of most of the open/free software communities that the use of a "jar" file by a piece of software linked via a Java "import" statement does not bind the linking work under the terms of the LGPL. The Apache Software Foundation, presently takes a more conservative view and thus projects of the ASF are not allowed to link/distribute LGPL programs into Java projects of the foundation.

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:

Sorry I haven't been on the list more, been traveling the last week. At any rate, Andy, did you ever get a resolution to including the HTMLParser Jar?

Should I just submit a code change the mimics the code that I need from HTMLParser, I mean, it is just a long list of values being populated into a Map! That is all I really want, versus sophisticated translation of character set logic or something...

Thanks for your efforts... eric

--
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?

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 :)

The phrase in question seems to be:

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:

I'm really baffled by what the issue is. It appears to me that the LGPL works just fine for Java.

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?

The issue is late-binding.

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.

FSF's interpretation are not very relevant

The FSF's interpretation of the LGPL only applies to software owned by the FSF. If I had a different interpretation of the LGPL (which is certainly possible -- many parts are quite vague), that interpretation would apply to my software, and the FSF can do nothing about it.

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).

Re:FSF's interpretation are not very relevant

Technically, when you "LGPL" your code, you sign away license rights for that software release to the FSF. That is why if someone violates the license of your GPL'ed program, the FSF can step in (with their lawyers) to defend your licensing rights. You are still the program's copyright owner, and you can reissue your program under another license if you like (though you can't "retract" your original release).

Pretty much everything in that paragraph is WRONG. First, unless you EXPLICITLY re-assign your copyright rights to the FSF, they do not own the copyright and cannot defend your rights. That certainly does not happen automatically. Unless your software says "copyright (C) 2003, the Free Software Foundation", it's not theirs and they cannot enforce your copyright.

Second, if you do re-assign the rights to the FSF, you are no longer the owner and may not reissue the program under any other license. You would only have the rights afforded to you by the GPL.

Third, you may not modify the LGPL or the GPL in any way. It violates the FSF's copyright and is not allowed. Read the license -- "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." (emphasis mine, obviously).

Re:FSF's interpretation are not very relevant

There's a flaw in your logic. You cannot retro-actively interpret a license. The license is an agreement. If you then decide that the agreement "really means" something other than what I think it means, we have a dispute. We can settle it between us by altering the agreement to be clear on the point, or either one of us can take the matter to court for resolution. This happens all the time. What you meant for the agreement to say is beside the point unless we had some form of verbal or implied understanding at the time.

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.

Not his call

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.

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?

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.

Misleading article

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.

Re:Misleading article

I said it before and I'll say it again: The "import" statement is a language construct ONLY. No actual linking is done by using it.

Check my history for the last message I posted on this.

Re:Misleading article

The 'import' statement in Java doesn't actually link anything - it is just a namespace declaration. However, when you refer at compile time to methods, fields, and constants in another class, the compiler actually reads in that class and does the equivalent of '#include done right'. This makes Java code that directly refers at compile time to LGPL code a derivative work.

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):

/* LGPL license */
package fsf.goodies;
import java.util.Locale;
public class C3P0 {
public String translate(String msg,Locale src,Locale dst) {
/* magic AI code here */
}
}

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:

/* BSD license */
package org.bsd.uberchat;

import java.util.Locale;

public interface Translator {
String translate(String msg,Locale src,Locale dst);
}

Then, you make a plugin that implements the Translator interface. Your plug in is LGPL because it uses the LGPL library.

/* LGPL */
import fsf.goodies.C3P0;
public class C3P0Plugin implements Translator {
/* in this trivial example (except for C3P0, that is), nothing more is required. In real life, you might need to massage arguments and do other processsing to match the interface with the implementation. */
}

Finally, you need a factory class to obtain a Translator instance:

package org.bsd.uberchat;

public class TranslatorFactory {
/* Actually, there are more exceptions that needs to be handled in a real factory class. */
static public Translator getTranslator() {
Config config = new Config("uberchat");
String cname = config.getString("translator");
Object trans = Class.forName(cname);
if (trans instanceof Translator)
return (Translator)trans;
throw new RuntimeException("translator plugin does not implement the proper interface");
}
}

Finally, using the plugin is simple:

package org.bsd.uberchat;
import java.util.Locale;

public class Foo {
static public void main(String[] argv) {
Translator t = TranslatorFactory.getTranslator();
String msg = t.translate(argv[0],Locale.US,Local.GERMAN);
&nbs p; System.out.println(msg);
}
}

And, while none of this is tested, pre

Yes, that David Turner

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.

Re:Yes, that David Turner

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

Oh, wait, now I actually read your post, and realize that you are still completely confused. Sorry.

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: ...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.

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

The problem is that CowboyNeal didn't call me first.

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

1. Make sure your licensing follows the simple requirements in the 1st para of section 6.

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.

Okay, let's hash this out then...

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.

Bunch of Crap!

This material should be considered akin to shouting fire in a crowded theatre when there isn't a spark around for miles.

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 ../lib/ext directory just for the explicit purpose of dropping in your libraries and any third party libraries.

BTW, once in the ../lib/ext directory the library is effectively shared for any Java program utilizing this particular JRE installation.

2. Put your own libraries in the ../lib/ext directory.

3. Put the third party library in the ../lib/ext directory.

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

Go back and read the LGPL again. The terms in Section 5/6 are not the terms commonly used with Java, sure, but the intent is pretty much crystal clear. If you use material from header files (read: interfaces or general class descriptions - the stuff that goes in header files in the C world) to make calls into the classes falls outside the scope of the license. The LGPL is no more or less befuddling with respect to Java then it is with respect to other languages. Likewise, the relationship elucidated between your object code and the LGPLed object code, whether it be in JAR or DLL format, isn't terribly different. If you contain or reuse too much of a library in your code, there's always a fuzzy, slippery slope of what constitutes a derived work. Again, this is really no different from the way the LPGL would apply to C/C++.

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

I quote Mr Turner's statement in its entirety:

DT: This sort of linking falls under section 6 of the LGPL.

He does not answer in the affirmative, nor in the negative. He merely points at section 6. He does not even offer any interpretation.

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

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

LGPL: Lesser General Public License

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 [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?

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.