While this is a very welcome news, the choice of GPL as the license has me a bit concerned. Two years ago, I was researching the various open source licenses like mad for our own open source project OpenI, and decided against GPL because of its "viral" nature (we ended up with Mozilla Public License, MPL). The "viral" aspect of GPL (section 2(b)) says:
You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
and later further clarifies:
..it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
When someone uses programming language software like Java to build their own software, it is tricky to determine if their work is "derivative", "collective", or a "mere aggregation". In such a case, all the software code is written in Java. The software requires a Java Runtime Environment, which acts like a virtual operating system, to run. So, Java as a software construct becomes very tightly coupled with each new software program built on Java.
This is a contentious issue where there has been a lot of debate. See this blog entry at O'Reilly and its comments back in 2004
For example, with Java being GPL now, what happens when I build a software program in Java and would like to distribute it along with a Java runtime engine (JRE) for user convenience? Since I have built the software using Java and I am combining the JRE in my distribution, will my software be considered a "derivative work" or a "collective work"? If my software is considered "derivative" than by definition of GPL, I *MUST* distribute my software under GPL, which can severely affect the commercial viability of my software.
So, who decides what is derivative vs collective? Unfortunately, most likely it will be lawyers rather than software developers. And that may very well cause at least some amount of concern amongst those who build commercial (i.e. non open source) software using Java for a wider distribution (i.e. for use outside of one's organization, most probably selling commercially licensed copies of software to customers).
Now it is probably unlikely that Sun will come after commercial software developers who use Java claiming their software fits the category of "derivative". However, if any organization has to spend any legal resources to investigate this, it affects the use of Java in commercial space.
I think Sun should make it very clear to the community why they chose GPL, and how they want to assure the community (both open source and commercial) that their software development efforts in Java are not subject to the "viral" aspect of GPL.
UPDATE: CLASSPATH EXCEPTION TO THE RESCUE
After digging through more details, I found 2 things that address my concern:
1. Sun is distributing Java under GPL with the ClassPath exception, and describes in their FAQ the reasons behind this -- with an example almost the same as I posted earlier where the classpath exception allows me to distribute my software written in Java bundled with a JDK or JRE without requiring GPL:
It allows you to link an application available under any license to a library that is part of software licensed under GPL v2, without that application being subject to the GPL's requirement to be itself offered to the public under the GPL.
2. Following one anonymous commenter's suggestion, I read the original GNU Classpath license text , and it does clearly describe the exception:
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module.Still, my suggestion to Sun still remains the same: you can't assume everyone will go through the trouble (granted it wasn't much) of digging through the details of the classpath exception, and as such, they are likely to remain under false assumptions re GPL restrictions on Java. So, don't assume -- everytime you mention Java and GPL, make sure you talk about the classpath exception and how it enables you to distribute your software written in Java under any license.
7 comments:
I would say Java programmers have nothing to fear. In reading about linux kernel module programming, where the issue was: can there really be such thing as a non-free Linux kernel module - one of the tests mentioned to see if a Linux kernel module was "derived work" was whether the particular kernel module actually depended on Linux or not. So for example, VMWare, nVidia, etc. modules - because they are ports from other operating systems, are clearly not derived work.
So, I believe that as long as competing non-free JVMs exist under which your Java code is also able to run, it should be pretty easy to prove that your software is NOT derivative work.
csirac2
Also, Java uses the ClassPath Exception to the GPL, which will enable you to keep your code closed, should you wish to do so. Besides, Sun will always be happy to provide you with a commercial license for Java should you want such.
Thanks csirac2 and berend.
csirac2: re your "as long as non-free JVMs exist" comment -- with Java being GPL, won't the existing non-Sun JVM's be required to distribute under GPL since they are a derivative of Java? Or, is it a case where JVM's should be considered separate entity from Java language, and as such are not affected by GPL?
berend: so if I intend to distribute my Java code under a different open source license, the ClassPath exception doesn't cover it? In that case, it doesn't make much sense to buy a commercial license from Sun for an open source project. Also, I'm pretty sure that a lot of existing Java-based software don't bake in a license fee for Java itself, so that will have a negative impact, should one be required to get a commercial license from Sun.
since you've been studious enought to study the GPL ... http://www.gnu.org/software/classpath/license.html
Thanks Anonymous. That link helped, and I have updated my post. I still think that Sun should make it clear in their main message what the Classpath exception means. It will address a lot of unnecessary FUD that goes along with GPL.
I'm glad you found those Classpath links. I do agree there's a lot of people like you out there that don't completely understand how GPL or the scope of software copyrighting/licensing works.
I also agree with you that it would be wise for Sun to post some sort of easily accessible clarification on what GPL means for Java users. I know too many of my peers are usually confused (to varying degrees) about GPL and open source works.
This isn't anybody's fault, I mean we're supposed to be the technical types! Copyright law is boring :-)
In regards to your question: do I think competing non-free JVMs will now need to become GPL'd themselves?
To my understanding, no, for two main reasons:
1. Copyright law means you still retain ownership over your own blood, sweat and tears that is your code that you wrote yourself. Sun can't take that away from you just because they are offering a new license on their own copyrighted works.
2. GPL contract/"License" - you have to agree to and actually USE some GPL'd code before you are bound by the terms of that GPL/License. Unless non-free JVM writers have suddenly downloaded the GPL'd code and started using it in a huge way, they can't randomly start feeling pressure from a software license that has nothing to do with them.
Non-free implementations are written by and are the hard work of people who still retain copyright on that implementation, so they can license their own copyrighted works as they see fit. Besides, they already have licensed whatever it is they need from Sun to get Sun's blessing as a certified alternative JVM product. The fact Sun has released a GPL'd public version of their own product is irrelevant.
For anyone who doesn't like the new public GPL'd version, they can continue to do what they were already doing and license Sun's code on a commercial case-by-case basis. For as long as Sun owns the copyright on the GPL'd code, they can offer that code to anyone and everyone with as many different licenses as they want. One of them happens to be the GPL.
I just don't see how Sun could have jurisdiction over other people's code, or how anybody could be forced to GPL code that they wrote themselves and own copyright on. Only a messy patent/"IP" claim could possibly do something vaguely like that, in which case the fact Sun's JVM now has a GPL version would be the least of their worries!
The countless mountains of closed/binary-only code out there compiled with gcc should provide a pretty solid reference point. Those binaries are generated with fair chunks of GPL'd code, like various slabs of ASM code such as that which comes with statically linking GCC's crt.o in various forms, and dynamic linking of libc (practically every C app does this).
I really don't see how you could prove that Java code is suddenly derived from or includes GPL copyrighted works, just because you're writing in a language that has an open source implementation.
One exception of course are the class libraries. I've only ever had a passing interest in Java, so I don't understand the Java infrastructure that well. But I think I've read in the past (unrelated) about "patterns" and "structures" having some vague copyright protection: so if your implementation of something is heavily influenced by the way some Java class/library allows you to solve the problem, who knows... thankfully Sun have recognised this concern with their Classpath license exceptions.
Of course, as they say, IANAL but I play one on Slashdot ;-)
My opinion is worth exactly what you paid for it, perhaps even less!
Cheers
- csirac2
Woops! Showing my ignorance there - Classpath is of course nothing to do with Sun :-)
Post a Comment