As I know some WordPress related developers are using CodeIgniter (CI) as well, I think it’s worth to share:
It’s true that CodeIgniter needed some simpler to handle license, but the outcome so far looks rather devastating and is paralleled with scare among the PHP based framework’s users and with misunderstandings of the new license by lead developers.
From a BSD-like license to OSL 3.0, a license with strong copyleft for network usage.
For the future use this means: If you can browse a CI-framework 3 website, you’ve got the work distributed to you. The website owner must provide you the source-code under OSL of the derivative work she/he created otherwise termination is in effect.
Permissive: Off / Reciprocal: On
This conflicts with much of the common usage and will be a show-stopper for those who don’t want to release their CI applications under OSL. Looks like this is preventing upgrades to CI version 3 for many who can’t change to OSL.
For example those who had previously sold their applications to their customers under a proprietary license, like the many CMSes that are based on CI. Or those who use as well GPL’ed code, the OSL is GPL incompatible. As the OSL is broad about what’s distribution (like the AGPL, not the LGPL), it does not allow these and other type of use but requires distribution under OSL.
There is an ongoing thread on the CodeIgniter forums (CodeIgniter changes license to OSL 3.0?) where users want to know more. In the project’s feedback tracking system a new request has been opened to change the license again (GPL compatible non-copyleft popular license).
Next to the burden the pure fact of switching from permissive to reciprocal is introducing to users of the framework which are scared by this step, the lead developer located @ EllisLab went into duck-and-cover mode after the topic was brought up and discussed in the forum.
The current licensing practice is questioned by their own users and it looks like that the choice of the OSL license hasn’t even been fully understood by the CodeIgniter project as they put files with conflicting licenses into the package.
The description of what you can do with the original work [“translate, adapt, alter, transform, modify, or arrange”] to create a derivative work based on the original work is turned upside-down and asked earlier the reaction was to pass-on a link to OSL 3.0 Explained written by Lawrence Rosen, the author of the license. But that document is very specific about what a derivative work is and modifying the CI code inside the application folder (ignoring config files for a moment which should not be copyrighted at all) by extending classes looks like a simple alternation to me.
For example, the CI developers are putting fragments of the code they distribute under the AFL (Artistic Free License) inside. This would be allowed under the OSL if a collective work is formed. A collective work requires that two independent works are brought together. If the two works are not independent to each other but the one work is based on the other, then it’s a derivative work. But for derivative works, the OSL requires that it’s under OSL as well. As the code under AFL is not an independent work, but extends from CI code, it must be licensed under OSL, not AFL. So the fact that the CI developers put the files in there under AFL while putting other files in there under OSL leaves the overall code in a contradictory state on the licensing side as it either can’t be licensed under AFL or CI itself can’t be under OSL.
Derek Jones defends the files being AFL. Taking that interpretation to a maximum, you’re free to even replace files from CI with your own files and licensing, because your file is not under OSL and must not be compatible. But there must be something special with CI, because Derek talks about derivative works as well:
So what is a derivative work in Derek’s eyes now? Is it based on the directory a file is placed into in the end? Obviously not, what a derivate is and what not is defined by copyright law in your country and is very specific to the original authors expressions in the concrete code. However as normally any code that is based on the CI framework and that is making use of the patterns and structures expressed therein is supposedly considered a derivative work, because it’s based on it. That won’t be a problem if the licenses of the code would be compatible, but with OSL this is very often not the case. So if you code anything based on CI 3 under OSL, play with the thought that you’re creating a derivative work and need to license it under OSL as well. You can not choose any license you would like as it was generously suggested by Derek. And obviously the license would not make much sense as a reciprocal license is for generous sharers of software. So share your code, that’s what the license is for, share your code with everybody using it:
Another thing that looks not to be much noticed is the fact that OSL distributes over network even when only a part of the application can be accessed, like a website as the front-end of it. Under OSL this counts as distribution [“Remote Deployment”] regardless that the application is installed on another computer. As clicking a link on a CI based website is sending a command into the application (Router and Controller, CI refers itself to the MVC model), the website is the user-interface of the software and any user has rights under the OSL, like getting the source-code which only runs on the server.
Next to that, OSL also requires that you make visible to any user to whom the software is communicated to (visits your website) that it runs on an application that is licensed under OSL. Be it a collective work or a derivative work.
Overall, the OSL does not sound like a developer-friendly license for a PHP framework if you want your users to work with it, especially as CI has not been similar licensed from it’s very beginning.
Other PHP Frameworks are often available under a MIT or BSD license, like Symfony2 or Zend Framework. This prevents many problems, from different kind of business models with the software you develop, compatibility across licenses and last but not least, the license is known. OSL is not widely used and there are better alternatives for developers. If you’re looking for copyleft, consider the GPL instead otherwise ensure that your application is already complete.
Related: What is Open Software License (OSL) ? (27 Oct 2011; by Kenji)