Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

LGPL is Viral for Java

CowboyNeal posted more than 11 years ago | from the careful-code-reuse dept.

GNU is Not Unix 717

carlfish writes "According to this post to POI-dev, Dave Turner (Mr License) of the FSF has decreed that the steps required to use an LGPL'd Java library will actually infect client code with substantial GNU-ness via Section 6 of the LGPL. (The "Lesser" GPL is supposed to protect only the Library, without infecting code using the library) This, as you might imagine, puts a few LGPL Java projects that previously thought they were embeddable without being viral in a bit of a bind. Various weblogs have further coverage." Update: 07/18 02:44 GMT by CN : The FSF's Executive Director, Brad Kuhn adds "LGPL's S. 6 allows you to make new works that link with the LGPL'ed code, and license them any way you see fit. Only the LGPL'ed code itself must remain Free. Such 'client code' can even be proprietary; it need not be LGPL'ed."

Sorry! There are no comments related to the filter you selected.

GNAA does not like java (-1, Troll)

Anonymous Coward | more than 11 years ago | (#6466364)

GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the first organization which
gathers GAY NIGGERS from all over America and abroad for one common goal - being GAY NIGGERS.

Are you GAY?
Are you a NIGGER?
Are you a GAY NIGGER?

If you answered "Yes" to any of the above questions, then GNAA (GAY NIGGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join GNAA (GAY NIGGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time GNAA member.
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the fastest-growing GAY NIGGER community with THOUSANDS of members all over United States of America. You, too, can be a part of GNAA if you join today!

Why not? It's quick and easy - only 2 simple steps!

First, you have to obtain a copy of GAY NIGGERS FROM OUTER SPACE THE MOVIE [imdb.com] and watch it.

Second, you need to join the official GNAA irc channel #GNAA on EFNet, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today!

If you are having trouble locating #GNAA, the official GAY NIGGER ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is EFNet, and you can connect to irc.secsup.org or irc.isprime.com as one of the EFNet servers.

If you have mod points and would like to support GNAA, please moderate this post up.

This post brought to you by a proud member of GNAA

________________________________________________
| ______________________________________._a,____ |
| _______a_._______a_______aj#0s_____aWY!400.___ |
| __ad#7!!*P____a.d#0a____#!-_#0i___.#!__W#0#___ |
| _j#'_.00#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,_ |
| _"#ga#9!01___"#01__40,_"4Lj#!_4#g_________"01_ |
| ________"#,___*@`__-N#____`___-!^_____________ |
| _________#1__________?________________________ |
| _________j1___________________________________ |
| ____a,___jk_GAY_NIGGER_ASSOCIATION_OF_AMERICA_ |
| ____!4yaa#l___________________________________ |
| ______-"!^____________________________________ |
` _______________________________________________'

So make a JLGPL? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6466378)

n/t

great, microsoft succeed again (5, Insightful)

Anonymous Coward | more than 11 years ago | (#6466384)

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

good stuff. :\

The GPL is like a Vaccine (3, Insightful)

Michael's a Jerk! (668185) | more than 11 years ago | (#6466468)


This viral stuff is backwards. I think the BSD license is actually more
viral than the GPL. Here's why:

If I decide to write a program and contribute it to free software, the
GPL assures me that it will stay free software forever. I'd be bothered
if somebody made it non-free, effectively stealing my work for their
own remuneration. The GPL is effectively a vaccine against that.

The BSD license lets people apply almost any license to my software,
including most non-free licenses. If I wrote work under the BSD license,
someone could modify it and sell the result with no source code, and
I'd have no recourse at all. Anyone who wants can infect my BSD software
with the non-free license virus.

So, which license is more viral? It sounds to me as if the GPL is getting
a bum rap here.

By the way, the BSD license allows you to apply the GPL to a modified
BSD work. I've thought about organizing a GPL-ed thread derived from the
body of existing BSD-licensed work, just to illustrate a lesson about
the BSD license. That would really piss people off, but it would be legal.

Re:The GPL is like a Vaccine (0)

Anonymous Coward | more than 11 years ago | (#6466520)

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

Hmm... could it be? Nahh.

Re:The GPL is like a Vaccine (0)

Anonymous Coward | more than 11 years ago | (#6466546)

Or for the BSD license, especially.

The Apache folks are smart to use a BSD license. The Jakarta stuff kicks ass, and there are no concerns with my using it commercially. We can use it commercially, we can help them develop it publically, it's a win-win for everybody.

With the [L]GPL stuff it gets very murky legal waters and we avoid that shit like the plague.

Re:The GPL is like a Vaccine (4, Funny)

pstreck (558593) | more than 11 years ago | (#6466523)

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 (0)

Anonymous Coward | more than 11 years ago | (#6466535)

Yeah, that's why I prefer the GPL. You should actually do this to a certain project. It would be a good case example. Especially if you got sued by BSD people!

Re:The GPL is like a Vaccine (4, Informative)

mjmalone (677326) | more than 11 years ago | (#6466589)

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 (0)

Anonymous Coward | more than 11 years ago | (#6466661)

> By the way, the BSD license allows you to apply the > GPL to a modified BSD work. I've thought about
> organizing a GPL-ed thread derived from the
> body of existing BSD-licensed work, just to illustrate
> a lesson about the BSD license. That would really
> piss people off, but it would be legal.

Good day to you troll :)
Don't want to spoil your day, but that has been done before, and it didn't piss people off. Actually, most people who advocate the BSD licence think it is pretty funny to see pieces of BSD derived code turn up everywhere in the GNU/Linux world.

That that can happen is exactly the point of the licence. You may want to realize that without it we'd still have had commercial software, but the standarisation of netowrking protocols that resulted in the internet would never have happened since that commercial software wouldn't have had the ice option of using BSD code for it, and GPL code would not have been usable.

Re:great, microsoft succeed again (3, Informative)

TheRaven64 (641858) | more than 11 years ago | (#6466505)

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

Google cached article (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#6466388)

Re:Google cached article (0)

Anonymous Coward | more than 11 years ago | (#6466402)

I had no idea java programming would need to be so painful.

Huh? (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#6466396)

For those of us who actually have sex with biped (warm blooded) members of the OPPOSITE sex, can you Linux people please explain what the hell "LGPL" is?

Re:Huh? (0)

Anonymous Coward | more than 11 years ago | (#6466408)

For those of us who actually have sex with biped (warm blooded) members of the OPPOSITE sex, can you Linux people please explain what the hell "LGPL" is?

What??? You have sex with sheep?

Re:Huh? (1)

woodhouse (625329) | more than 11 years ago | (#6466431)

Sheep are quadrapeds

Re:Huh? (0)

Anonymous Coward | more than 11 years ago | (#6466469)

Sheep are quadrapeds

What??? You have sex with apes?

Re:Huh? (0)

jinglecat (673072) | more than 11 years ago | (#6466485)

Not always, there is a process called "Lunch" in which they have no legs at-tall. /english_voice.

LGPL: Lesser General Public License (2, Informative)

jbuilder (81344) | more than 11 years ago | (#6466421)

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? (3, Funny)

jedidiah (1196) | more than 11 years ago | (#6466425)

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.

Re:Huh? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6466475)

Kangaroo's?

How about not using the word `viral'? (0, Redundant)

UnderScan (470605) | more than 11 years ago | (#6466407)

It has too many negative connotations. `Viral' is too closely related to virus, worm, exploits etc.

The FSF & those posting in their blogs need to choose a better word. One Bill CIOofSomeCorp gets wind of Free Software being viral ... well it is all down hill from there.

Re:How about not using the word `viral'? (1, Funny)

jinglecat (673072) | more than 11 years ago | (#6466441)

It does have negative attributes to it.. And I for one, don't like the term because when I read viral...

... I subconsciously think Virile.

Nasty habit, really.

Re:How about not using the word `viral'? (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#6466498)

It does have negative attributes to it.. And I for one, don't like the term because when I read viral... ... I subconsciously think Virile.

The problem is that excessively virile people usually become excessively viral people (especially gay niggers).

Re:How about not using the word `viral'? (1)

MilesParker (572840) | more than 11 years ago | (#6466477)

Hey, don't be so-postmodern!* Seriously, words aren't responsible for how they are used. It is descriptive, evocative, and in common usage. What other word captures the mechanism so well? Yes, its analagous to disease, but it is also directly analagous to the way many kinds of ways that information self-replicate and spread. And anyway, or own fear of viruses is certainly anthropomorphic, and -- knowing just enough about micorbiology to be dangerous -- may be more neccessary to genetic processes than we think. (*See "State of the Onion" post.)

GPL model (3, Funny)

jinglecat (673072) | more than 11 years ago | (#6466409)

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

Just ask SCO!

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

This is good news! (0)

Anonymous Coward | more than 11 years ago | (#6466422)

This will speed up the adoption of real VMs (read : mono). Nothing but crap has come from Sun recently like their bloated OpenOffice, their castration of GNOME not to mention their crappy CDE desktop. I hope Sun crashes burns and leave the OSS world to a mono/kde/koffice world which is better than java/gnome/ooo.

-1, flamebait, I really don't care.

No problem. (4, Insightful)

Blackknight (25168) | more than 11 years ago | (#6466423)

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

Re:No problem. (-1, Troll)

jinglecat (673072) | more than 11 years ago | (#6466456)

Yeah.. Switch to that and then wither away and Die.. Just like BSD is doing.

Re:No problem. (5, Insightful)

keesh (202812) | more than 11 years ago | (#6466490)

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. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6466631)

some ballmer boy with mod points modded you wrongly.

it's a shame that slashdot is visited by 65% windows computers and seeded with anti-opensource operatives.

Re:No problem. (5, Insightful)

Michael's a Jerk! (668185) | more than 11 years ago | (#6466494)

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

The GPL is not viral. (5, Insightful)

oGMo (379) | more than 11 years ago | (#6466424)

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

Anonymous Coward | more than 11 years ago | (#6466438)

That's exactly right. Please mod the parent up. The "offer to compensate" part is very insightful :) Also, if you don't use Java for anything anywhere, then your code will work and you will be happier.

Re:The GPL is not viral. (0, Redundant)

ADOT Troll (687975) | more than 11 years ago | (#6466465)

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

Re:The GPL is not viral. (3, Insightful)

The Bungi (221687) | more than 11 years ago | (#6466487)

And again, until you get it

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

The term "viral" pisses people like you off because it's convenient to think that it's a term invented solely for the purpose of turning people off from using it, and that's not the case. In cases like this one (and many others that I won't dredge up right now) the adjective is perfectly applicable - it implies a lack of knowledge as to how the license works and how to use it, but it doesn't make it any less "viral". It was used in ignorance, and now the folks that assumed they were OK find themselves "infected". That's what viral means. It doesn't mean that the license in and of itself is evil or incorrect or otherwise wrong.

Re:The GPL is not viral. (2, Interesting)

TheAJofOZ (215260) | more than 11 years ago | (#6466488)

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.

Re:The GPL is not viral. (1, Insightful)

oGMo (379) | more than 11 years ago | (#6466605)

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.

No, the point is that calling the GPL or LGPL viral is wrong, whether or not it acts correctly in this case. Using the term "viral" is merely FUD-spreading. Saying "the LGPL has bugs when used with Java" would be far more accurate.

Besides, my point stands: you're responsible for knowing the actual terms of the license, not just thinking you know what it means. And you have the choice to follow them or use something else.

Now, if there are bugs with the license in this case, then let's have someone fix them. But spreading FUD is not doing any good.

Re:The GPL is not viral. (0)

Anonymous Coward | more than 11 years ago | (#6466501)

Sorry there, Rich. That time of the month?

Re:The GPL is not viral. (2, Insightful)

William Tanksley (1752) | more than 11 years ago | (#6466534)

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

Saying that it's viral is mere shorthand for that, and you obviously know that (since you define viral in that way).

Now, your prescription to deal with the viralness is quite on-target -- money talks, and coding your own dang solution also works. But this doesn't change the facts about how the GPL works, and how it's intended to work.

Grin... To stretch the analogy, suppose someone claimed that the common cold wasn't viral because you could avoid it by wearing a mask, washing your hands, and staying out of public. I know, it's a stretched analogy...

-Billy

Re:The GPL is not viral. (1)

abe ferlman (205607) | more than 11 years ago | (#6466657)

Grin... To stretch the analogy, suppose someone claimed that the common cold wasn't viral because you could avoid it by wearing a mask

What if they said it wasn't viral because it uses a little bit of benign copyright application to protect a body of code against truly malignant, embrace-extend-extinguish style copyright application? That sounds much more like a *vaccine* than a virus to me.

What you're saying is like scaring the bejesus out of a little kid who just got a polio vaccine by telling them they just got some polio virus shot into them. Even if technically true, it's highly misleading because you didn't give them the virus, you gave them the vaccine.

And to preempt the "but programmers aren't little kids" argument, they are like little kids in their understanding of copyright law. FUD is real folks.

Big difference between GPL and LGPL (4, Insightful)

IntelliTubbie (29947) | more than 11 years ago | (#6466553)

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

Re:The GPL is not viral. (0)

Anonymous Coward | more than 11 years ago | (#6466592)

What you are glossing over is the difference in intention of the GPL and the LGPL

Ignoring the legaleese (which may turn out to be the exact opposite of the common understanding) The LGPL states that you can use the thing I made w/o having to GPL your stuff. If you change the stuff I made, those changes need to be LGPL'd (yes, yes.. only if you distribute...blah, blah, blah...)

This is the understanding under which tons of stuff was LGPL'd and tons of LGPL'd stuff was used. To narrowly constue the legaleese of the licence (which is so C centric as to be absurd) hurts everyone. (Yes I know that RMS hates the LGPL, but in addition to being brilliant, he's an idiot)

The net of the net is that anyone with a brain will say Fsck the GPL. Fsck the LGPL. Fsck RMS. I'll stick with Apache/BSD/etc stuff that doesn't have pages and pages of twisty words associated with it that may or may not limit my options.

Who is better for that?

Re:The GPL is not viral. (0)

Anonymous Coward | more than 11 years ago | (#6466594)

The uncompromising face of idealogically-driven development. Well fuck you - I'd rather use software that has quality as the most important ingredient, not politics.

The GPL is viral. Please stop denying it - and anyone in business, please read that again until you understand that the "Free" software communists will lie to you, until you are firmly in the grip of their lawyers and mouth-foaming ignorant slashbots.

I have to agree (1, Insightful)

abe ferlman (205607) | more than 11 years ago | (#6466612)

This is an interesting topic, but the way the submitter phrases it is 100% pure flamebait.

The GPL (and to a lesser extent the LGPL) is a vaccine for the body of free code (a little bit of benign IP law to save us from the ravages of truly malignant IP law), not a disease you catch accidentally.

Re:The GPL is not viral. (2, Insightful)

p3d0 (42270) | more than 11 years ago | (#6466613)

Have we hit your pet peeve here?

Obviously if you don't use GPL'ed code, then you have no problem. Equally obviously, then, that can't be what people are talking about when they say it's viral.

The GPL has the property that, if you derive a project from code covered by it, your own code must also be covered by it. Most licenses don't have that property. So, if your 10,000 LOC project has 50 LOC covered by the GPL, you must license the whole thing under the GPL (in which case the GPL has effectively transmitted itself to other code) or remove those 50 LOC (thereby innoculating your project).

If you object to the term "viral" being applied to this situation, so be it, but I think it's an apt description, and it's exactly the effect that I think Stallman intended. Regardless, you need to take a deep breath and relax a bit.

BILL GATES WAS RIGHT!!! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#6466430)


Re:BILL GATES WAS RIGHT!!! (0)

Anonymous Coward | more than 11 years ago | (#6466560)

Really?

"640K ought to be enough for anybody."

"I believe OS/2 is destined to be the most important operating system, and possibly program, of all time. "

"There are people who don't like capitalism, and people who don't like PCs. But there's no-one who likes the PC who doesn't like Microsoft"

"It is obvious that we will not include things like threads and preemptive multitasking in Windows."

Re:BILL GATES WAS RIGHT!!! (0)

Anonymous Coward | more than 11 years ago | (#6466591)

"the HURD will be ready soon"

"Linux will dominate the desktop in a few years"

"Richard Stallman has taken a bath"

Re:BILL GATES WAS RIGHT!!! (0)

Anonymous Coward | more than 11 years ago | (#6466653)

""640K ought to be enough for anybody.""

Please tell me the date when Bill Gates said this, and to whom.

Wait... YOU CAN'T!!! Because he never said that.

Whew (1)

Daengbo (523424) | more than 11 years ago | (#6466433)

All I can say is that this is bad shit. How will we get folks to develop from the LGPL now?

Re:Whew (1)

bersl2 (689221) | more than 11 years ago | (#6466483)

How will we get folks to develop from the LGPL now?

Simple. We modify the LGPL to comply with its purpose. The GPL is on version 2, isn't it? Just edit section 6, name it LGPL 2.0, and call it a night.

Now, lemme get around to reading the article.

Re:Whew (0)

Anonymous Coward | more than 11 years ago | (#6466579)

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:Whew (0)

Anonymous Coward | more than 11 years ago | (#6466627)


Simple. We modify the LGPL to comply with its purpose. The GPL is on version 2, isn't it? Just edit section 6, name it LGPL 2.0, and call it a night.


Good luck to getting anyone at FSF to play. If this is the nail in the coffin of the LGPL all I would expect to hear from that quarter is laughter.

Re:Whew (1)

pldms (136522) | more than 11 years ago | (#6466635)

We modify the LGPL to comply with its purpose. The GPL is on version 2, isn't it? Just edit section 6, name it LGPL 2.0, and call it a night.

I had a look for the problem section. I guess it's this:

6b:

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

This, AIUI, is the main difference between GPL and LGPL. It is intended to distinguish between static linking (derivative work must be LGPLd) and linking to shared libs (no restriction).

Java doesn't have two kinds of linking, and would appear to violate condition 1.

It means what it means (2, Insightful)

waterbear (190559) | more than 11 years ago | (#6466434)

It's worth pointing out that no-one (except a court) is really in a position to 'decree' what the LGPL clause 6 means if it really is a close call on more than one interpretation. If it turns out to be ambiguous or contentious, the best move could be to debate a clarification and campaign for the adoption of that instead.

Java (-1, Troll)

Anonymous Coward | more than 11 years ago | (#6466447)

sucks

OK, so we need a new license (4, Insightful)

bokmann (323771) | more than 11 years ago | (#6466453)

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

Re:OK, so we need a new license (1)

eakerin (633954) | more than 11 years ago | (#6466536)

From What I can tell by reading section 6 of the LGPL, (Although I am in NO way an expert) You basically have to state that sections of the codebase are licensed under the LGPL, and you have to provice the code if asked (the GPL has similar clauses) (as well as the sections the parent stated).

It's not that the License dosn't work for Java, it just dosn't work with the APL.

And I suspect most of us feel the same way... (4, Insightful)

sterno (16320) | more than 11 years ago | (#6466554)

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

rking (32070) | more than 11 years ago | (#6466654)

Open source software lives by the certainty of the licensing it uses. If we can't trust the interpretation of the licenses, then we can't feel confident in working with this code. The FSF is risking a serious blow to the open source community.

So far as I can see the FSF are giving their honest assessment of how the LGPL operates in this situation. The way it works may be inconvenient in this case, or for that matter the FSF could be wrong, but I can't see what strategy would be better for them to adopt than giving an honest opinion. Why do you feel they are doing something risky? Or what would you suggest they do instead?

the slashdot story is mis-interpreting the post (4, Insightful)

Anonymous Coward | more than 11 years ago | (#6466467)

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 (1)

MilesParker (572840) | more than 11 years ago | (#6466542)

Wrong. :-D If you knew Java, you'd know that a jar is the equivalent of a "binary"; that is object code. What is described here, is exactly that -- using a _*jar* file from another peice of code.

Re:the slashdot story is mis-interpreting the post (3, Insightful)

MisterFancypants (615129) | more than 11 years ago | (#6466545)

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.

You are absolutely wrong. What they are really saying is that the LGPL works virtually the same as the GPL when it comes to Java code because Java code doesn't use early linking, everything is bound at runtime, thus there is no clear separation between one LGPL library and other libraries used by an application, or between the LGPL library and the application itself.

If you follow this to its logical conclusion (which I haven't seen done in by the 'FSF-license guy') what you wind up with is the fact that you just cannot use the LGPL license with Java at all since the LGPL license conflicts with Java's own base set of libraries, which are shared source, but not free software in the *GPL sense.

Re:the slashdot story is mis-interpreting the post (1)

GigsVT (208848) | more than 11 years ago | (#6466650)

I'm not sure what you are saying, but that could be because of my ignorance of Java.

If a Java app uses a LGPL library, there is no way to modify the LGPL library and have the closed app use the new version?

That's the real intent of the LGPL, preserving the right of the user to modify the library and relink it with the closed program.

obWhore (2, Insightful)

dspeyer (531333) | more than 11 years ago | (#6466473)

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?


To quote C3PO from Star Wars... (0)

SunPin (596554) | more than 11 years ago | (#6466482)

Oh, dear!

That's great that what's-his-face can decree something. Is somebody forcing him to use the license or is he just screaming at the sky?

Text of LGPL (0)

Anonymous Coward | more than 11 years ago | (#6466486)

Section 6 highlighted in bold

GNU LIBRARY GENERAL PUBLIC LICENSE
Version 2, June 1991

Copyright (C) 1991 Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

[This is the first released version of the library GPL. It is
numbered 2 because it goes with version 2 of the ordinary GPL.]

Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.

This license, the Library General Public License, applies to some specially designated Free Software Foundation software, and to any other libraries whose authors decide to use it. You can use it for your libraries, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library, or if you modify it.

For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights.

Our method of protecting your rights has two steps: (1) copyright the library, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the library.

Also, for each distributor's protection, we want to make certain that everyone understands that there is no warranty for this free library. If the library is modified by someone else and passed on, we want its recipients to know that what they have is not the original version, so that any problems introduced by others will not reflect on the original authors' reputations.

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that companies distributing free software will individually obtain patent licenses, thus in effect transforming the program into proprietary software. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

Most GNU software, including some libraries, is covered by the ordinary GNU General Public License, which was designed for utility programs. This license, the GNU Library General Public License, applies to certain designated libraries. This license is quite different from the ordinary one; be sure to read it in full, and don't assume that anything in it is the same as in the ordinary license.

The reason we have a separate public license for some libraries is that they blur the distinction we usually make between modifying or adding to a program and simply using it. Linking a program with a library, without changing the library, is in some sense simply using the library, and is analogous to running a utility program or application program. However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such.

Because of this blurred distinction, using the ordinary General Public License for libraries did not effectively promote software sharing, because most developers did not use the libraries. We concluded that weaker conditions might promote sharing better.

However, unrestricted linking of non-free programs would deprive the users of those programs of all benefit from the free status of the libraries themselves. This Library General Public License is intended to permit developers of non-free programs to use free libraries, while preserving your freedom as a user of such programs to change the free libraries that are incorporated in them. (We have not seen how to achieve this as regards changes in header files, but we have achieved it as regards changes in the actual functions of the Library.) The hope is that this will lead to faster development of free libraries.

The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, while the latter only works together with the library.

Note that it is possible for a library to be covered by the ordinary General Public License rather than by this special one.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Library General Public License (also called "this License"). Each licensee is addressed as "you".

A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.

The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".)

"Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does.

1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

* a) The modified work must itself be a software library.
* b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
* c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
* d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.

In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.

Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.

This option is useful when you wish to copy part of the code of the Library into a program that is not a library.

4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.

If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.

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.

However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.

If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)

Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.

6. As an exception to the Sections above, you may also compile 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.

You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:

* a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
* b) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
* c) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
* d) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.

For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.

7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:

* a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above.
* b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.

8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it.

10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.

If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances.

It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case Micheal sims gets to shit in your mouth.

13. The Free Software Foundation may publish revised and/or new versions of the Library General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.

14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

NO WARRANTY

15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License).

To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.

one line to give the library's name and an idea of what it does.
Copyright (C) year name of author

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with this library; if not, write to the
Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.

Also add information on how to contact you by electronic and paper mail.

You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names:

Yoyodyne, Inc., hereby disclaims all copyright interest in
the library `Frob' (a library for tweaking knobs) written
by James Random Hacker.

signature of Ty Coon, 1 April 1990
Ty Coon, President of Vice

I PUCKED YOUR MUM! (0)

Anonymous Coward | more than 11 years ago | (#6466532)

This is nice, but... (0, Troll)

mcgroarty (633843) | more than 11 years ago | (#6466497)

This is all very nice, but it's not the win we're waiting for:

Will Apple PLEASE hurry up and link GPL'd code against their lickability??!?!??

We WILL have it!!!1!

weblogs have coverage? (0)

Anonymous Coward | more than 11 years ago | (#6466499)

Various weblogs have further coverage.

Weblogs are not credible news sites.

Viral? Infected? (2, Interesting)

foolip (588195) | more than 11 years ago | (#6466503)

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

Why I don't use the LPGL for Java (1)

DeadSea (69598) | more than 11 years ago | (#6466506)

I get a couple requests to use the Lesser Gnu Public License for my Java utilities [ostermiller.org] a week. I say, "I use the GPL to encourage open source development. If I were to use the LGPL, then you could use my libraries without giving me the source to your program.".

If you are really serious about free software. Then you will never use the LGPL [gnu.org] .

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

cpeterso (19082) | more than 11 years ago | (#6466533)


If I were to use the LGPL, then you could use my libraries without giving me the source to your program.".

but if the other person made improvements or bug fixes to your LGPL code, then he would (have to) share those changes with you. You benefit.

The phrase in question seems to be: (3, Insightful)

adamy (78406) | more than 11 years ago | (#6466510)


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

marcovje (205102) | more than 11 years ago | (#6466563)


I don't see the viral problem with that phrase, or any of the 'a'..'e' clauses. (only one of which I have to satisfy.

If I link LGPL library X, I have to provide library X source code, period. But no viral effect on my own code linked to it.

I can be wrong (am I missing something, of is none of the quoted parts actually identifying _what_ part exactly is viral?

Re:The phrase in question seems to be: (1, Informative)

Anonymous Coward | more than 11 years ago | (#6466604)

I think a simple separate jar of the LGPL ought to be enough. The reason is simple, what you propose is a runtime instantiation. Thanks to the Java class loading mechanism this already happens.

Lets look at the basic mechanisms of java

a) A library simply is a class file nothing more nothing less
b) A jar file is a collection of libraries bundled to a compressed zip file + optional execution info

c) Java does nothing than to uncompress the libraries already present on the disk on the fly.

d) The linking to this library happens after program startup at the first time a class is called, hence the singleton pattern really does lazy instantiation even of a class and therefore of a library.
Ever library/class has to be decompressed from a jar or loaded directly from the disk. It is copied into memory and this is done at the first time the class is called in a program. It has to pass an already running class loader (which is a java class itself) and the program already has already entered main at this stage if I interprete my runtime and debugging experience correctly.

Now lets look at the problematic sections:

>A suitable mechanism is one that (1) uses at run time a >copy of the library already present on the user's computer
>system

This describes exactly the class loading mechanism for class files lying around on the file system or for separate jar files, maybe even LGPL code bundled into a jar can be applied to it
(this is very vague however)

Whoever did the analysis did not know what a class loader is. .Net however could be more on the problematic side here, since it uses as far as I recall some kind of mem dump, a real linking more or less.

What about Perl/Python modules? (2, Interesting)

avida (683037) | more than 11 years ago | (#6466516)

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?

Re:What about Perl/Python modules? (1)

carlfish (7229) | more than 11 years ago | (#6466634)

Not quite. Section 6 doesn't apply the whole LGPL. It just means that you have to provide an offer valid for three years to supply the source-code for the LGPL'd library your application relies on. If your application is available for download, you need to make the LGPL'd library source available for download from the same site.

You must also provide sufficient source to allow people to use your code with a modified version of the library.

Charles Miller

Re:What about Perl/Python modules? (1)

justin.warren (14556) | more than 11 years ago | (#6466652)

I agree. As an author of a Python library, I was operating under the belief that the LGPL provided the terms I wanted; use my library however you like, but any changes to it have to be made available. The GPL wasn't suitable, and the BSD license was a bit too much.

If the LGPL is interpreted as applying to code someone else writes by making use of my library, not cutting&pasting the code, then I'm going to change the license I use. Simple as that.

As someone else has already said, I don't believe this interpretation of Section 6 is in the spirit of the LGPL as I understand it. I believe the license should be changed so that Section 6 adheres to that spirit.

The issue is late-binding. (4, Informative)

carlfish (7229) | more than 11 years ago | (#6466524)

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.

Mod parent up! (0)

Anonymous Coward | more than 11 years ago | (#6466585)

Moderators, the parent post seems to be correct, and the key point at issue.

Moderate up, please!

Re:The issue is late-binding. (1)

MisterFancypants (615129) | more than 11 years ago | (#6466619)

However, Java programmers have generally believed that Section 6 does not apply to them, because Java is a late-binding language

I believe you've summed up the issue correctly, but my question is this... If Section 6 DOES apply to late-binding languages, how can anything written in Java be GPLed or LGPLed considering that these *GPLed libraries will have to link with Sun's Java base library set (for String and other base classes) which are "Shared Source" but aren't Free Source/*GPL?

Isn't this a catch-22 right out of the gate which disallows you from ever using those licenses with Java unless you somehow manage to avoid using any of the base Java runtime library code?

Re:The issue is late-binding. (1)

MemRaven (39601) | more than 11 years ago | (#6466648)

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. Otherwise, I wouldn't be able to run GPL code on Solaris, since it would potentially link against a non-free libc.

I'm sorry but this is idiotic (1, Insightful)

Anonymous Coward | more than 11 years ago | (#6466527)

Sorry to rant here, but I quickly checked section six, no big deal here

Either use a separate jar file for the library then the thing is not linked and used like a shared lib (according to the section six definition it must reside as a separated interface compatible lib)

Or just bundle the binary with the LGPL code and add I will allow reverse engineering to my code clause to your own code license. I don't really see the problem, there is no way stated that you have to deliver the source from your own code there is an explizit "and/or" there and even the usage of obfuscators aren't prohibited as long as you allow reverse engineering and alteration of your own binary files.

Btw. separate class files must fall into the same shared library section as separated jar files :-)

As I see it this is nothing but self inflicted fud :-)

Worthless, no information (1)

dnoyeb (547705) | more than 11 years ago | (#6466555)

Their is no information to support this claim, so the article and all the linked blogs are worthless.

Please repost when your article and or references actually contain information worthy of discussion.

I use LGPL on some of my java code. Why ClassForName is supposed to be special I have no idea. I am lost here. a jar file is no different in usage from a DLL, so their really needs to be some support of these ideas...

Re:Worthless, no information (1)

JakusMinimus (49854) | more than 11 years ago | (#6466576)

I agree. The post is inflamatory at best.
I just re-read clause 6 in its entirety and don't see the problem. But maybe thats because I consider a jar equivalent to a dll. *shrug*

Re:Worthless, no information (1)

magic (19621) | more than 11 years ago | (#6466610)

Agreed-- LGPL is ideal for Java, where *everything* is dynamically linked.

-m

Re:Worthless, no information (0)

Anonymous Coward | more than 11 years ago | (#6466645)

Yes the post is rather useless, whoever gave the interpretation never had a clue about the class loading mechanism of java, basically a dynamic link is pretty much the only thing whichever happens in java, there is no way, that any of the libraries and any of the class files outside of the main class is started/copied into mem before the program is running. And to be on the save side (just in case a zip/jar file is interpreted as a library) put all the gpled code into a separate jar.

The class.forname is utterly useless, the classloader takes care of that anyway during execution, otherwise the singleton pattern would not do a lazy instantiation. If you want to see that in action make a program which does a longer calculation and then initialize swing, watch the 10 seconds swing needs to load its classes and initialize.

Viral... (2, Funny)

en4ca (543233) | more than 11 years ago | (#6466557)

Did anyone else read this as LGPL is Vital for Java. Guess thats what happens when you're half asleep

Java as a license framework (1)

CryptOntology (597072) | more than 11 years ago | (#6466561)

Sun probably already knew this LGPL catch-22 already. Consider this: they made Java with as an intent-towards-community. Their essential difference from Free software is that "the" community is under their control and aegis.

Why am I treating this difference like crime scene evidence? Because it justifies all the software decisions they've been making since Day One. Including SCO, Microsoft expansionism, _and_ the LGPL.

What's the issue, exactly? (1)

Adrian Lopez (2615) | more than 11 years ago | (#6466566)

I'm not sure I understand the issue. Does Java's "import" statement incorporate any of the library's copyrighted content into the program being distributed? If it doesn't then my opinion is that the LGPL should NOT apply unless the LGPL'd library itself is distributed along with the program. If the library is distributed with the program, or if the program contains a portion of the LGPL library, then of course it should be treated like linking any program to an LGPL library.

FSF's interpretation are not very relevant (3, Insightful)

reynaert (264437) | more than 11 years ago | (#6466572)

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

GPL only covers distribution (1)

bentini (161979) | more than 11 years ago | (#6466582)

Because of the way copyright laws work, and the GPL (and LGPL) only cover distribution...

Once a user has the code, they can do whatever they want with it, right? So, you can distribute your java code, and it will try to import the library, and they can go get the library, and it will work, right? Even with GPL code... You don't have to have the source for it to work. How can their license affect what you have to do?

The LGPL and End to Sexism (1, Funny)

Anonymous Coward | more than 11 years ago | (#6466593)

You know, I hated watching PGA golf [pga.com] back in the 1950s, when men were getting all the attention. Fortunately, the LPGA [lpga.com] came along, and before you knew it, we all were treated to the likes of Nancy Lopez, and today, Annika Sorenstam.

In regard to open source software, I've been feeling the same way over the past decade, watching the men sponsored by the GPL get all the coverage. It's great to at long last see the LGPL get some attention too. I'm sure it won't be too long before the Ladies of the GPL start receiving the attention that has been denied for too long.

Not his call (3, Insightful)

Otter (3800) | more than 11 years ago | (#6466597)

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? (3, Interesting)

JanusFury (452699) | more than 11 years ago | (#6466602)

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 (5, Informative)

timsuth (466108) | more than 11 years ago | (#6466616)

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.

Open warfare on Java and Open Source Has Begun! (1)

TheNarrator (200498) | more than 11 years ago | (#6466622)

Wow.. This isn't the first attack on Open Source and Java today. Take a look at this thread on the server side between a commercial vendor and the Hibernate open source project. It degenerates into legal threats and wild accusations. I have rarely seen a flamewar this severe.


[theserverside.com]
Thread is here

Old fashioned (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#6466643)

Still using GPL? Time to upgrade to BSD!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?