Posted by evanx
on May 18, 2006 at 7:52 AM PDT
My earlier blog "Duke in a Tux" mused about Java being opensourced as GPL, as opposed to Apache. Jim Driscoll commented that OpenSolaris and GlassFish are both under CDDL. Since I didn't know what CDDL is (besides being an approved opensource license) I decided it's time to get my dukes in a row on opensource licenses...
Now that Sun's big boys are trying to decide "how" to opensource Java (with the "why" worked out by Jonathan and Rich a long time ago I'm sure), it's time for the little boys like me to get excited about opensource licenses and what they mean.
By the way, I suggested in an earlier blog "Swing trounces Ajax" that Sun will opensource Java to counter competitors (Microsoft, IBM and Red Hat) and their competitive offerings (C#, Harmony and GCJ) because "Sun wants developers to be field of Sunflowers following the Sun." I liked that quote, so I'm repeating it, and I liked that blog so that's why I keep punting it. What I do change with each punt is the title, eg. Swing trumps, thumps, trounces... and who knows what'll be next? ;)
In my previous blog "Duke in a Tux" I mused about Java being opensourced as GPL, as opposed to Apache. This was a silly suggestion because then all Java programs would have to be GPL'ed too! (I suppose the JVM could be GPL'ed and the class libraries LGPL'ed but lemme put that bone aside.)
Jim Driscoll commented that OpenSolaris and GlassFish are both under CDDL. Since I didn't know what CDDL is (besides being an approved opensource license) I decided to do some reading... (Isn't Google great?)
So Google took me straight to Jim's "What is this CDDL thing, anyway?" (June 2005) which is perfectly terse with important links namely Sun's executive summary on "Why the CDDL" , Simon Phipps' "Failed as in succeeded wildly" (April 2005) and Claire Giordano's "CDDL - Is it so bad, then, to be misunderstood?"
(April 2005) which was also a great read on the CDDL.
So the story is that Sun liked the Mozilla Public License (MPL), but it needed some bugfixes, and so that's what the CDDL is - a refreshed MPL after a day at the health spa.
CDDL aims to reduce the proliferation of opensource licenses by fixing up the MPL license for everyone. I get the impression that this was an honest and noble effort on Sun's part. Hey, it now has the full support of this little fish in the sea of developers - hold the presses!
OpenSolaris prompted the creation of the CDDL. Sun has subsequently reused the CDDL for GlassFish. Maybe Mustang will be next? So what is this CDDL, and how does it differ from the GPL and ASL (the Apache Software License)?
Claire explains that the GPL and the BSD-family of licenses (which includes Apache's ASL) where considered for OpenSolaris. GPL was too viral, in that derived works also have to be GPL'ed. So it's not company-friendly in that respect. We know that the GPL is developer-friendly license. Hey I need one of those RMS collars, that processes your speech, and everytime you say "Linux" instead of "GNU/Linux" it gives you an electric shock ;)
The BSD-family of licenses (of which the ASL is the state-of-the-art, Simon Phipps says) is great for companies, since it says "Use this software as you wish, baby, just don't sue me." Not in those exact words of course. I guess they got some lawyers in, and they worked it out.
After the GPL and BSD-family, the third distinct class of license is the MPL (of which the CDDL is the state-of-the-art, Simon says).
The MPL neatly defines "modifications" and "derived works" in terms of files, eg. C source files. Changes to existing files are modifications, and new files that you add to the source tree, are "derived works." I like this because it's clear what's what, innit.
Now to grasp the difference between GPL, BSD and MPL in terms I can understand, let's use Simon's great definition that
"an open source software project is a software source-code commons."
In this case, (re)licensing your software means you are placing it into a "public commons" where everyone can play nicely with it. According to the license of that particular commons of course.
And here's the difference...
In the BSD commons, you don't have to contribute your modifications or your derived works back into the commons.
In the MPL commons, you have to contribute only your modifications back into the commons.
In the GPL commons, you have to contribute both your modifications and your derived works back into the commons.
So it's clear that the MPL is some happy medium between the ASL and GPL licenses. I can see why it's important to have a state-of-the-art bug-free MPL. Enter the CDDL. "I'll take one of those happy meals with the free Mozilla CDDLy toy - hold the BSD fries and GNU cola please!"
Here is Simon Phipps' definition of opensource (April 2005 ).
An open source software project is a software source-code commons maintained by a creative community, which uses the content of the commons to create richness and innovation, with and around the commons. In the process of that creativity, the community enriches the commons for the benefit of all and may be compensated by the recipients of the creative act.
He goes on to say of the CDDL that
the commons is continually enriched... That's GPL-style (copyleft) for your work on the commons and BSD-style for your own creations
So the CDDL is copy-left for modifications (like the GPL), and "free use" for derived works (like the BSD/ASL). GPL is the most restrictive license, and BSD the least, with the CDDL sitting inbetween. The CDDL is less restrictive than GPL (it allows "free use" of derived works) but is more restrictive than BSD/ASL licenses (it is copyleft with respect to modifications).
Someone wrote in a comment to Jim's blog on how Sun manages their CDDL projects. Now this is nothing to do with the CDDL - just how Sun happens to manage these projects, which happen to be under the CDDL. He says that contributors should grant a joint copyright to Sun. Then Sun can relicense those contributions as they wish. So those modifications stay in the common, but Sun (as well as the contributor of course) have the right to use those modifications outside of the commons. For example they could relicense them into a different commons, or use them in a closed product. Without detracting from the rights of contributors, it should be said.
As Jim points out, many groups require this joint-copyrighting, including Apache. And including the FSF, just joint-copylefting in their case of course ;) Apache have their Contributor Agreements, after which Sun modelled their SCA (Sun Contributor Agreement). SCO taught the world the need for these, innit.
The GPL is great for developers that don't want some other company building a closed commercial product using their work. But what if later you wanna relicense your GPL project, eg. under ASL or CDDL, and/or build a commercial system using your project? Maybe for your new best client that is gonna help you pay off your house, by letting you work on your project all week instead of all weekend.
The problem is that if you've accepted contributions, you can't. Because you don't hold copyright over all those little patches - here, there and everywhere - submitted by a whole bunch of handy helpers.
So I think joint-copyright, via a Contributor's Agreement, is desirable. Actually what I had in mind for my little GPL'ed project is to require that any contributions are dual-licensed under GPL and Apache. That means I can switch the whole project to an Apache license in future, and also I'm always free to build a closed commercial product on top of my GPL project, incorporating any contributions by outside parties. Not because I want to take advantage of outside contributions per se, but so that I can accept outside contributions without limiting my future options. The "problem" is that no one else is allowed to build a closed commercial project, because it is GPL'ed. That is a bug and a feature of the GPL.
This does make the point that the license a project is released under, is not the whole part of the story. The terms and conditions of acceptance of contributions is another chapter. I guess in the extreme case, no contributions are accepted, ie. such a project would have to be forked in order to make any "contribution" to the project.
Another case is the requirement that contributions are multiply-licensed, ie. contributed under a different license in addition to the original license. In my example, a project is released under the GPL (the most restrictive license), but contributions to the master source tree are only accepted if made under the ASL (the least restrictive license).
Finally, a common case seems to be the requirement of a Contributor's Agreement which grants joint-copyright. This is an attractive solution for the project originators, since they retain the freedom to relicense their software into another commons, and/or use the software (which is predominantly their own) in a closed product. That is, keep their options open for the future. Also, as the FSF says, it it makes it easier to defend against infringements in court, if you can argue as the single copyright holder (and not one of hundreds).
Traditionally one would assume that contributions would be accepted under the same license as the source is released under, without any further conditions. The point is that there is no guarantee of this, or that contributions would be accepted at all - clearly patches can be, and are, rejected, eg. in the case of the Linux kernel.
Opensource promotes common development, where the idea is to engender a community of contributors. But maybe in some cases it's more about distribution. And in others, it's a marketing gimmick. And in most cases, it's some combination of all of the above!