As I was thinking about Sun's new Community Source licensing principles for Java, I realized that an appropriate metaphor for this type of licensing is the chameleon. The license essentially changes its color based on the kind of software in which the Java source code is included. If it's free Open Source software, it's like an Open Source license in that it allows source code redistribution without restrictions or fees. If it's commercial software, it's more like a commercial license, with fees payable to Sun.
It's useful to compare this to the GPL, which has recently been described as a "viral" license. That's an appropriate metaphor, because the GPL essentially infected any code in which the source was included: no matter what you wanted, you were required to license your code under similar terms. It's the polar opposite of the chameleon license.
With all due respect to RMS, I think it's clear that the GPL significantly retarded acceptance of Open Source software. The GPL was clearly an important statement, but the ideology was way ahead of what most people wanted to practice. We all know people who could not take advantage of GNU software because they didn't understand exactly what the license meant, what they were giving up, what they could conceivably be sued for in a couple of years, and so on. We all know of companies that wouldn't allow any GNU software on their machines because they didn't want to take the risk that someone would borrow a few lines of source code and compromise the company's intellectual property. Whether you agree with this or not isn't the issue; the fact is, it didn't do any good to have a license that made people scared to use the software. A limited version of the GPL for use with libraries (the LGPL) tried to clarify some of the issues and allow users to link to GNU libraries without compromising their own licensing, but in my experience, the LGPL was even less well understood that the original GPL.
The bottom line is that the GPL is fundamentally coercive, and was intended to be so. Morality aside, that just plain hurt the cause. The right way to popularize free software wasn't to threaten people who chose to use it. The net effect was to impose a potential penalty on developers who used GPL software: if you incorporated it into your code, you lost control of your code's use.
This is where the chameleon license offers an important new model. It's much more developer-friendly, and can entice developers to the Open Source model. It's a carrot, not a stick. You can incorporate the Java source code into your product, and still license it in any way you please. If you want an Open Source license, that's fine. If you want a traditional commercial license, that's fine too.
But notice how the cards are stacked. If you want a traditional commercial license, you have to deal with Sun's marvelously helpful marketing and sales people, pay them royalties, do all the accounting that requires, and so on. That's a big burden for a small company to bear. If I were starting out as a software developer, I'd look at that and say "I can go either way. But why not try one of the many models for making money from Open Source software?" After all, there are more than a few companies making money by selling support and high-end features; Cygnus and Sendmail are the first two that come to mind. Although you can go the commercial route if you want, Sun has given you an implicit incentive to go the Open Source route--or at least to consider it.
I'm not sure that Sun executives realize or understand the hidden incentives built into the chameleon license, but they're real, and very much to the advantage of the Open Source community. It's an opportunity that opens the community's doors to pragmatic developers: people who'd like to figure out how to make some money from their work, and are put off by licensing zealotry. It gives them a real opportunity to experiment with different licensing options without penalty, and gently pushes them in the Open Source direction.
Having said all of that, it's important to realize that Sun's community source license is a template that will be used differently by different divisions. And there are certainly pitfalls between the statement of principles and the actual implementation of licenses. As I said in my previous article, two particular things concern me: the idea that the Java instantiation of the license will require a charge for compatibility testing, and some strange language about royalties for "internal deployment". Without belaboring the point, Sun needs to realize that testing fees and ill-defined language about internal use royalties aren't going to help build the community of open source Java developers. The Jini group is steering clear of these trouble spots; I hope the Java license, when it is eventually released, will do the same.
The stark terms of the viral GPL may have been necessary to grab people's attention back in the early 80s; but it's the chameleon license that will attract people to the Open Source community.
