Java GPLed?

by Robert Cooper

Well, honestly, when I posted this a few months ago, I didn't actually think the GPL was seriously on the table, but CRN/CMP is reporting (via /.) that Java is set to be released under the FSF's license, with other products from Sun to move that way:
The company is very close to announcing that it will put the mobile (ME) and standard (SE) editions of the Java platform into the GNU General Public License (GPL), with the Java Enterprise Edition and GlassFish reference implementation (currently open-sourced under Sun's Common Development and Distribution License, or CDDL) to follow, several industry sources said.

The OpenSolaris operating system will continue to be offered under the CDDL, according to several sources. The news could come as early as next week, they said.

The GPL is an intriguing and controversial choice. By requiring derivative works to also be released as open source, the GPL discourages commercial forking -- a consequence that fits well with Sun's stated goal of preserving Java's cross-platform compatibility. However, a GPL license would require those making changes to the core Java platform to freely release their code.


Again, I think the GPL is likely a better fit for their goals and concerns as a business than CDDL. Still, I wonder what licensees will think about this move.

11 Comments

Andy
2006-11-08 07:43:03
Although you might be able to get the source via GPL, Sun can still reserve the right to license the source to folks under different terms. I believe that MySQL does something similar, where you can modify and close the source if you are willing to shell out some money.


In addition, GPL is only triggered on distribution of code. I can take GPL software and modify it to my heart's content and keep the source... so long as I don't distribute it to anyone. This is huge for server software. Under most folks interpretation of the current GPL, I could build a web site from modified GPL software and not be under any obligation to release the source. (GPL v3 seems to be looking to change this)


Bottom Line: I think current licensees won't see any changes. The community will get the code in a way that will prevent a closed source fork.

cooper
2006-11-08 07:49:32
Yeah. There is just a lot of muddy in it. Both actual concerns about virility of the license and general FUD from certain rainforest based companies can make this a concern. Going back to the comments in my previous post, to go with a dual open/closed license means legal wranglings for any code from outside Sun proper, which seems like part of the problem the current Java source licenses entail now. Plus the threat that a licensee (or someone on their staff) will pull in external GPL attached code is a legitimate concern if an actual after-market Java community takes off.


Still, I think the GPL is generally a good move, these issues aside.

Dalibor Topic
2006-11-08 08:42:50
I don't get the rainforest based companies reference.
cooper
2006-11-08 09:44:11
:)
Dalibor
2006-11-08 11:21:31
Ah! ;)
Bake
2006-11-08 13:34:01

@Andy: The current draft of the GPLv3 does not obligate you to release source in such a case. OTOH, it does not prohibit you from adding such a requirement. In Section 7b4, we see that it indeed mentions this option and, interestingly, is careful to point out that the license "does not assert that they [the optional requirements] can be successfully enforced by the copyright holder."


2006-11-09 05:48:40
a) Virility & general FUD: I'm sure they'll have a FAQ explaining why the big bad GPL does not eat one's own code. Or an exception, a la MySQL. They've been able to push the DLJ past Debian, after all, so I'm sure they know very well by now how to deal with internet lawyering. ;) Besides, who could you trust on virility, if not the author of the code?


b) Pulling in external GPL code is a very remote possibility, afaict. I'm not aware of any GPLd jitters/garbage collectors/other VM components that would obviously be superior to what's in the RI.

Dalibor Topic
2006-11-09 05:49:49
darn, forgot to sign the above.
cooper
2006-11-09 08:11:24
Pulling in external GPL code is a very remote possibility, afaict

It isn't so much Sun doing that I would worry about, but, for instance, I can imagine a world were JSR-80 USB support -- currently provided in single platform projects under various licenses (CPL/BSD/GPL that I know of) getting pulled into a unified open source JVM. Bam, the GPL Java has a good feature that isn't part of the core. The potential for an employee of a licensee to grab that and build it into their licensed JRE seems very real. Now, whether or not the GPL would attach to that is a point of debate, but I can certainly imagine situations where that kind of thing could happen. While it wouldn't really affect Sun, it would leave a bad taste in the mouth of the licensee.


Bringing up specific stuff like that, however, I really hope we start to see open source JVM branches/bundles. Getting a JVM with jSDL, javax.usb, Tritonus/libLAME, (JOGL would be on the list if it weren't about to show up in the JVM on its own) etc all built in is something that really excites me. (And yes, I am sidestepping trying to start the JSR-277 flamewar here :P) However, that Java-Distro model could pose problems with GPL Java and "Pure" Java getting mixed up.

Carla Schroder
2006-11-09 10:12:01
The GPL is a good fit for Java. Java is everywhere, so the GPL will encourage the growth of a large common codebase. This won't prevent commercial forking- indeed, the 'freedom to fork' is an essential freedom guaranteed by the GPL. Anyway, Java is already forked in the worst ways- we have IBM Java and a Microsoft Java, and they are rife with incompatibilities. Having an open GPL codebase will ensure compatibility, unlike the current state of affairs.


Dalibor Topic
2006-11-09 11:31:29
In that case, I'd expect the good ideas (and probably code) from 'spin-offs' to quickly get merged into the RI, with copyright assignments, and all that. We've done that for a couple of years with GNU Classpath now. Given a bunch of passionate people in a project with a strong culture of sharing, it worked quite well so far.