This story was bubbling around the j.n forums yesterday, and there has been some discussion about what the license for use with the FLOSS Java will be.
While the question of what does the GPL mean if you extends Object.class which may be GPL it seems there is another case to be made here:
What if the core java.* and javax.* classes became LGPL and the runtime became GPL? I think this is an interesting thing to discuss for several reasons:
First, the GPL for the core runtime would in some ways “protect” Sun’s investment in their JRE. Unlike less contagious licenses, it would guarantee that nobody takes the JRE, enhances it and packages it as a product outside of Sun’s domain. If Sun is committed to open source Java, then the re-rolling of external contributions into the runtime won’t affect them in the future. Additionally, the LGPL on the core library means that external optimizations and bug fixes will be available to merge back into the core.
I know the GPL is seen as a “political” license, but it seems to me the best way for Sun to ensure that they don’t see, say, Redmond, lift the JRE code and run with it in a radical new direction is to adopt a contagious license. LGPL of the rt.jar doesn’t affect the state of ISVs and developers who just write Java apps, any more than glibc does people who write Linux apps. The primary question here, however, is how many customers does Sun have that include the core runtime tightly bound into their products on a License from Sun for whom this would be a problem. My guess is there are likely one or two who might take issue with this approach.
Afaict, Sun has the liberty to arrange the licensing with their RI customers under whatever licensing suits their mutual interests best, judging by the fact that the RI is available under BCL, SCSL, JRL, JDL, JIUL and DLJ licenses, which serve different purposes and different target groups.
The GPL/LGPL would just be an additional option for us non-RI-customers, and serve goals that are in the mutual interest of Sun and the open source community.
Right, however those licenses all deal with one-way code transfer. The advantages of the GPL with "open" forks would mean that if Sun ever pulled in contributed/forked code, they would be locked into the GPL for all distributions. No more JRL or SCSL licenses as an option, or transferrable binary licenses.
That's what joint copyright agreements / contribution licensing agreements are for. It's pretty standard procedure for most large open source projects.
I must be missing something on that, though. I generally thought the whole point of contributed similarly licensed code was it broke out the copyright status to the individuals, and only the license remained the same.
That seems very much like if Linus decided he was going to take the whole kernel code and give IBM a license to distribute an enhanced, binary only version. Once he took code from other people under the GPL and added it to the kernel, he effectively lost that right.
One of the problems I have with the current "open" JDK stuff is you have to go through a whole legal department to contribute a one line patch. Seems like if Sun demanded copyright transfers from everyone, it wouldn't really be much more "open source" than it is at the moment. It would also mean they couldn't absorb enhancements or bug fixes that game from GCJ for instance or any other semi-forked project that borrowed from the Sun code.
Well, sorta. Most major open source projects have some sort of contributor agreement that involves either a) assigning copyright to the project b) joint copyright or c) licensing the code to the project. That includes Eclipse, FSF's and ASF's projects, OpenOffice.org, and so on.
The idea is in general to have
a) a clear paper trail for each line of code from the authors in case problems arise
b) a way to address problems without having to involve each contributor individually
For example, b) matters in terms of proving that you've got the right to deal with copyright violations, for example, as in many countries, enforcing a license is something that only the author, or agents authorized through him can do.
Different projects have different arrangements. The FSF for example, that handles contributor copyright assignments for GCJ, promises not to license your contribution under a non-free license, and grants you back the right to relicense your work to others as you see fit.
See http://www.gnu.org/licenses/why-assign.html for FSF's reasoning.
I've been involved with projects with different policies on handling contributions: at Kaffe.org, we do it as Linus does. At GNU Classpath we do it FSF's way, and at Apache Harmony, we do it ASF's way. Sun uses a joint copyright ownership model on OpenOffice.org and OpenSolaris, afaik.
Each policy has its pros and cons. ;)
I guess I am just kinda out of the loop there. I have contributed to any number of projects, but I have just always assumed the "Linus" model -- I retain copyright on my code and it retains the attachment of its licence. Granted for ASL or BSD licensed projects that is less invasive, but I have always assumed that was the norm.
Indeed, one of the things that has always prevented me from contributing to the Sun managed products was the "agree to our lawyerisms before we take your patch." It seems to me one of the advantages for the "Top 9" OSI licenses is people understand up front what the terms are without the lawyerese.
Indeed, the Linus model is the norm, at least for volunteer ran projects, as the administrative cost of setting up, and running the required buerocracy beats the potential returns.
I (and many others) are far more concerned about the little clause in the GPL that forces all work derived from GPL code to be GPL as well.
As all classes ultimately derive from Object, lawyers would have an extremely strong case to argue that every single Java class written against a GPL core library MUST be released under GPL as well, essentially destroying the usefulness of Java for commercial software development.
If you want to protect your investment, you can't release it under GPL (and in fact if you value your own work you won't).
The politics in the GPL are the sole reason the GPL exists, to destroy commercial software development.
Well, and again, I think releasing java.lang.Object under the GPL *would* be a bad idea. However, it seems to me using the GPL compiler/JIT and LGPL for rt.jar classes model that GCC uses wouldn't adversely affect ISVs/end users but would have advantages to Sun in terms of fork control and investment protection.
> LGPL of the rt.jar doesn't affect the state of ISVs
But then, why didn't Geronimo use JacORB (LGPL) as its Orb? Can Apache-licensed code use LGPLed code? Or is it just, that Geronimo wouldn't have JacORB bundled with its code?
c.f. this posting:
http://article.gmane.org/gmane.comp.java.geronimo.devel/20555/match=jacorb
FWIW, Sun's implementation happily uses (and contains, afaik) LGPL licensed code (CUPS, libasound), so if LGPL licensed code is good enough for Sun to build and distribute their current, proprietary JDK implementation on/with, I doubt anyone else can make a case for LGPL not being good enough for ISVs.
LGPL obviously works fine for ISVs like BEA, IBM and Sun, or they wouldn't be using code licensed under it in their class libraries.
Regarding the JacORB discussion: the issue with JacORB was the same for Geronimo as was for GNU Classpath, afaik.
JacORB used the official OMG IDL files to generate the org.omg classes. The IDL files from OMG come with a license that does not allow modification, so it's not open source. Since both the ASF (Geronimo) and FSF (GNU classpath) are committed to writing and redistributing Free Software, neither ASF or FSF would want to ship the IDL files.
It turns out that ripping JacORB apart from the OMG files is non-trivial, so GNU Classpath ended up having its own CORBA-compliant ORB and open source org.omg classes. I believe Geronimo went for a similar solution.
It wasn't an issue where the LGPL prevented an ISV from using the code, it was OMG's proprietary license on the org.omg files that did.
And the GPL wins!