PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

Not all licenses are created equal

Note: This article was originally published at Planet PHP on 21 April 140.
Planet PHP

IANAL. As you are all are hopefully aware there are huge differences the exact "freedoms" allowed by the various open source licenses. I find that many younger developers have a natural affinity to the GPL, because they seem to feel its important to prevent someone from just taking their code, building upon it and not releasing their changes under an open source license when they distribute. Maybe with enough experience you start to realize that it happens close to never that a proprietary fork of an open source project ends up outpacing the original project. So why bother regulating this? It just makes legitimate business uses harder and in the grand scheme of things, I don't worry about this. People who prefer to go proprietary are likely not in the state of mind yet where I would want to work with them anyway.

So these days I prefer BSD, Apache and MIT licenses. My first open source project PEAR MDB was licensed as BSD. The Symfony2 eco-system is mostly licensed under the MIT. With basically Johannes Schmitt being the odd one out using the Apache license. We moved PHPCR to the Apache license in the early stages of the development push thinking this makes sense given that JCR is also licensed under the Apache license. We also moved Jackalope to Aapche thinking we might one day contribute it to the Apache foundation. There is one trouble here in that I recently learned with Apache 2.0, the FSF considers it incompatible with (L)GPLv2. Note that (L)GPLv3 is considered compatible.

Popular projects like Drupal being GPLv2+ and Doctrine LGPLv2 there is a problem. As Drupal is considering adopting PHPCR/Jackalope they would have to move to GPLv3+, which is easy for them to do since they made sure to include the "or later" when they went with GPLv2. Now for Doctrine the situation isn't so easy since its LGPLv2 without the "or later" option. Meaning we couldn't just drop the LGPLv2. That being said to me the LGPL is very fuzzy in combination with an interpreted language like PHP, but it would be good to avoid such a grey area. As a result all the current core developers have agreed to try and switch Doctrine to the MIT license. Due to its longer history moving the Doctrine ORM and more importantly the DBAL over is going to be quite hard, however the rest of the project is sufficiently young that its feasible to attempt this. Note that the DBAL actually started its life in Doctrine as part of the 1.x branch which in turn was a fork of my MDB project which was BSD licensed. Still since then a lot of code went in and out.

Now the big question is how on earth can we work through such a license change? In short its going to be really really hard. At least in the days of git and github we will not be faced with quite as many patches that were committed by someone else than the creator as back in the day many changes came in via patch files submitted to issue tickets or mailing lists. But there is still the risk of code lifts from other projects that might also be using a non MIT compatible license. So it seems like we really need a tool to help manage determining all the contributors and if they have approved the license change. Then also helping in reviewing individual commits if they are worthy of a copyright (typo fixes and obvious bug fixes do not). Maybe even do some analysis to show is which code portions remain without consent for the license change so that we can choose to rewrite them. Unfortunately I am not aware of any such tool. The only high profile project I remember having done such a change is VideoLan, but at least in their blog posts it seemed like they simply got the permission of their few dozen core developers. Anyway I will follow up this blog post with another one outlining some ideas I have for how such a tool could work.

Now to finish up this blog post I want to touch upon the topic of a CLA. When I first mentioned this issue on twitter, people were quick to point out that a CLA would make such a license change easier. Avid readers of my blog should know that I have spoken out against CLAs quite a lot in the past. The two main reasons is that it adds an annoying legal hurdle for contributors and that all CLAs I have seen include patent clauses which I reject. But it is true that a CLA would enable the entity to which the CLA would be signed to could easily do a license change (which could also be an irritating fact for some). Now there is a different kind of agreement called a Fiduciary Licensing Agreement which is used by the KDE. Essentially it gives the KDE guys the right to change the license, but also to defend the rights of the original creators in court. The difference to the CLA is that a FLA is also useful even if you do not force everyone to sign it. As a result the practice is to simply get people to sign it eventually after several contributions and not like a CLA before eve

Truncated by Planet PHP, read more at the original (another 663 bytes)