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

Re:The GPL is not viral.

[TheAJofOZ]

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.

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 author (and copyright holder) intended you to be able to.

Viral? Infected?

[foolip]

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

What about Perl/Python modules?

[avida]

So does that mean if I have a Perl or Python module under the LGPL that is used/imported into a project, the LGPL applies?

What about languages that don't compile?

[JanusFury]

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.

Re:The issue is late-binding.

[MisterFancypants]

No, I think the argument is that a (L)GPL body of code can link with a proprietary body of code, but vice versa is not the case.

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?

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

Re:The GPL is not viral.

[WatertonMan]

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 phrase in question seems to be:

[pohl]

Strange. This entire panic appears to have been created by an overly-literal interpretation of the word "interface" in the LGPL...as if it must be what Java programmer's think of as interfaces (method signatures without implementation). I'm willing to bet dollars-to-donughts that this is not what was intended in the context of the LGPL, and that any method-signature-compatible and namespace-compatible concrete classes would count as being "interface-compatible".

Re:Misleading article

[AKAImBatman]

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:And I suspect most of us feel the same way...

[steve_l]

The apache interpretation has always been: every java app is a jar', so every app is a library, so for java, LGPL has the same semantics as GPL.

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

Re:Why I don't use the LPGL for Java

[rking]

You don't gain anything by GPLing your software except for the satisfaction that no one will probably ever make a profit off of it.

If the program's useful then there's every chance that people will profit off of it. To suggest otherwise is just silly. Companies large and small all over the world use GPLd software in their businesses. The GPL does not seek to prevent this.

Fear

[gtshafted]

I work for a large consulting company and one of our clients is a large telecom company in the south. This company is very much against open source, due to unfounded paranoia and misinformation.

They think 1) open source code's quality is much less than commercial closed source code
2) the open source code has malicious intentionally hidden 'backdoors' and 'viruses' and 3) that open source could threaten our projects from a legal standpoint (intellectual property etc)

Recently our company has been making small strides in changing our client's attitude. News like this kills our efforts (giving more power to ignorant people against open source) and only slows down open source's adoption...

Hell, I can't use anything from Apache - like Struts or anything else from Jakarta! Reading some of the posts (and my initial reaction to the main one) it sounds like many people are happy because of this... well for me this sucks!

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!

In my Mac OS X app...

[g0at]

In Doggiebox [doggiebox.com], I use routines from libsndfile [zip.com.au](an LPGL library C library). Since Doggiebox is written in Objective-C, I've also written a bunch of wrapper code to make libsndfile more convenient to use. I'm bundling this wrapper code into ZygoatAudio, a Mac OS X framework which statically links libsndfile. ZygoatAudio itself is presented as LGPL, and dynamically loaded by Doggiebox at runtime.

I've done it this way because my understanding is that I can't just static link libsndfile into Doggiebox without opening the whole Doggiebox source. On the other hand, I am happy to disburse code for ZygoatAudio (there's no web page yet since it is still too much in flux), and my understanding is that this dynamic loading issue takes care of LGPL requirements. If someone wants to re-engineer ZygoatAudio and drop it into Doggiebox, as required per LGPL, they can.

Is my approach correct?

-ben

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

[BZ]

Sure. And here is why it's a problem.

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 GPL is trying to prevent.

And that makes GPL just as bad as the commercial licenses, in this respect.

Java OOPness is the real issue

[mabhatter654]

Because Java makes such extensive use of OOP priciples, it would be possible to "rewrite" entire libraries by operator overloading the entire class. You'd be changing their libraries but claim you're not technically breaking the rules of LGPL. The FSF says you need to maintain a clear distinction between the seperate file. You should be able to drop-in-replace any newer version...again, if you're following the rules then you're OK. This really only applies to a small number of rules lawyers attempting to "play" the rules.

Note: this was also an issue in the design of the 2.5 kernel with driver developers "overwriting" large portions of the kernel in their closed drivers by calling a lib properly but then "redirecting" all the stuff internally to their own stuff. [a certian GPU developer may get bit by this]

Re:The GPL is like a Vaccine

[Anonymous Coward]

What about "communism" then?

Re:The GPL is not viral.

[aug24]

that's like saying cholera is not bad as long as I don't catch it

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 slashdot story is mis-interpreting the post

[jrumney]

The only comment from "the FSF-license guy" in he linked article is:

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

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 misinterpreted the comment to mean the opposite and we now have articles being printed left right and center spreading FUD about the LGPL and Java. Thanks a lot Slashdot, Microsoft couldn't have done it better.

This is a farce

[Srin Tuar]

Anyone who was pissed off would probably be so because you substituted a less freely usable license for a more free one.

A BSD licensed piece of code is only more freely usable from one persons point of view: the next developer.

Once he commercializes it, it will certainly become less freely usable to the end users who ultimately receive it.

So in the balance, BSD code is LESS freely usable than GPL. The GPL is the same free to everyone. There are tons of BSD bits that are free to almost nobody.

Its your prerogative to license things as you like, but dont say its "freer as BSD" because its just not true, unless you dont care one whit for the end users of a commercialized version.

Re:The GPL is not viral.

[Minna Kirai]

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

Irrelevant

[msobkow]

My point is that it's my source code I want kept free and up to date.

I don't care if you use some of it, all of it, or none of it. I don't care what compiler you use, how you link the code, or what kind of applications you are building.

If print media comparisons are the problem, then software should be under a seperate set of laws. Software is not print media.

Source code is more like a blueprint or a recipie. It would be absurd for me to post a recipie for everyone to use, then complain about the way people were eating the food their chef produced. The chef's preparations are analagous to compiling the code, while linking is whether the consumer chooses to eat with their fingers, a knife and fork, chopsticks, etc.

My only legitimate cause for complaint is if they change the recipie, don't tell anyone what they changed, and either claim it as their own or fail to let others know it's not quite the same (don't publish changes.)

Static linking is a very common QA requirement for production applications. Trying to ban static linking is just plain ignorant, and there is no way you can convince me otherwise.

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

[Planesdragon]

If one of us is a zealot, I think it's the one attacking the GPL because it doesn't let him horde other people's work.

Sheesh. I'm not a coder, I'm a /.er. It's possible to not toe the FSF party line and still support OSS, believe it or not.

Let's say that I write a program, and I give you a copy--this is copyright law, and you don't have the authority to make any copies not necessary for your own use of the program. (backups, quotations, whathaveyou.)

Now, let's say that I tell you "you can distribute that software or make derivitive works based on it." I've now given you something of value. Woot. Go sharing.

However, I _also_ say "If you give that software to anyone else, you have to follow this license. By doing this, I have taken something of value from you--a promise to behave a certain way.

Are you better off than you were before we started out this transaction? YES! Do you have every liberty that you had before we did our transaction? YES!. Did this transaction involve taking one of your liberties away? YES.

This is a semantics argument. That's all. Don't get your panties in a knot that I'm not adding "Gnu" when I say "Linux." The FSF's tendancy to do that banishes them to the political corner reserved for ecoterrorists, liberterians, and other zealots.

You should realize that there isn't a difference between "contract" and "license." Both define a transaction wherein something of value is exchanged for something else of value. If I give you one million dollars but stipulate that you have to buy every homeless man you meet a dinner, I've offered a contract wherein I give up my posession of one million dollars (a thing of value) and you give up your liberty to not buy homeless men dinner (a thing of value.)

If I form a PAC that goes around saying that all homeless men should always be bought dinner, it doesn't somehow magically make your thing of value value-less. In a like vein, the FSF's widely stated belief that all source code should be free for all to do what they wish with does not somehow make the right to not distribute the source code of your own innovations a thing of value.

Heck, the GPL also requires you to identify your changes--a small thing, and a very reasonable thing, but still a thing of value.

I like the GPL. It's good to have someone standing up for community-made software. It's great to have bundles of free software that are out there for the use and the taking.

But the GPL is a contract, and contracts have, as a matter of law, consideration (things of value) exchanged between both parties. They're not fundamental rights that are exchanged--but, when dealing with capital-R rights, not even a dreaded EULA can squash them.

Re:The GPL is like a Vaccine

[Directrix1]

Heres how you avoid the viral GPL situation. The process:
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 SASL library. No problems, its a seperate GPL'd plugin library which implements the interfaces my classes need. At no point in my non-GPL'd code do I import it, so at no point do I have to relicense. Oooh, hard. BTW, the rest of my code is Apache licensed, I'm not just trying to rip off the open source world :-P.