CodeIgniter goes Copyleft with OSL

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.

The code, which is currently developed by many on github, did suddenly undergo some major license change on October 20th for release 3.

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.

Derivative Works

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:

Remote Deployment

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)

This entry was posted in Linked, PHP Development, Pressed and tagged , , , , , , , , , . Bookmark the permalink.

10 Responses to CodeIgniter goes Copyleft with OSL

  1. Christian Cross says:

    What a shame. I considered to use this framework, but the prospect is just scary. Their dev head talkes about employing lawyers to check the new license.
    So they changed the license before they had any idea about the implications? That seems like locking the stable door after the horse has bolted.
    If a lawyer is what it takes to be on the safe side I guess other people will run, too.

    • hakre says:

      Over the last week or so:

      CI: We have a super cool new open source license. It’s great. You can do anything you like! It’s super special and flexible as hell. It has Open Source in its name!

      USER: Why did you change it? OSL? AFL? For what’s is it good? What about GPL’ed code and commercial use?

      … days are passing by …

      CI: We can’t answer your questions, because our lawyers don’t want us to talk about licenses. In the meanwhile we tell you: We have a super cool new open source license. It’s great. You can do anything you like! It’s super special and flexible as hell. It has Open Source in its name!

      I wonder if this is going to become epic.

      Personally my favorite is the part to change from permissive to reciprocal for a PHP framework (!) while it’s in running operations (!!). Or wait, the copyright they claim. That’s probably the best part.

      Okay, a PHP dev might not want to read this: They should ask Ruby, how to make things less and not more complicated.

      • Yes, things would def. have been simpler if they’d gone with BSD or MIT. However, as I understand it the /application/ folder can be any license (except GPL I guess). So you can have commercial products and/or permissive licensed products based on CodeIgniter.

        • hakre says:

          Sure, BSD or MIT would be much better. Such a well known license helps developers to easily deal with the framework.

          Next to the huge problem of the GPL compatibility you name, what about this one:

          Have you seen any written statement by EllisLab that they have clarified with a lawyer (and that lawyer says it’s 100% OK) that they could put files in the application folder under AFL (not conflicting the OSL)? I only read disclaimers in the last days. And they tell everybody that they need to ask lawyers on their own. So this is far away from something “can have” nor answered. They actually say that you should ask your lawyer first. As I wrote in my article here, the OSL is pretty precise when you can and when you can not, if you create a derivative work, or your code is not an independently written work (which the application folder in CI definitely is not), those files are to be licensed under OSL.

          The point is especially important because OSL is an AGPL like copyleft license.

  2. Derek Jones says:

    hakre, OSL has no viral component. It does not care what license you use for files that link to or are packaged with it, and its license does not extent to folders, or files that don’t carry a prominent OSL 3.0 notice. That requirement is a legal one that is in the OSL 3.0 license itself. If the file doesn’t say OSL 3.0, it’s not OSL 3.0. And that file’s license does not reach to other works, certainly not to your independently written code.

    • hakre says:

      > OSL has no viral component.
      OSL 3.0 is a reciprocal open source license. You know that but you write the opposite. Don’t you think other’s won’t notice?

      Link or other technical measures are explicitly not a criteria in the OSL, if you want the OSL to not apply to your work, just don’t create a derivative work, or a collective work with dependently written code.

      I’ve seen you being misleading on this since day one. As you don’t know my code, or code of others, you can not tell everybody that the OSL would not apply to them. Because you don’t know if others are creating derivative works or not.

      Even more important you do not even try to get legal help in a productive manner and clarify common points.

      Not helpful Derek.

      If you don’t want the OSL to apply for everybody else, choose another license for CI. You already know the solution.

      If you want the OSL, you should not hide away the problems this can create but openly and explicitly talk about them. It’s not easy to outline what a derivative work is or not, and this problem will have any of your future users that don’t want to put their code under OSL.

      Next to that the OSL is not GPL compatible. Not everybody likes the GPL or perhaps a person that is a proponent of it, but many like software under the GPL. You brought this to the personal level, your feelings about the GPL. Feelings are totally uninteresting. We either use software because it makes sense or we don’t. I don’t go for feelings, I go for facts. And if the licenses are incompatible, you’re out of the game. That simple it is.

      Fix this. Don’t make so much words, just fix it. Everybody will thank it to you.

      • Derek Jones says:

        Your questions should be fully answered in today’s post. And disagree with our conclusions if you like, but I must note that I have not misled or lied about our conclusions as you imply.

        • hakre says:

          You’re missing it’s a demand: GPL compatibility and non-copyleft license.

          Next to that in no way gives Rosen a guarantee that calling something a library and telling everybody they would link to it, does not create a derivative work.

          And now you’re lost again, the general problem to decide about the derivative state of a work still exists. You have not written/published something with a legal base according to the state of derivative-ness for the files you’ve put under AFL. Unless you don’t provide something that is legally clear about that, I won’t trust you about those files.

          Where is your legal analysis?

          And no, a finished application like Magneto is not really comparable with a PHP framework. You make this argument anyway only to keep users in a sleepy state:

          You trivialize the complex legal context about derivative works in software because you know that your users don’t want to use OSL for their code. You try to make something comfortable while others know already what they want – for understandable reasons. But you’re not open to that solution, you even ignore very valid arguments.

          Rosen is not only the author of the license, but as well lawyer of Magneto (or was at that time). He also needs to protect his client I guess. Just a hint to not read too much out of words.

          Additionally you write in your latest article that OSL would only apply if something has been modified. That’s not the full story again about the OSL, it does apply as well if no modifications are made.

  3. Pingback: EllisLab: Copyright not by work but per File | hakre on wordpress

  4. Pingback: EllisLab, you’re doing it wrong | hakre on wordpress

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s