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

Comments

great, microsoft succeed again

[Anonymous Coward]

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

good stuff. :\

No problem.

[Blackknight]

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

Re:No problem.

[keesh]

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.

[Michael's a Jerk!]

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.

[SuperDuG]

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.

[oGMo]

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.

[alienw]

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.

[fanatic]

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.

OK, so we need a new license

[bokmann]

I am a Java developer, and I have used the LGPL on work (and also used work that HAS been LGPLed).

My intent in using the LGPL is pretty simple: If you want to use my library, go ahead. If you make CHANGES to my library, those have to be released back into the wild, so the library can be improved by everyone's improvements. I'm not a 'Free Software' zealot - I'm an open-source pragmatist.

If the LGPL does not meet this intent with Java, then we should find or write a license that has this intent. Perhaps one of the ones at Creative Commons would work...

the slashdot story is mis-interpreting the post

[Anonymous Coward]

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

[bwt]

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.

Re:The GPL is like a Vaccine

[pstreck]

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

The issue is late-binding.

[carlfish]

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.

Big difference between GPL and LGPL

[IntelliTubbie]

You have a choice. The [L]GPL is not a little bug trying to worm its way into your code. If you chose to use GPL code, then you follow the terms, or don't use the code. It's simple.

You seem to miss the entire point of the LGPL. The whole point is that you should be able to use LGPL code in a non-LGPL project. To quote from the website:

"The choice of license makes a big difference: using the Library GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs."

So whereas the GPL is intended to be somewhat "viral" -- i.e. software using GPL code must also be GPL -- the LGPL is not supposed to. This is why the viral-ness of the LGPL is news, since it's contrary to much of the community's understanding and intent regarding the use of LGPL code.

Cheers,
IT

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

[sterno]

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.

Re:The GPL is like a Vaccine

[mjmalone]

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.

Misleading article

[timsuth]

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

[CustomDesigned]

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, presumably with "fsf.goodies.C3P0" as the value of the "translator" property in your configuration framework (now included with Java 1.4), running

java org.bsd.Foo "Good Day!"

should result in an output of:

Guten Tag!

Yes, that David Turner

[prizog]

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

[prizog]

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

[prizog]

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.

Re:The GPL is like a Vaccine

[William Tanksley]

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

Bunch of Crap!

[OYAHHH]

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

[Fnkmaster]

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.

Re:The GPL is like a Vaccine

[JonMartin]

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

[JonMartin]

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:FSF's interpretation are not very relevant

[alienw]

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

connotation

[Kunta Kinte]

...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 like a Vaccine

[Breakfast Pants]

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

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

[Otto]

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.

Clarification from FSF on Section 6 of LGPL

[bkuhn]

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