CPL

From APIDesign

Revision as of 19:59, 17 January 2011

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 convince my company lawyers to accept CPL, so NetBeans can redistribute JUnit without problems.

The whole process went through several stages. To capture the feelings, my post will also go through several stages. Don't get surprised that the point of view changes between individual sections. My view of the real situation changed as well.

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 ten years! What can be so horrible with it that now it is a problem?

Why we are 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?

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. So let's ask:

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 result into two options. Either complete silence. Or enormous amount of opinions. The JUnit community is however different. I've received quick answers with a bunch of damn good 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 its 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. Or wait until IBM decides to buy your rights to your software to enjoy this patent free violation too.

The things CPL can achieve are so great!

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!

That is why 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 copyright holder). Quite surprising revelation.

This means that CPL is dead and EPL can be used instead for all 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!

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 their wish (which basically happened with the release of EPL and agreement that EPL supersedes CPL).

This sort of 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 Free Software Foundation. I guess at that time many projects changed their files to exactly specify the version (like Linux does, kernel is 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/>