Are implicit dual-licensing agreements inherently anti-open?

[Stéphane Croisier]

Jim Driscoll, currently project manager for Glassfish, has blogged 
"<http://weblogs.java.net/blog/driscoll/archive/2005/07/newest_concern.html>Newest 
Concern on Sun's Open Source Strategy," addressing similar concerns 
over copyright assignment to Sun under the CDDL.

The ensuing discussion thread brings up some interesting points. One 
poster went into great detail about SUN getting a way to for the 
project back to a proprietary license while being able to continue 
using all third parties contributions. Same issue, same debate...

>The CDDL and the Copyright grant are completely independent, and 
>basically unrelated. I think the CDDL is a fine license, as it 
>balances programmer rights and user rights. But as Jim mentioned, 
>copyright trumps license. With copyright, you can change the license.
>
>Several years ago, Borland released the Interbase Database source 
>code as an Open Source project. They then, quickly, turned around 
>and brought it back in house. Obviously, it was immediately forked 
>and today we have Firebird, which as far as I can tell is on a 
>divergent course from Interbase.
>
>Interbase wasn't free long enough for any community work to have 
>been done on it before it was taken back, and I'm not familiar with 
>their license. But it is an example of a company "changing its mind" 
>regarding an open source project.
>
>With the copyright grant of the SCA, Sun has the ability of taking 
>the totality of the work, both original code and new submissions, 
>and forking it for a completely internal, closed source project, and 
>then being able to relicense that code in any way it sees fit. After 
>a year of work, Sun can take the GlassFish project, update it, 
>change it, repackage it and relicense it as "Java AS 10 Super 
>Edition". They can integrate enterprise clustering, managment, etc., 
>and are not obligated to return any changes to the community.
>
>If a community member tried to do the same thing, any changes they 
>made to the original source code that were necessary to implement 
>those changes WOULD have to be returned to the community (at least 
>made available) because of the terms of the CDDL.
>
>So, if I wanted to make GlassFish Enterprise, even though I wouldn't 
>be obligated to release my "Enterprise Management Console" or 
>whatever, since it may well be a new creation and not under the 
>terms of the CDDL, however if I had to make internal changes to 
>better support, say, clustering, those changes are required by the 
>CDDL to be released.
>
>But since Sun holds copyright, they are not obligated by the CDDL to 
>release those internal changes, as they are not obligated to keep 
>the CDDL license on the code.

And:
>Let's be clear. Code licensed under the CDDL is open, and will 
>forever be open. Also, any changes to such licensed code will also 
>be open and forever open.
>This facet is very similar to GPL code. Once GPL'd, the source code 
>is always open. This is an attraction to many open source developers 
>because it promotes community ownership of the code. Once shared in 
>such a way, the code will always be shared. In contrast, BSD and 
>Apache licenses are basic attribution licenses. By agreeing to the 
>license, you agree to give credit to the original, but you are under 
>no obligation to actually release your changes to licensed source code.
>Some contributors consider this aspect of the BSD and Apache 
>licenses a "taking" of the code. Some reel at the fact that 
>Microsoft uses (or used) BSD code in their products "for free". 
>Basically, while the original BSD code is still around and 
>available, Microsoft's changes to that code are dark, and 
>unavailable. Thus the code was "taken".
>The obligation (or lack of) to distribute changes is one of the key 
>distinctions between the GPL and BSD style licenses.
>In the perfect world, a programmer would release some source code, 
>and another programmer would then fix and upgrade the code, rather 
>than simply report a bug or make a feature request. Once that change 
>has been made, the original author could leverage this new version 
>and advance the code again, and so on.
>When code is licensed in a way that such changes are obligated to be 
>released, then contributors can assume that their contributions are 
>not a one way street, that anyone who advances the code for their 
>own purposes will give back.
>When code is licensed in a way where it is not obligated to be 
>released, then some contributors won't join at all because the 
>sharing requirement is not there. No tit for tat. I give, you give, 
>we all give, and the code gets better. Rather, it's I give, you 
>take, you improve, you expand, and I and the community never see any 
>of that benefit. You benefit from my work, but I don't benefit from yours.
>Code licensed under the CDDL enforces sharing. Change CDDL code, 
>release the change, just like the GPL and unlike the BSD/Apache licenses.
>But the key here is that basically with the SCA, regardless of the 
>license used, Sun gets both options. Sun may, at its option, being a 
>copyright holder, take contributed code, relicense it, and no longer 
>be obligated to share it changes.
>This is what I was referring to when I used the GlassFish example. I 
>could, for example, write a PostgresSQL driver for GlassFish so that 
>it is natively supported (like Oracle is now in Sun AS). I could 
>contribute that code into the package, and everyone could use it.
>But Sun could take that code, relicense it internally, "fix it", 
>advertise "New, Sun AS 10 with IMPROVED PostgresSQL support", and 
>not be obligated to release the new improved version back to either 
>me, or the community . To be fair, as joint copyright holder, I have 
>the exact same ability, but you can see the difference when I only 
>have copyright on the PostgresSQL piece, whereas Sun has the 
>copyright on the entire project.
>It is the POSSIBILITY of this kind of code "taking" that could be an 
>issue with some contributors, and while the CDDL is supposed to 
>prevent that kind of taking, the copyright grant trumps the CDDL.
>For example, if someone created "FreeSolaris" as a fork of 
>OpenSolaris, but managed much like the Linux kernel is today (where 
>everyone and their cousin has copyright -- I'm not saying this is a 
>good thing), then those who may not feel comfortable joining the 
>OpenSolaris project, because of the SCA, could well feel better 
>about working on FreeSolaris as it would be managed solely by the 
>CDDL. FreeSolaris would have the ability to roll updates and patches 
>from OpenSolaris (because of the CDDL), but you can't say the same 
>about updates and patches from FreeSolaris going back into OpenSolaris.
>As far as using joint copyright to handle license upgrades, etc., I 
>don't know what a solution to the problem would be. I would guess 
>that there would be some way to create an agreement between the 
>contributor and The Project that contributed code can safely have 
>its license "upgraded" to a later version, but that obviously needs 
>to be carefully worded otherwise there will no doubt be Mack truck 
>size holes in it. The idea there is that the contributor is giving 
>limited rights to the project, but not full copyright.
>It is my belief that the complaint over the Sun projects and the 
>CDDL is related to the SCA and potential of "taking" of code, even 
>though the CDDL really has nothing to do with it. It's easy for 
>folks to conflate the two aspects. In isolation, I find it difficult 
>to see any issues with the CDDL itself.
>I think while the SCA is clearly worded, Sun is promoting the CDDL, 
>and the SCA parts of the agreement are not as well advertised. I 
>think it is easy for someone to think that even by signing the SCA, 
>that the CDDL may still apply to their contributions. There's a lot 
>of lawyering going on here.
>In truth, I don't expect this to ever be an issue, but someone may 
>well chime in when Sun releases Sun AS 9 Enterprise Edition (I 
>believe that GlassFish is more like the Platform Edition, without 
>the Enterprise Edition feature set, I may be mistaken) and wonder 
>why the new Enterprise bits aren't released, even though "his 
>changes" are in it.