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.
