CPL
From APIDesign
Common Public License is an open source software license originally used by Eclipse later superseded by EPL. Most of the software projects already migrated from CPL to EPL, but one important project has not done that yet (as of January 2011): JUnit. This essay describes my experience when trying to marry CPL with NetBeans IDE so the project primary sponsor can redistribute JUnit without worries of any kind.
The whole process went through several stages. Don't get surprised that the point of view changes few times. The real world is/was changing too.
Contents |
CPL is Unacceptable
We have new lawyers. The old Sun lawyers are gone and as we are getting more and more integrated into Oracle, we need to align with its culture. One of such cultural checks is to re-approve all the open source licenses used by NetBeans.
Our new lawyers seem to be concerned about CPL, the JUnit license. True, JUnit's use of Common Public License is unique and sort of archaic. I don't know about any other (important) project using this license anymore. But the CPL was found OK by Sun lawyers and we've been shipping JUnit for years! What can be so horrible with it that now it is a problem?
Why we are holding the NetBeans release and getting ready to remove JUnit from our standard installation? Is not that silly? JUnit is necessary part of any serious Java development. What can we do to allow JUnit and NetBeans to cooperate and get approval of Oracle's lawyers for that?
CPL is Not Modern
OK, let's try to ask on a JUnit mailing list. Maybe the group would not mind upgrading to more modern license. At the end EPL is almost identical to CPL. Be polite:
Don't you want to relicense JUnit to some more commonly used license? EPL would be fine. At least I have not heard any complain about EPL from our new lawyers yet. Dual licensing to CPL & EPL probably too.
Asking on a mailing list of Open source project can yield various results. Either complete silence. Or enormous amount of opinions. The JUnit's mailing list is however one of the best I've participated too. I've received quick answers with a bunch of valuable reactions and points (including reactions from people I'd never expect to be on such mailing list).
From that I have understood that Kent does not want to relicense, but rather offers commercial alternative license for companies scared of CPL.
CPL is Great!
While reading the reactions provoked by my query on the mailing list I've noticed an explanation of why CPL is so great. It is approved open source license (good), but it scares some companies (a bit similar story to GPL) so these companies rather pay (good) than redistribute JUnit under CPL. This is perfect! Open source projects need donations (read WhyGPL for details) and it seems that CPL can generate some revenue. Good!
The wording of the CPL states, that as soon as a company redistributes your software, it cannot sue you for violating any of own software patents. Excellent! Open source developers hate software patents in general and this is a perfect way to fight with them. Release your software under CPL, wait until Oracle (or others) use your software and then just violate any of their patents without a risk. I don't think violating patents shall be a hobby, but it can easily turn into a profitable business plan. If the amount of companies using your software grows, some big company (like IBM) can knock on your door and buy rights to your software to enjoy this patent free violation too.
There is a great potential in CPL!
Pay for CPL
CPL seems great for library providers. However Oracle just can't afford to use it. Thus we were about to buy an alternative license, but we have a problem. While backed by a company NetBeans is open source project too!
I can imagine buying a commercial license is good for closed source projects. But how can a commercial license be suitable for an open source project like NetBeans? If we want to stay open source, we cannot have a commercial license on one of our libraries! We need to have an open source one. We need to let 3rd parties to take parts of our IDE and use them in an open source manner.
I hoped the JUnit guys to have some experiences with such dual licensing, but I guess nobody knows what to in such case. Time to seek different alternatives!
CPL is Dead!
As few guys pointed on the JUnit mailing list (including the current Steward of EPL), the EPL license supersedes CPL. This means that EPL is not just more modern license, it is more modern version of the same license.
Also it turned out that the language of CPL/EPL allows anyone to upgrade the license of the covered software to the latest version of the license. In this case one can freely replace CPL with EPL without asking for a permission anyone (not even the authors of the code). Quite surprising revelation.
This means that CPL is dead and EPL can be used instead for all CPL covered projects.
The Right License
For a while it looked like CPL is a perfect license for an open source project as it can make it profitable. Companies (especially in US) have to play the patent games and the wording of CPL is really anti-patent like (which shall be largely applauded by the open source guys). Any larger software house just has to donate the development of the project to keep its patent portfolio safe. If the CPL was used on majority of open source projects, the software patent industry would likely collapsed (no wonder lawyers object)!
However at the end it turned out that CPL does not deliver on its promise to generate donations. As an open source author you may believe so, but the automatic upgrade clause just restricts your freedom and gives someone else (Eclipse foundation these days) right to change license of your project whenever they wish (which basically happened with the release of EPL and agreement that EPL supersedes CPL).
The story resembles the furore when RMS decided to release GPLv3. Not everyone likes the third version, some would like to stick with GPLv2, but alas, the default file header in many software project allowed anyone to pick any later version produced by FSF. I guess at that time many projects changed their files to exactly specify the version (like Linux does, kernel was always stictly GPLv2).
On the other hand dealing with multiple licenses is problematic even now. Multiplying this by number of versions of each license will make the proliferation of licenses even more problematic. This is a good reason to allow upgrade to most recent version of each license. Under the assumption that you trust the license steward, otherwise you may be surprised when new version is out.
It is dangerous to sign blank checks. When choosing a license for your open source project, choose the one that gives you control over its version or over its steward!
<comments/>
External Sources
- IBM's CPL FAQ
Follow
