Slashdot Mirror
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."
they coined the term "viral" with respect to software licenses, and now everyone's using it.
:\
good stuff.
I had no idea java programming would need to be so painful.
It has too many negative connotations. `Viral' is too closely related to virus, worm, exploits etc.
... well it is all down hill from there.
The FSF & those posting in their blogs need to choose a better word. One Bill CIOofSomeCorp gets wind of Free Software being viral
What??? You have sex with sheep?
I know a way they can handle their GPL model..
Just ask SCO!
"If it is not OUR's then it must be Viral"
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
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...
Polymorphism -- It's what you make of it.
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.
Just switch to the BSD license, like the Vorbis project did.
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.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
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.
A Pirate and a Puritan look the same on a balance sheet.
Sheep are quadrapeds
All I can say is that this is bad shit. How will we get folks to develop from the LGPL now?
Put identity in the browser.
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.
I am a Java developer, and I have used the LGPL on work (and also used work that HAS been LGPLed).
My intent in using the LGPL is pretty simple: If you want to use my library, go ahead. If you make CHANGES to my library, those have to be released back into the wild, so the library can be improved by everyone's improvements. I'm not a 'Free Software' zealot - I'm an open-source pragmatist.
If the LGPL does not meet this intent with Java, then we should find or write a license that has this intent. Perhaps one of the ones at Creative Commons would work...
The 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.
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.
I'm not Seth.
What??? You have sex with apes?
Subject: Re: [Followup] RE: Possibly Include HTMLParser Jar in contribcode?
From: "Andrew C. Oliver" <acoliver <at> apache.org>
Date: Wed, 16 Jul 2003 08:12:12 -0400
Newsgroups: gmane.comp.jakarta.poi.devel
You cannot. Though the FSF has stated that the Apache interpretation was correct and that importing classes from LGPL jar files in Java does indeed cause the "viral clause" to apply to Java.
Please stop saying "lift the code" or other things that imply violating the copyright.
Under no circumstances can any LGPL code be used as it would require us to LGPL our code per section 6 of the LGPL license and the statement I received from the Free Software Foundation's Dave Turner (the man behind licensing <at> fsf.org):
" Me:
DT: This sort of linking falls under section 6 of the LGPL. "In short, Sam was right, I was wrong.
-Andy
On 7/16/03 4:55 AM, "EPugh <at> upstate.com" <EPugh <at> upstate.com> wrote:
--Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
Sig:Why copyright isn't a fundamental human right
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?
Laws are for people with no friends.
Not always, there is a process called "Lunch" in which they have no legs at-tall. /english_voice.
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
Will Apple PLEASE hurry up and link GPL'd code against their lickability??!?!??
We WILL have it!!!1!
Various weblogs have further coverage.
Weblogs are not credible news sites.
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
If you are really serious about free software. Then you will never use the LGPL.
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.
Open Source Identity Management: FreeIPA.org
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?
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.
The more I learn about the Internet, the more amazed I am that it works at all.
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
You have a choice. The [L]GPL is not a little bug trying to worm its way into your code. If you chose to use GPL code, then you follow the terms, or don't use the code. It's simple.
You seem to miss the entire point of the LGPL. The whole point is that you should be able to use LGPL code in a non-LGPL project. To quote from the website:
"The choice of license makes a big difference: using the Library GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs."
So whereas the GPL is intended to be somewhat "viral" -- i.e. software using GPL code must also be GPL -- the LGPL is not supposed to. This is why the viral-ness of the LGPL is news, since it's contrary to much of the community's understanding and intent regarding the use of LGPL code.
Cheers,
IT
Power corrupts. PowerPoint corrupts absolutely.
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.
This sig has been temporarily disconnected or is no longer in service
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...
Did anyone else read this as LGPL is Vital for Java. Guess thats what happens when you're half asleep
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."
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.
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.
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
One example of one such non-standard interpretation is the "Lisp LGPL", used by Franz 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 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).
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?
Moderate up, please!
"the HURD will be ready soon"
"Linux will dominate the desktop in a few years"
"Richard Stallman has taken a bath"
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.
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 I'm listening to now on Pandora...
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.
using namespace slashdot;
troll::post();
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.
microsoftword.mp3 - it doesn't care that they're not words...
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.
Thread is here
""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.
Hi. I'm that David Turner who is quoted. I'm not the David Turner who works for Microsoft, and I do not hack on Freetype.
First, I'm upset that CowboyNeal didn't contact me -- as the article says, I work at the Free Software Foundation, and you can find our phone number on our web page by searching for "s" on Google and clicking "I Feel Lucky."
Now, if you read section 6 of the LGPL, it's not the same hereditary [1] thing as section 2 of the GPL -- what it says is that your program, which links against the library, does not need to be licensed under the LGPL. But you do have some obligations -- you need to allow people to relink your code with new versions of the library.
[1] I think hereditary is a much better analogy than viral, and I thank the person who came up with it and whose name I forget.
Become a FSF associate member before the low #s are used
LGPL is Vital for Java
Run Windows Update.... it now has an antivirus patch which removes all GPL and LGPL software from your system. Ain't that nice and tidy!!
Yea, this is what I thought till I read the section in question, section 6 [grrrrr]
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.
This pisses me off. OK, so it does not say you have to distribute your code. But it does say you must permit modification of the work and you must permit reverse engineering for debugging the modifications the other user decided to do.
WTF is that? I thought xGPL was about code, and has nothing to do with rights to reverse engineer and or modify your work!?
I find that rediculous. I think they are right in their problem with the LGPL. But its not a Java related problem specifically. And the only thing in question here is NOT that your end project must be LGPLed, but your end project must allow reverse engineering and modification.
Has the GPL or the LGPL ever been litigated? With the opportunity for interpretation being what it is, you would think someone would push the envelope and wind up in court. Have they?
This material should be considered akin to shouting fire in a crowded theatre when there isn't a spark around for miles.
../lib/ext directory just for the explicit purpose of dropping in your libraries and any third party libraries.
../lib/ext directory the library is effectively shared for any Java program utilizing this particular JRE installation.
../lib/ext directory.
../lib/ext directory.
Anybody who works regularly with Java will understand the mechanics of how professionals work with provided libraries and that those same mechanisms fit perfectly with the requirements of Section 6, Part B of the LGPL.
It's pretty obvious that the writer doesn't understand Java programming or Java systems configuration.
To explain how Java works, basically if you want to utilize a third party library all you need to do is:
1. Distribute Sun's (or a suitable facimile) Java Runtime Environment to your target clients.
Note that the standard JRE comes with a
BTW, once in the
2. Put your own libraries in the
3. Put the third party library in the
4. Run your Java program. Note how long it takes to "load up".
My guess is that one of the things the JRE is doing is reading those libraries to "know what it has available" and storing that info in some sort of a hashtable.
5. During your program's execution create a object from the third party library.
Note, that the Java interpreter merely looks up the class in the hash via an internal call that anybody can duplicate. But why when all you are duplicating what is already built-in the Java interpreter.
If some client/end-user wants to substitute in a modified version of the third party library then there is nothing stopping them.
They can drop in a modified or a substitute library just so long as the class names and method names, etc.. stay the same.
Whether the program continues to work is a totally different matter.
But the key point is is that the entire process is all dynamic. And from one run of the program to another run nothing guarantees the calling program that the third party library is actually the one that was originally installed.
Caution: Contents under pressure
The real problem is that LGPL was designed primarily for C/C++ libraries. That is why there is so much talk object code, macros, inlines, etc... You have the option under the LGPL to include object files, instead of source files, for a work that using the library. This assures that people can change the library and re-link the program. However, Java, depending so much on run-time linkage, and really lacking object files in most cases (I'm sure you can make those Java compilers output object code), is pretty much forced to distribute source.
====
Crudely Drawn Games
GPLed code acts as a lure. If the code is enticing enough to convince you to open your own code, then you bite. It's your own damn choice.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
If I wanted to study the nuances of licensing agreements, I would have gone to law school. Is there a web site where all these licenses are summarized in English?
What about this problem: I wrote a piece of software that links to a kXML library that is open sourced under the Open Public License, What is that? I wrote the license author and their email bounced, now what do I do?
Free cell phone tracking
So Section 5 applies just as it does with non-Java code. Likewise, Section 6 is pretty darned clear. Section 6b still applied for Java - Java runtime linking meets all the requirements of 6b. What's the big deal? As long as the LGPLed library (or it's "modified form" you distribute under your own terms, per section 6) is distributed in a separate JAR, it can be replaced by another, recompiled version of the JAR. You can change one line of code, and recompile the original library to a JAR file, distribute it under your own terms, just provide source for your "modified" version of the library, and you have complied with section 6. Voila. There's no need to jump through these hoops though, section 5 still applies, let's not get our panties in a bunch, the sky has not fallen.
not Lessor (anymore).
If the LGPL code is in a jar file, I can black-box reverse engineer the code in it. What happens when I replace the LGPL code with my code? The program still works (of course assuming no bugs) because none of the LGPL code is brought into the program.
How can a program be forced to become LGPL when it doesn't even have LGPL code in it at all? I mean even with DLLs, there is some code that is linked into program for resolving dynamic links.
You know all this license stuff is way to much for a simple coder like me. I can now see where the BSD license is coming from:
"Here, just take the god damn code. If it breaks I don't care!"
What, all of it? Even the stuff that Microsoft stole?
</conspiracy>
Attack its weak point for massive damage!
The Java import statement does not alter the compiled class in any way. The import statement is esentially a compiler directive, which tells the compiler in what packages to look for classes.
For example:
import java.util.*;
public class Bob {
Vector v = new Vector();
}
and...
public class Bob {
java.util.Vector v = new java.util.Vector();
}
produce the same exact bytecode. In the first case the compiler would search for class Vector in the packages specified in the import statements.
I does not actually import anything from those packages/classes into the class.
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.
It's possible to copy a substantial portion of a work and infringe its copyright without even realizing that you're copying anything. See Bright Tunes v. Harrisongs .
Will I retire or break 10K?
Excellent point. I would like to add another.
Because, as you note, "the author has the opportunity to write it to cover whatever case, and has the responsibility to make his intentions clear," a standard rule of contract (and a license is a form of contract) interpretation is that a contract is construed against the drafter. In other words, if a contractual provision is ambiguous, all other things geing equal, the ambiguity will be resolved against the party that drafted the contract.
Statements by the FSF regarding its interpretation of the GPL and LGPL may be useful in determining which legal positions it will assert in litigation, and whether it will file suit. However, its interpretation is useful in determining whether said position will prevail only to the extent that their reasoning is persuasive. The fact that the FSF has chosen to interpret a contractual provision is a given way is, by itself, useless for the latter purpose.
Only Women Bleed (Sex, Sharia remix)
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 why not just draft your own license that's basically the LGPL, except that it is built specifically so that it will work as most people expect it to with Java libraries (and maybe other languages, like Objective-C libraries)?
Make sure that the license is compatible (as much as possible without destroying the intended modification for Java code) with the FSF's LGPL, GPL, etc licensees. Then find some way (I have no idea how to do this) to get people to know about this. Maybe bribe on of the Slashdot webmasters to put it on..
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!
Putting the project under LGPL indicates a willingness to let it be used as a library. Only the copyright holder can sue - and they have indicated they don't want to. So who has anything to fear?
Apparently the only thing that the LGPL causes is that you must not disallow reverse engineering and post-purchase modification.
In other words, if you use an LGPL'd library. You can't sell your software and then say "You can't reverse engineer this!" or "You can't modify the binary on your own computer!"
What exactly is it that prevents this with java? It seems to me that you can reverse-engineer java code without the source, or whatever.
autopr0n is like, down and stuff.
I'm not a GPL fantic or anything but...
GPL backers typically don't like the adjective "viral" to be used to describe their work because it has a negative connotation. ie. The set of associations implied by a word in addition to its literal meaning. ( dictionary.com ) To me, that position is very understandable.
There's always more than one way to say what you mean. You can call someone "Stubborn" or you can call them "Strong willed", almost the same thing? Marketing, politicials use this type of thing very often.
In fact 'viral', as an adjective is, I'd say, blatantly demeaning. There is absolutely nothing good about a virus, and that connotation sticks with the adjective.
Would you tell your girlfriend "your love for her is spreading through your system like ebola"? or I love you like flies like sh**?
Both those statements I believe express great unyeilding passion. But it may not go over that way.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Actually I believe that the LGPL should be repalced with a DUO Licensing system for free Software Libraries. The first license would be the standard GPL. The second license would allow proprietary closed source devleopers to use the library under the following conditions.
1. They NEVER apply for a patent on software or
software algorythms.
2. They SURRENDER any patents they currently hold on software or software algorythms to the public domain or license them under the same duo licensing system that the library is covered by.
3. They NEVER as a third party engage in lawsuits designed to enforce patents on software or software algorythms.
The license would also have a clause stating that any violation of its anti software patent conditions renders it void therby placing their software under the GPL ONLY and giving them three options.
1. Writing their own library to replace the Free Software library they originally used in their closed source project.
2. Distribution their project as Free Software as defined by the Free Software Foundation through the GPL.
3. Cease and desist the distrubution of all software using the library.
I believe that the approach I have outlined here is better than the LGPL for licensing Free Software libraries for closed source development because it allows us to attack the greatest scourge in the software development field, either Free or Proprietary today, SOFTWARE PATENTS witthout haveing to resort to our corperate money addicted congress. It also allows Proprietary developers to give back to the community in a way far more important then their code. The surrender and final elimination of this rediculous and deadly software patent trash.
Import is provided so you don't have type out whole package names. It is a common misconception that it has something to do with linking. Everyone keeps saying things like "if you use import then...blah blah", but you don't have to use import - ever. You can just always use the fully qualified name: like "foo.myclass". Or you can say "import foo;" and simply refer to "myclass". That's it - no magic - it is more like a preprocessor. What about using reflection? hehe...
Some of what the other posters have mentioned, I agree with -- That the decrees of those who have written the license no longer matter as far as what it 'means'. That it is for the courts to decide, and programmers to interpret how -they- think the court would interpret it when they decide whether to use a license or not.
:
.so's.
... , 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."
That said, I could not find the line of thought that led Dave Turner to think that LGPL does not allow Java libraries to remain seperate (viral? parasitic?). Here is my reasoning to think otherwise, as a Java Programmer.
Remember, from section 0 of the LGPL
"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..."
We're only concerned here with what we have to/are allowed to [not] distribute and what and when we are allowed to modify.
Here's a mild stretch, but something to consider from section 2.d)
"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."
A Java JAR file is essentially a ZIP file -- this could be argued to be merely a form of digital distribution medium, designed to save hardware space and costs. Thus when we distribute the JAR file including the LGPL'd library, it is no more that if we were emailing a zip, rar, or installshield including our program and LGPL'd DLL or
Section 5 (The particularly relvant one):
"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."
A Java program is run by invoking the java runtime on a class with a 'main' function. The only thing non-modular at that point is the class itself. All other classes can be rewritten, replaced, modified, etc, without changing the base 'executable' of the original class. Thus, all code (classes) not having anything to do with the LGPL'd code remain 'in isolation' and fall outside the scope of the LGPL.
More from Section 5:
"However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library
Key note here: Section 6 states terms for DISTRIBUTION of such executables.
Given that java doesn't create the action 'executable' until you actually attempt to run the program (until then, all compiled classes are object code), noone is ever 'distributing' a java executable. It is interpreted/linked/created/run on the user's machine. Thus, as far as distribution is concerned, we are never distributing an 'executable' containing the LGPL'd library, so section 6 never even applies to Java. At any point in the distribution, the library can be retrieved and replaced from the distributed files.
With regard to actual usage of the library in your own code, we look again at section 5:
"If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions... , then the use of the object file is unrestricted"
Using Java objects is not much different than using C++ objects. You are merely using the accessors, data structures, etc provided by the 'include' files. The 'import' command is typically interpreted as the analog to C/C++'s '#include'. Java simply does not separate the header from the object code. It is similarly possible to write some or all code in a C++ class in the
the association of open source software with the GPL family of licenses is hindering the adoption of OSS. The GPL is a very poorly constructed license, fundamental elements of which probably aren't even enforceable. The FSF intentionally maintains a state of doubt surrounding the meaning of the GPL in order to leverage their authority over elements of the open source community. This LGPL issue simply highlights the fluid and arbitrary nature of its interpretation.
The fate of OSS as a 'movement' is far too dependent on the state of the GPL - if the GPL is struck down the conventional wisdom will be that "open source is dead".
Sometimes I honestly think that the best thing that can happen to OSS is for the GPL to be litigated in court and for it to be proven invalid. It'll be a blow to the community but may finally get people to focus on developing viable OSS licensing models - if it got rid of the Stallman drones that would be good too.
what's more important , developing good OSS or falling on our swords for a hack software license that reads like someone's freshman year political manifesto ?
Paraphrasing:
The #include <stdio.h> is a preprocessor directive ONLY. No actual linking is done by using it.
No actual linking takes place until you run your program, when ld.so links it with libc.so. Bah.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
- First it was as keesh. The result? "0: Redundant."
- Several threads later, as ADOT Troll, you said pretty much the same thing. Too bad, same result. "0: Redundant."
Third times the charm.concrete5: a cms made for marketing, but strong enough for geeks.
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.
Section i6 isn't about modification to an LGPL library - it about certain requirements that apply when you distribute an application that uses the library. These requirements may be inconvenient to somebody distributing a commercial program - but not "viral". Furthermore, using a shared library version of the LGPL library has distorically been considered to satisfy the linkage requirement of section 6; using a Java archive should do the same.
So I can't import LGPLed code into my project unless my project is LGPLed as well? That's the idea! I personally would interpret it as you can include LPGLed libraries with your code, just as with a staticly linked C lib, but that you must provide source as well.
The point here isn't that Java is a special case, but rather that it isn't an exception. I can accept that.
You can't judge a book by the way it wears its hair.
This is not in any way related to a computer (or other) virus.
It's creates FUD and MOST Joe Sixpack types are mislead by this use of this terminology. Of course the drags in your common IT "expert" and ALL the management decision makers, who make decisions based on CRAP they read on crappy, so called "news" sites like Cnet and the like..
Someone, please, let's drop the use of this terminology except when refering to real viruses..
(Wow! I got through that one without my usual M$ bashing!!)
...since gcj can build traditional shared libraries out of jar files. See http://gcc.gnu.org/java & http://sources.redhat.com/rhug
there seems to be a bug with slashdot (GASP)
a 12
click 'reply to this' to read all of the post, or here is from where I see it get cut off from:
It is similarly possible to write some or all code in a C++ class in the header file itself, though it is usually considered bad practice due to recompile issues. Java has done away with both the issues and the notion of separate header files.
More specifically:
http://radio.weblogs.com/0122027/2003/04/07.html#
answering this question in relation to each point:
A) this is no different than creating a C++ class from a LGPL library. Your code is yours, you are simply using the interfaces/accessors provided by the library.
answer A - unrestricted
B) this is touchier. by extending a class, you are basically creating a class that is equivalant to the original, with possible additions and modifications. However, this is being done without actually using any of the original code, so you are not actually modifying any LGPL source, and are not 'based on', but rather 'use' the original library/class. Also of note, after extending the class, the original class file can be swapped as explained above with the beginning of section 5. Java does not include any of the original 'portions' of the LGPL library in the object code compiled for an extended class, thus again, it falls in the class of code 'using' the library rather than 'based on' or containing portions of it.
answer B - unrestricted
C) in my professional (programmer) opinion, the rest of the options are merely obfuscations around the point, in case the answer to A was restricted.. again, ProxyBar is merely using the object provided and its accessors.
answer C - unrestricted
D) more obfuscation, but rather than the usage, the obfuscation here is how they retrieved the object. This concerns the distribution method, again, and thus it is not nescessary to do this. However, since the question is not whether this is needed, but if it's okay to do it, I'll answer anyway. The process used here is equivalant to the pseudo code:
org.gnu.foo.Bar obj = new org.gnu.foo.Bar();
obj.someMethod(args[0]);
which is nearly the same as A. The classes are loaded using the same class loader in both cases, because the system loader is searching for org.gnu.foo.Bar in the same places whether the import statement is used, or the Class.forName().
The only difference is that this is done at runtime -only- for this version, while the import looks up the class at compile time, as well. This means that for the import statement, insteading of assuming that your functions will exist when getMethod() returns, or that the class will even be there (notice no error checking in this and the next question), will actually check the code and ensure proper usage of functions. No actual information is stored when the compiled object/bytecode is output.
answer D - unrestricted
E) whee, more obfuscation! Same as above, except the strings are taken via the command line. The name of the class was not in question or copyrighted (maybe trademarked, but that doesn't matter in this discussion). If it were, there would be larger issues with that library than just the LGPL's interaction with Java. This question in fact has absolutely no knowledge of the LGPL'd library, and could be used to run any library, any class, any function. So it is not at all effected by the LGPL.
answer E - unrestricted
F) the org.gnu.foo.Bar in question has suddenly become an executable, not a library, and as such the license no longer has any bearing. remember from section 0: "The act of running a program using the Library is not restricted" The library has becoming it's own program using the library.
answer F - unrestricted.
That's my interpretation, and line of reasoning. Feel free to nitpick or argue against my points, I will gladly view others' reasoning.
How could this be construed as saying that "LGPL is Viral for Java"?
Maybe there's more to it in that one link that's Slashdotted.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
If I write an applet and license it LGPL or GPL, what I'm saying is "Use this, modify this, just don't hide this if you change this". If one doesn't want to deal with this as an author of proprietary software, there's a simple solution. Don't depend on someone else's GPL'ed work. That's it. It's not exactly brain-surgery. If you need something that only exists in GPL, write it yourself. If you're too lazy to do so, well, that's why you're not making the big bucks as a developer.
Do not look into laser with remaining eye.
What is it with you people? If *you* the program author put your code under the LGPL and it doesn't mean what you thought it did, then *you* the program author simply need to modify the license. Put a paragraph at the beginning saying: "NOTE: any language in section 6 that suggests you can't use my code this way, ignore it, what I intend is that you can use my jar file such-and-such a way".
/. where every closet RMS-hater can bring out their anti-GPL FUDshit AGAIN and AGAIN.
why the hell do people think that RMS and the FSF and the GPL have these "magic powers" to "force" and "compel" and "infect" programmers and code??
The SOFTWARE AUTHOR who HOLDS THE COPYRIGHT can choose ANY LICENSE including the LPGL plus an explanatory paragraph. The FSF even says how to do this (even though they don't recommend it).
If somebody rips off your Java jar, guess who has to file the lawsuit? RMS? FSF? No, YOU the programmer. So YOU decide when it is being violated.
Problem solved in about ten seconds, no need for a sensationalist post on
There is the Free Software Foundation. When will we have a Freer Software Foundation? Then when will we have the Freest Software Foundation? Rise up! Revolt! Distribute gcc, et al., with the GPL removed. Go ahead!
Now that the real Dave Turner has stood up and explained that you can still use LGPL libraries in your proprietary code, the question is why would CowboyNeal put this FUD up in the first place? Instead of getting a clarification, he just let somebody scream "Fire!" in a crowded theater. Damn it, that doesn't help anyone. People are going to remember the headline and not the truth. CowboyNeal should pull his head out of his fat ass, and put Dave Turner's comments up on the front page so the *REAL* story gets out. The basic point is that if you modify the LGPL library and distribute it, you need to make the code available. Not a big deal, really. Thanks for damaging the perception of the LGPL for no reason. With friends like CowboyNeal, the OpenSource community doesn't need enemies.
Okay, if I make a piece of java code, like a class, and provide methods to use that class, and wrap this up in a jar file and say it's now under LGPL, then here's what somebody should be able to do (IMO):
1. Create java code which uses my library (jar file) with the library as a separate jar file (ie., none of my code is in their code, they're just calling methods and classes from my code).
2. Not have any requirements placed upon their code at all in any way.
As I see it, this is exactly what the LGPL does. Section 6 never comes into play whatsoever, because their code falls into section 5. They haven't actually combined my code into theirs, it's totally separate, sitting right in that jar file (aka library).
Granted, if they modify my code and distribute the modified version, then they must distribute the modifications they made to my code as well. That's what the LGPL is for in the first place.
But I fail to see how section 6 applies in any way whatsoever. None of my LGPL'd code is included in their code in any way. It's separated because it's in a separate jar file.
Lookie here:
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
To me, this exactly describes someone calling classes or other code that resides in my jar file. They're not copying the code into their own jar, they're linking to it. But let's look at section 6:
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library...
This never happens if done properly. My jar is sitting alone, their jar is sitting alone. At runtime, their jar loads, says to the java interpreter "hey, make a class from that other jar", then my jar loads and a class gets created.
So, am I wrong here? I see no normal situation in which section 6 would ever apply to Java libraries, unless someone was straight up ripping my classes off and including them in their own jar file along with their own code.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
In other words, as long as you don't modify the Library and you keep your source code entirely separate from the Library source and you distribute your object code (or executable) separately from the Library you have nothing to worry about.
...and that's the way the cookie crumbles.
LGPL's Section 6 allows you to make new works that link with the LGPL'ed code, and license those new works any way you see fit. Only the LGPL'ed code itself must remain Free. Such 'client code' (as mentioned in the story posting) can even be proprietary; it need not be LGPL'ed. LGPL's Section 6 does place some requirements on what you do, but that is only to make sure that people can effectively exercise their freedoms to copy, modify, and redistribute the LGPL'ed code.
-- Bradley M. Kuhn, Executive Director, Free Software Foundation
Thank you.
Read, L
Pine(R) is the University of Washington's "Program for Internet News and Email". Made in the U.S.A.
Turner explained himself further in subsequent posts. You simply need to follow the rules for LGPL in Java as in C (ie, package your app so that the LGPL library can be replaced simply). You state that:
the LGPL works virtually the same as the GPL for Java code.
Certainly you can use the LGPL for C. Therefore, what is in fact true is that
the LGPL works virtually the same for Java as for C.
You've just made a compelling argument for universities to switch to C# for computer science classes!
In Doggiebox, I use routines from libsndfile(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
myselfmusic
This is exactly the reason why the single largest fount of open source code was the University of Califoria at Berkeley. UCB and the UC Regents created a license that was intended to allow programmers and the businesses (both for- and not-for-profit) they work for to do whatever they wanted with the code. Stallman had a different idea - that all software should belong to everyone, and that's what the GPL and the LGPL are intended to express. Those two different approaches produced two different licenses. And that's why everyone goes into ctl-alt-meta-cokebottle SetMode AmateurLawyer when discussing the GPL, and nobody except the FSF has a cow when discussing the BSD license.
If you're a socio-political philosopher-coder, by all means put everything you write under GPL (and listen to what Stallman says about his LGPL being a bad idea after all). If you don't care about the social/economic/etc. aspects, use the BSD license and just be happy.
Reading over Section 6 of the LGPL left me at a complete loss as to how the LGPL could possibly considered 'viral,' regardless of you're talking about Java .jar files or shared libraries. Someone care to explain a little bit more thoroughly than the post linked to in this article?
So what you're saying is that M$ or anyone else would never make the resulting code not interoperate with the original code.
Don't you understand that there two important facets to computer code? As a result, if you can restrict the function of the code (by closing the source) then you can edge out the BSD version easily.
First, yes, it is data. Therefore it is copyable.
SECOND, it is programmatic. It not only has form, (copyable) but FUNCTION!
If you take that BSD code, close source it, and then make it not interoperable with open source versions (and make your closed source version have some killer feature) then you have won.
That is why the BSD license is crap. It doesn't protect the author's functional rights.
This is also why copyright for software is stupid.
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]
If you read what is referneced via the links you will see that the Apache Software Foundation (ASF) is taking a "convservative" view of the LGPL, i.e. they know they are over reacting.
You would need that people transferred their copyrights to modifications to you, so you could continue to double-licence the whole. AND you can't demand it, because the GPL does not allow any other restrictions.
Think in cases like the Linux kernel, that has a lot of copyright owners.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
This doesn't invalidate the GPL, nor does it invalidate the copyright holder's claim on his code. As the original author of the code, he can dictate whatever terms he likes for someone else to use and distribute his work.
File under 'M' for 'Manic ranting'
The GPL doesn't require the distributor to promise that modifications are runnable.
Doesn't the GNU GPL's guarantee of installation scripts imply that the author has to provide a way to run modified binaries? Here's the relevant excerpt from section 3 of the GNU GPL:
The definition of "installation" on a computing device that stores programs on removable read-only media may pose an obstacle to adoption of GNU licenses for console game engines.
Will I retire or break 10K?
As I understand it, the Java issue seems to be almost identical to the static linking problem.
While I label a lot of my code as LGPL, I have absolutely no problem with static linking the code. I don't see how a few linker options are relevant to licensing of source code.
This has always been a nitpick that has baffled me about the GPL and LGPL. Why does everyone have such an issue with static linking? Static linking doesn't change the code I release, and nor should the implementation of byte code loaders and Java runtimes.
I do not fail; I succeed at finding out what does not work.
Let me rephrase that last statement:
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, without getting the most definitely undesirable stigma of section 6 attached to the code.
The whole point of the LGPL is to create libraries that are open source but which can be used by closed source programs, requiring only that any modifications to the *library* be distributed back into open source. Your definition requires more than that, and thus the LGPL doesn't do what everybody has thought it did for the past X years.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
Just a wrong headline on slashdot. The whole thing apparently started by somebody believing "since we use Java, we don't have do follow the LGPL", and the FSF clarified that the LGPL works exactly the same for Java as it does for C or C++.
Constructing a headline from an out-of-context quote in the middle of a long thread... Is slashdot trying to copy CNET or MSNBC?
Because in places where the LGPL is used, there's a clear marker of the specific version of the LGPL. Shortly after that, there is text stating that one may use this version, or to their discresion any other later version of the license when interpreting the licensing agreement. In which case, we come to 2 conclusions:
In any of these cases, there's nothing wrong. Either it's supposed to have this behavior. Or not.
Kind regards, Devon H. O'Dell
Ummmm...why are you doing all this work? The LGPL is not viral - if you link/import/include what have you to an LGPL library your code does not "become LGPL". What does happen, though, is that you have an obligation to provide the source code to the LGPL'd library that you included. Going through all these acrobatics doesn't change anything - you STILL have to provide the sources to the LGPL'd library.
What if he links with a BINARY library he has found on his machine and came with the OS on the machine (i.e. the api offered by the OS) ? Developers like linking with binaries since that shortens compile time.
Now, he links with a binary but has to embed a license to his own sourcecode because he links with a library, however he doesn't include any sourcecode from the binary (say, he uses win32's LoadLibrary()).
_THAT_'s the viral part. He calls into a library and because he does that he has to make his own code which he owns copyright of open because someone else who doesn't own the copyright of that work said so.
I'm 100% sure this will not hold in court in The Netherlands or Germany.
Never underestimate the relief of true separation of Religion and State.
Fear and Fud are the stock and trade of Microsoft. Not the Java people. The preceptions of open source being inferior are spread by MS salesmen, not programmers. Any tom, dick head and harry that gets certified in the .NET college mill is spoon fed this tripe by the MS trained instructors. The whole crux of the matter is that MS is out to control digital communication world wide. They have large interests in the Media, they are on the constant lookout to purchase digital rights to content. Did you know that Bill and Steve went on a shopping spree a long time back and proceeded to buy the digital reproduction rights to a huge chunk of the worlds great art from cash starved Galleries. Back then the Galleries did not realise what was going on and just took the cash. If we do not act in concert soon to break the monopoly we are in for an information dark age that will make Orwells 1984 look like a rainstorm at a Baptist Church picnic!
OH THE SHAME I fell off the wagon and use sigs again!
The 'viral' remark is not made to just call the GPL as something bad, the viral remark is made to illustrate that the GPL fights its way into your own software like a virus does with its host cells: it enters the host cell, most of the time fooling that host cell and after that it takes over the host cell, using it as a tool to reproduce ITSELF. This is also the case with the GPL. It works itself into your software via teh linkage to a binary file, and takes over the license of your software (which can also be a library) and uses your software (f.e. your library) as a tool to reproduce itself, for example to the users of YOUR software.
That's the viral part. And it will NEVER hold up in court.
Never underestimate the relief of true separation of Religion and State.
The whole point of the LGPL is to allow for the creation of library code (aka the GNU C library). Now if according to this "new" interpetation: that you cannot subclass a Java LGPL library (or even import it), then that would automatically mean that other licenses (proprietary or not) cannot link against the GNU C libraries either, since you can extend the GNU C library as well. Perhaps not through subclassing but certainly through passing it function pointers and overriding functions through the dynamic linker (or even the static linker). It would also render the GNU C++ library useless to anything other than LGLP/GPL code.
Now we know that this is not the case, for if it was it would render the LGPL pointless since it would just be the GPL.
You're viral has connotations of 'accidental infection'. Perhaps assimilationist might be more accurate - Everything that incorporates GPL, becomes GPL. Resistance is.... ... sorry.
Is deja vu a common place on slashdot ?
Can we please stop using the term "viral" to refer to software liscenses? This is a term coined by Microsoft, and using it only perpetuates their influence on the market.
--#!
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.
Wrong. You have infected your program by including the GPL covered code. No one held a gun to your head and demanded that you include it, nor did the code sneak in through an open window and jump into your source repository. That was your choice. Calling it viral is ungracious at best.
[...] under non-free licenses like the GPL [...]
That you prefer the BSD terms to those of the GPL does not make the latter non-free in any meaningful sense and your claim to that effect is nothing more than religious zealotry. Learn to accept that not everyone will genuflect at your church and get over yourself.
Not all those who wander are lost.
My interpretation is shared by Linus. He's not a lawyer either though.
Even if you wrote the library, once you release it under a license like the GPL, you can't really put the genie back in the bottle can you? If you release Version 1 under GPL, then Version 2 must also be released under the GPL since it stems from the code of Version 1. Screwing up legally regarding Java kind of sucks since it's permanent.
Eat at Joe's.
I'm not retarded, I'm just special...
Eat at Joe's.
I do not get the fuss...
- If you use GPL code in your code, then your code is GPL'd
- If you *link* to LGPL code in your code, then your code can be distributed under a license of your choosing
- If you *USE* LGPL code in your code, then your code becomes LGPL too
- If you use or link to BSD code, then your code can still be licensed as you whish.
Don't like it, don't use that code.
If I use commercial code, then I get sued...
This is no more viral than the GPL!
How about a dual license with LGPL / MPL?
The problem with java and any other non-static linking language is that you *can't* "link" (in the *static* way that lgpl require?) with a lgpl library due to java's dynamic binding *sigh* Please explain this to me and every other java developer that now, for instance, can't use jboss as a application server. This by the "new" definition of lgpl that seems to imply that all applications deployed on jboss also become "infected" (in lack of a better word, english isn't my native language... sorry).
In my experience, free beer exists only if you're a cute college coed at a frat party...
The GPL's purpose is not to make impossible to make money off of software. I would argue that it, in fact, makes it easier to make money off software than a BSD style license.
Say for example, you write some great code widget and you decide to open source it. You decide to use the GPL. Now, some company comes to you and says, we'd like to use this piece of software, but alas, we can't GPL our software. So, you offer to license them a copy of the software under different terms for a few. They likely get cheap software, and the community benefits from you have a little extra cash to spend time working on your widget.
Now, take this same situation and use a BSD style license. You release your code, that company takes it, and they may or may not contribute it back to the community. The code costs them nothing and you get no financial benefit for your work. It becomes harder for you to spend the time working on the project.
This sig has been temporarily disconnected or is no longer in service
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.
That's what they say:
The GNU license (GPL) has its roots before modern Object Oriented languages became popular. It is viral in nature since it affects all code that extends or uses it. It is not entirely clear about where to draw the lines as to where external software gets "infected" by GPL's viral nature. In fact, one could easily argue that with Java, where everything is a library (class), any code that includes a GNU component must convert into GPL. [my emphasis]
The Enhydra Application Server provides an environment for application code to be loaded and executed, thus extending the original functionality of the base server. This is the primary way of developing systems built with Enhydra, and one might say that providing such an environment is the primary purpose of an Application Server. This is thus clearly incompatible with the GPL license since all the code that you might develop must also become GPL.
The LGPL takes the GPL license a step in the right direction by addressing libraries and clarifying that code that uses a library can carry any license, while code that modifies the library itself is subject to the LGPL license. We don't feel that we can use it because the Enhydra Server is not by any definition a library, but is a server or platform designed to call other code. Although LGPL has been used in Open Source Java initiatives, we believe that it still suffers from GPLs ambiguities for Java and we don't ever want to have to change our license again!
Now that Brad Kuhn has weighed in and the article submission has been updated accordingly, who am I supposed to believe about the nature of LGPL and Java -- the guy from the FSF, or the guy from the FSF?
I suggest that this should be the standard GPL license for any Java project when you intend it not to be viral.
It's true that not many people knew about the reverse engineering stuff in Section 6. But the LGPL does have more-or-less the same meaning as everyone has always thought it did.
No, no, no... Either the damn thing does what it's meant to do or it doesn't. If it won't allow closed source developers to use LGPL libraries without opening a hole in their own licensing the size of a freight train, then it most certainly does not do what it was supposed to do, or at least what everybody has thought it did for however long. The LGPL has practiced a major form of deceit and trickery. We've been had, that's the stance I'm trying to get across here.
I feel straight up lied to, and am going to have to go back and reexamine quite a lot of licensing to remove this ridiculous nonsense if it's in there. Furthermore, I'm going to have to re-examine the GPL itself, because frankly I don't think I can trust it anymore to do what everyone thinks it's does.
So, here is the call:
LIBRARY DEVELOPERS! If you use the LGPL, you're only ensuring that no closed source projects will use your code. Until the LGPL gets fixed, it's just a damn bad idea, in any language! And frankly, after reading these opinions, I'd be concerned about the GPL doing untold things as well!
That good enough? Now, either fix it by defining linking properly in the document, or someone else will do so and to hell with the GPL, the LGPL, and GNU. They're finished. Kaput. Fin. After lying to the open source world for so long, they'd damn well deserve it too.
To put it another way that hopefully illustrates how stupid that definition is:
Say I make code that calls upon an LGPL library:
- If I distribute the library and the closed code in separate installers, I don't fall under section 6, but only under section 5.
- If I create a single installer for both, then I now fall under section 6.
See the ridiculousness of this? Nothing actually changed in any code anywhere, but because I'm now packaging in one zip file instead of two, I now have to leave myself open to reverse engineering and modification of my program by anybody. How dumb is that?
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
Could you kindly tell me what exactly this hole is?
Is it really that important to you that your clients/customers be unable to discover that you used a piece of LGPL'ed code? Is it important that they be unable to discover how you used that library?
...follow the terms of the license, or don't use it.
You're completely right. Please, people, follow this advise. Do not use the GPL. It's a pain in the ass for everyone involved.
If you want it to be free, use a free license like BSD/MIT. Nobody is going to sell your code unless they make substantial (incredibly) changes or incorporate it into a much larger project.
You don't make any sense at all. The BSD version will lose when you make a more restricted closed fork? Why?
But remember the "Freedom Zero" debate. Tim O'Reilly commented that the first freedom of free software, and he called it Freedom Zero, is the freedom to choose which license you use to release it. RMS rejected this concept, calling it "Powerplay Zero", saying in effect that only the GPL is acceptable.
ESR then challenged RMS publicly: if you had the power to require all software to be GPL software, would you do it? RMS did not answer. A "yes" answer would be consistent with his other public statements, however.
So I don't know if we can prove that one of RMS's goals is the eradication of commercial software, but his public statements are consistent with that position. A relevant quote from the "Powerplay Zero" essay:
Proprietary software is an exercise of power -- it harms the users by denying their freedom.
By the way, RMS has never been opposed to people charging money for software; he just insists that the software must be under the GPL (and thus come with source code, be subject to forks, etc.). This, in the real world, means that there is a (fairly small) upper bound on how much one can charge for the software.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
If your normal software license is of the draconian "modify a single bit of this software only under pain of death" type, then you have to modify your license to allow the user some basic freedoms. (The right to modify the binary code on their machine and the right to reverse engineer to the extent necessary to debug said modifications)
Of course, depending on country and state laws where the consumer is, they may have this freedom already. And even if they don't, a legal notice isn't going to stop someone with a hex editor.
Every app is a library? Since when? Sure, you can reverse-engineer a Java application to find out how to call the libraries it includes, but you can do that with any application written in any programming language. So why doesn't the same argument apply to C++ libraries, say?
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
I do not fail; I succeed at finding out what does not work.
BSD License: Essentially public domain.
GPL: Creates a completely separate public domain; stuff goes in but never comes out.
LGPL: They had to maket this one so that people wouldn't all go BSD.
Personally, I think that people who hate Sonny Bono & friends' perpetual copyright games ought to prefer BSD to GPL. The whole point of public domain is that anyone can use it, for any purpose. GPL seems more like an attempt to make sure that no code, ever, anywhere can be proprietary.
An even smaller group understands what the GPL is actually for. These are the diehard RMS zealots who think nobody should be allowed to keep code private.
I use the GPL because I want to release my code and get the benefits of open source collaboration but I don't want to subsidize proprietary competition. I agree with Tim O'Reilly who said that the freedom of choosing a license for original works is a fundamental freedom, and that this extends to commercial software as well.
So it doesn't really bother me that Windows is proprietary, but I think that Linux would be as prevalent today as BSD if they used the BSD license and I don't think that IBM would be contributing if they knew that Sun could take their changes and use them to better compete against them without any repayment of any kind! The GPL is a very strong license for many types or projects, but it is one of many licenses and if you choose to release your work under a different license, more power to you.
LedgerSMB: Open source Accounting/ERP
Ok, I admit that these are both good licenses, but they have different strengths. I might use the BSD license if I had a pre-existing community and no creditable proprietary competition (Apache) or if my project was originally predominantly a research project(*BSD, PostgreSQL) where proof of concept and industry influence are more important than widespread adoption.
But what if you are trying to write a new, say, OS. It will compete with various different operating systems and anything you write may find its way into your competitor's products. This is what I refer to as subsidizing the competition, and if you are trying to make money off your product, it is NOT what you want to do. The GPL provides for this by leveling the playing field.
This is not to say that BSD licensed OS's have no market or that one cannot make money off them, but they cannot be competitive in the same way that a GPL'd product can be.
LedgerSMB: Open source Accounting/ERP
well in MS's case its because whatever they change was pushed upon to to many computers and everyone else has to deal with their crappy ass software.
But aside from them i don't think it applies to anyone else
Like I said, people are worried about the negative emotional baggage with the term "viral" and ignoring its true fitness for describing the GPL.
Wrong again. The term "viral" both carries negative emotional baggage and is a poor analogy to the GPL. I've already explained this, but I'll go over it once more for you. Do pay attention this time.
Something that make perfect copies of something else is not viral, so no, a file server that copies files or anything else is not viral.
What if the file server hosts a copy of its own source code? By your standards we should look past the bad connotations and call it "viral" because it makes perfect copies of itself. Obviously that's wrong. Unlike a virus this is not self directing, someone has to initiate the copy. The same is true of the GPL. It doesn't sneak into code against he will of the author; someone has to deliberately and consciously put it there every time.
No, I'm not stretching the truth. Virii are parasitic, yes, just like the GPL. Once a project has been released as GPL, it is forever so and cannot be revoked; it is attached forever.
Please pick up a dictionary and look up "parasitic". A parasite is not defined by being attached forever, but by doing harm to an unwilling host. Furthermore, most licenses -- including the BSD license -- are effective for the duration of the copyright (so the GPL does not last forever, alas) on a work released under its terms. While GPL encourages people to apply it by forbidding derivative works under an incompatible license, this is clearly not parasitic behavior.
I suppose you're right that you're not stretching the truth, since you've barely even noticed it.
However, they do NOT always take without giving. [irrelevant wittering about baceriophages omitted]
Exceptions to the parasitic rule of natural viruses are completely irrelevant, as are scientific attempts to turn them to useful purposes. The GPL is not a molecule and has no meaningful resemblance to those molecules we call viruses. But don't be dissuaded from attempting to change the subject since you obviously know precious little about the one at hand.
And no, replication is NOT beside the point. It *IS* the point, the only point, in calling the GPL viral. [...] it attaches itself permanently to people's code and replicates itself perfectly.
Again, this is complete nonsense. The GPL does not attach itself to anything. A person may make the decision to accept its terms and replicate its conditions or refrefrain from creating derivative works. No self-replication is happening and there is no parasitic relationship in sight. Nor is this process any more permanent than the results of applying a BSD license.
Clearly you have an adgenda here that has nothing to do with the facts. Maybe you're angry because the GPL doesn't let you misappropriate the work of others, or maybe you're just jealous that some high profile GPL licensed project is more popular than your favorite. Whatever. I look forward to shredding your next round of specious rambling.
Not all those who wander are lost.
I've always liked the word "crystalline" to describe the effects of the GPL.
- First they ignore you, then they laugh at you, then ???, then profit.
the rapist is back. hi there , rapie
Now you're just trolling. That's a sure sign that you've lost the argument and you know it.
I refuse to address your questions.
I've noticed. I'm sure that if you had the intellectual capacity to address them you would. Instead you pretend that your empty assertions and unimaginative are a substitute for argument. That's just pitiful.
I have nothing to say now which I haven't already said.
No? Let's recall what you've said so far in support of your absurd claim that the GPL is viral. I've removed some of your most silly errors for the sake of clarity.
A virus, whether of the computer or biological variety, strives to give its host no choice at all. This is altogether unlike what the GPL does and therefore does not justify claims that it is viral.
The term viral actually isn't a good fit. That there is negative emotional baggage merely suggests that those who insist on using it are motivated by some petty jealousy or a desire to misappropriate the work of others.
Does that mean other licenses that can't be revoked, such as the BSD license most other licenses, are also parasitic? No. It simply means you don't know what a parasite is.
A bird making a nest in a tree has attached itself and is likely to replicate, yet no sensible person would call it a parasite because it does no harm. Clearly you don't know what a parasite is.
The GPL is no more permanent than any other copyright license and neither attaches itself to anything nor performs self-replication. One must consciously choose to incorporate GPL covered code into a project in which case one can comply with it's terms by using the GPL or any compatible license for the work as a whole. Therefore your statement is wrong from begining to end and does not justify the claim that the GPL is viral.
The existance of a project licensed under the GPL is not in and of itself an example of a viral property. Otherwise the existance of a BSD licensed project would indicate a viral property of that license, and so on for other licenses.
Apparently when the going gets tough, Cranx rounds up a bunch of fourth grade students from a local playground and asks them for tips. Unfortunately, none of this is justifies the claim that the GPL is viral.
Give it up Cranx. You're just not good at this sort of thing.
Not all those who wander are lost.
Actually, I spent less than ten minutes making that bullet list. You see, this game is quite easy for me. I can play as long as you like.
Oh, and the GPL is not viral.
Not all those who wander are lost.
you like to jump intoxicated men at fucking clubs you fucking asshole.
i reflect upon this poem, it reminds me of you, after you you know wat
Careless of your innocence
Enchanted by your youth
I wanted you
And for you greatness
Fame I never had
Me a lonely man
And you, what can I say, a sexy lad.
Careless of your innocence
But knowing of your needs
And wanting you
I catered to your fantasies
Fathering I never had
Me a jaded man
And you a knowing lad.
Careless of your innocence
I bared my love and lust
Careless of my own
But I found a friend and son
Family I never had
Me a loving man
You a loving lad.
D'you want to be aborted little fetus?
Or d'you want to enter the world?
D'you think you'd like pollution?
Politics and war?
Or maybe a religion
And settle an ancient score?
You don't know what it's like out there
Your mama doesn't want you
And your papa doesn't care
And you'd be a pain
A drudgery and a drain
D'you want to be aborted little fetus?
Or d'you want to experience?
D'you think you'd like sunsets?
Dogs, jokes and sex?
Or the thrill of mind and muscles moving
And knowing you're a being
Who can love?
You don't know what it's like out there
Your mama doesn't want you
And your papa doesn't care
And you'd be a pain
A drudgery and a drain
But then again?
You being a code thief must know what you are up against. You know the ins and outs. You fucking thief. Everyone now knows you rip and steal code you fucker. From O'reilley all the way to ripping off stuff off of Usenet and Google complete with comments, you are a thief. And you know it.
GPL protects the world from fuckers like you. The world knows you steal. You contribute no patches. You have no public progressions that show you doing the work. You are a fraud. A doll. And you are a freakish ass who steals and lies. You take GPL and act like its BSD; you steal.
You will be uncovered as an unoriginal thief. Then try getting work in the valley. Mwaahahah. Haken. Blacklisted in Si. valley. You'll be rimming more fags for a living in the Castro you fucking bastard.
Microsoft loving Slashbotting motherfucking asshole. You lie and you grovel here for attention because your homosexual lover fucking hates you.
I make an absolute valid point, and do so in all seriousness, with no sarcasm, nor baiting, that cuts right to the heart of the whole Free vs free issue (and points out that its bollocks), and what happens? Some fucker Trolls it. Hurray for Slashdot! Lets use "Troll" when we mean "Censored".