Will OpenJDK never contain other GPLed code?
David.Herron at Sun.COM
Thu Aug 16 18:22:40 UTC 2007
Volker Simonis wrote:
> On 8/16/07, Volker Simonis <volker.simonis at gmail.com> wrote:
>> On 8/16/07, David Herron <David.Herron at sun.com> wrote:
>>> Volker Simonis wrote:
>>> On 8/16/07, David Herron <David.Herron at sun.com> wrote:
>>> Volker Simonis wrote:
>>> During the discussion on a different thread on this list regarding the
>>> disassembler library for the HotSpot I realized, that although the
>>> OpenJDK is released under the GPL, it is currently impossible to
>>> contribute or integrate other source code, that is also licensed under
>>> the GPL, into OpenJDK, because it would be probably impossible to get
>>> a Sun Contributor Agreement (SCA) for such code. And SUN will probably
>>> refuse to integrate code into the JDK that can't be integrated into
>>> the official SUN J2SE distribution which is not GPL.
>>> In the OpenJDK FAQ (see
>>> http://www.sun.com/software/opensource/java/faq.jsp#n3) SUN
>>> "..when we chose the GPL as the basis for Sun's open-source Java SE
>>> implementations, we made it easy to combine the open-source JDK code
>>> base with other GPL-licensed code bases such as GNU/Linux, GNU
>>> Classpath, Kaffe, GNOME, and others".
>>> That's true, however the other way round, combine GPL-licensed
>>> software with OpenJDK becomes impossible because of the need of a SCA.
>>> Therefore it becomes impossible for OpenJDK to profit from GPL
>>> software. Notice that I'm speaking about the "official" OpenJDK here,
>>> not any branches thereof (like for example IcedTea), that don't have
>>> these problems.
>>> Is this intended? Any comments?
>>> Does the SCA FAQ answer any questions?
>>> In particular the SCA has the contributor assign joint rights so that
>>> both Sun and the contributor own the contributed code.
>>> - David Herron
>>> Yes, but this is exactly the problem. Let's say there's some very
>>> cool, GPL-licensed software that OpenJDK could benefit from (in the
>>> case I'm refering to this was binutils). You can't put it into
>>> OpenJDK, because SUN uses the OpenJDK sources to build its non-GPL JDK
>>> and you can't get SCAs from all original authors of the software in
>>> So OpenJDK, although licensed under GPL, is effectly still bound by
>>> the SUN JDK, which is not GPL licensed (at least with respect to
>>> already existing GPLed code)!
>>> Maybe this isn't spelled out carefully enough .. but the scenario you're
>>> describing is why the contributor agreement has the contributor agree to
>>> joint ownership of the code. I've been told by the people who worked with
>>> the lawyers, that the joint ownership allows us to redistribute the code
>>> under different licenses. We are following a dual license model, as you
>>> note, distributing code under both GPL and non-free licenses.
>>> Before code can be contributed to any Sun project a contributor agreement
>>> is required from the contributor. The scenario you're describing cannot
>>> happen. Or, put another way, for some project with several owners, you're
>>> right that it would be very hard to track down all those owners and get them
>>> all to sign an SCA. Hence it's a good thing that the SCA requires dual
>>> ownership of contributed code. Without dual ownership, 10 years the Sun
>>> projects would be having a wide range of owners making it difficult to make
>>> any legal changes...
>>> I found this page to have some similar considerations
>>> - David
>> I understand what you want to say and I think I also understand SUNs
>> dual licence policy. After all its not a bad policy and I didn't
>> wanted to criticise it. I just wanted to point out the conclusion that
>> this dual-licence policy makes it impossible to contribute
>> 'single-licenced' GPL code to OpenJDK and consequently, OpenJDK will
>> always remain a SUN project (what's not bad - again, no criticism
>> here). This point only has not been obvious to me...
>> I think as of today, most of the available GPL code is single licenced
>> only under the GPL (making things kind of easy) but in recent times,
>> more and more companies begin to release their software under dual
>> licences (one open, not even necessarily GPL and a closed, commercial
>> licence). Combining code from such projects will only be possible in
>> the "open" part, and this will irrevocably result in project forks.
>> Hopefully, this won't happen to OpenJDK soon!
> I just realized that the last three posts on this topic havn't been
> cc'ed to the mailing list. At least from my part, this happend
> unintentionally. Would you mind if I will repost my last message that
> conttains all the other posts inlined to the list?
> As an addendum to our discussion, I also found the article "Does dual
> licensing threaten free software?" by Glyn Moody quite usefull and
> interesting (see http://linuxjournal.com/node/1000069)
Hi Volker, I do agree we should have had this discussion on the list.
Okay, hmm, it remains to be seen how successful we will be using the SCA
to entice contributions.
But I don't understand the "single licensed" code. I do think it
depends on the individual contributor as to whether they will see fit to
agree to the SCA. The GPL doesn't, so far as I can tell, prohibit an
individual project from dual licensing code. If it did then Sun
wouldn't be able to as we are doing with the OpenJDK because we're using
both GPL and non-free licenses for the same code.
I'm sure there are other organizations using the same GPL/non-free dual
license model. er... MySQL for instance is available that way.
On my earlier reply to you I spent awhile looking at the MySQL website
to see their contribution policy. But they don't seem very open to
outside contributions in the first place.. this page is where they list
outside contributors, and it says at the front the MySQL AB owns all the
copyrights, and then the type of contributions they list are usually not
about the code to the database but ancilliary things.
That makes MySQL not a good organization to look to for a model of
gaining contributions while dual licensing the code.
- David Herron
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss