It’s frustrating how much we open-source developers have to learn about open-source licences; especially in the world of high-reuse.
There are 54 OSI-accepted licences in existence. They largely come down to the central two, GPL and BSD, with a horde of bits in between. The Mozilla licence is listed as a third type and has lead to various variants.
The GPL is viral (for all the good and bad of the term; humans are viral too) and makes anything it touches GPL (to some interpretation of the legalese). The BSD is very open (too open for GNU).
LGPL exists as a way to ease the virality for an essential case, but the legalese refers quite specifically to concepts from the C/C++ library.
Others have the same problem. The Artistic licence with which Perl is licenced refers directly to Perl and C in its clause 9.
SCO have shown that the world of open-source is not immune to the law courts, though they’re not trying to win a case but just to make money from corporations who can afford to pay. The MPAA/RIAA and who knows who else are creating legal knotholes in which it could become illegal to purely develop and so it pays for us open-source developers to have legal protection, which is most likely when banded together. ie) the ASF.
This is where we hit the brunt of this grumble. Said legal protection states that the LGPL licence, for languages other than C/C++, is viral in the same way the GPL is. This means that a cost of our legal protection is that we shouldn’t (and in the case of the ASF can’t) depend on LGPL projects unless we release our code as LGPL.
A year or so back the issue got a bit of noise. The FSF’s Eben Moglen gave an interview to Slashdot and said:
The language or programming paradigm in use doesn't determine the rules of compliance, nor does whether the GPL'd code has been modified. The situation is no different than the one where your code depends on static or dynamic linking of a GPL'd library, say GNU readline. Your code, in order to operate, must be combined with the GPL'd code, forming a new combined work, which under GPL section 2(b) must be distributed under the terms of the GPL and only the GPL. If the author of the other code had chosen to release his JAR under the Lesser GPL, your contribution to the combined work could be released under any license of your choosing, but by releasing under GPL he or she chose to invoke the principle of "share and share alike."
The question was:
One issue that I know has come up for me is how the GPL applies in situations where I'm using GPL software but I'm not actually modifying it. For example, I write a Java application, and it is reliant on a JAR that is GPL'd. Do I then need to GPL my software? I haven't changed the JAR in anyway, I'm just redistributing it with my software. The end user could just as easily download the JAR themselves, it's just a convenience for me to offer it in my package.
The question was really on the GPL licence for Java, which states that in the FSF’s opinion the GPL licence is as viral in Java as it is in other languages. As a sidenote, he suggests that in the FSF’s opinion the LGPL is as unviral as it is in C/C++. The problem is that this does not seem to match with other legal views (what a surprise) and it would seem that the only solution would be a rewrite of the LGPL etc. I’ve no idea where, but I’m pretty sure I’ve heard that a patent-handling variant of the GPL should be expected someday, so maybe the FSF will detach the technical C/C++ speak from the LGPL and make it a better licence.
So we’re left with a choice. Ignore the world of lawyers, sueing, insanity and ravacious corporations and go with the intent; or allow the open-source split (Linux vs BSD etc) to continue to exist in the world of open-source Java.
My personal solution is to keep my personal code in the former, and any code that might become popular in the latter.
