ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

CodeIgniter changes license to OSL 3.0?

October 21, 2011 6:55am

Subscribe [20]
  • #1 / Oct 21, 2011 6:55am

    Hello, I have read that CI is going to change its license to OSL 3.0, but, what does it mean? Will I have to license my software developed with CI under the same OSL? Could I develop non open source and non free software with CI?
    Thank you in adavanced for your response!

  • #2 / Oct 21, 2011 10:47am

    Derek Jones's avatar

    Derek Jones

    7561 posts

    Agustín, the short answers:

    Will I have to license my software developed with CI under the same OSL?

    No, only derivative works to the CodeIgniter source files that are under OSL must be reciprocally licensed.

    Could I develop non open source and non free software with CI?

    Absolutely.

    http://rosenlaw.com/OSL3.0-explained.htm.

  • #3 / Oct 21, 2011 10:58am

    deckard

    20 posts

    Hello Derek,

    I just found out that your GIT commit states that the application folder will be under AFL. (you should have mentioned that in our private conversation).

    Anyway, the application folder being under AFL in general is better than OSL but seems still not compatible to GPL, see http://www.dwheeler.com/essays/gpl-compatible.html.


    Excerpt:

    Avoid the “Academic Free License” (AFL). It has been claimed that the AFL was a “compatible upgrade” from “licenses such as BSD and MIT”, but this is a misleading claim; as the FSF notes, “the modified BSD license and the X11 license (aka MIT) are GPL-compatible, but the AFL is not.” (at least version 1.1 and 2.1 are incompatible, and I believe that AFL version 3 is incompatible as well). The AFL has some nice properties from a legal point of view, but its GPL-incompatibility is a serious failing that completely dwarfs those advantages. Projects such as SHPTRANS have noted the AFL incompatibility as a serious problem, and have chosen to not use the AFL for this reason. At one time some people in the OSI recommended the AFL, but as of July 30, 2007 the OSI lists the AFL license as being “redundant with more popular licenses”, and pointedly does not include it with “Licenses that are popular and widely used or with strong communities”.

    My question:
    If EllisLab wants to give us real freedom on our own application why not explicit state that you we can use whatever license we want in the application folder? I am not interested in the CI code, just want to keep the GPL on my own app code.

    Regards

    Carsten

     

  • #4 / Oct 21, 2011 11:37am

    Derek Jones's avatar

    Derek Jones

    7561 posts

    If EllisLab wants to give us real freedom on our own application why not explicit state that you we can use whatever license we want in the application folder? I am not interested in the CI code, just want to keep the GPL on my own app code.

    To be clear, the folder is not under AFL; you can’t license a folder.  AFL is only applied to the the files we provide as defaults (config, error pages, the Welcome sample controller).

    Please refer to §1(c), specifically: “Under AFL 3.0, Derivative Works of AFL 3.0-licensed Original Works can be licensed under other licenses, and the Source Code of those Derivative Works need not be disclosed”.

    How is this stopping you from using GPL on your own code?  The AFL certainly doesn’t care.  http://www.catb.org/~esr/Licensing-HOWTO.html#id2853340

  • #5 / Oct 21, 2011 12:02pm

    deckard

    20 posts

    :-(

  • #6 / Oct 21, 2011 7:06pm

    Thank you very much Derek! All my doubts are clear now! Thanks!

  • #7 / Oct 22, 2011 8:49pm

    Mytosis

    21 posts

    Why don’t you consider to switch to a more compatible license like MIT or APACHE 2.0?

    I have the feeling that CI core under OSL has more impact than you outline here, especially the viral nature of it. That’s a big difference to the current licensing.

  • #8 / Oct 23, 2011 5:38am

    Phil Sturgeon's avatar

    Phil Sturgeon

    2889 posts

    Plenty of developers hate GPL and the OSL gives more flexibility. What is the down-side?

  • #9 / Oct 23, 2011 6:18am

    deckard

    20 posts

    Hello Phil and Derek,

    Plenty of developers hate GPL and the OSL gives more flexibility. What is the down-side?

    Yeah, right. That’s a really founded statement. Many people hate Santa Claus, too. (there you go, about the same niveau). This all sounds to me (and the private discussions I had with Derek, too) like you choose the OSL for political reasons not for anything else.
    And I still do not understand why a more compatible license wasn’t chosen, I did not hear one real fact about this except for “GPL is too political for us”. How would the MIT or APACHE 2.0 license not fulfill your needs? What is indeed the critical point for your choice of license?

    I am still interested how you did get agreement of all past CI core contributors to switch the license? Can you please give us details on that since you already made the switch? Or are you in violation already?

    I am still not sure how you could run any GPL software inside the app folder without the OSL and GPL license conflicting because they the will form a single package. I think EllisLab is taking here a license turn for the worse. First you have been sloppy in license questions (pardon my language) and now you desperately try to rectify it but it feels you are doing the same mistake again.

    Let me give you a few example what your future users or CI won’t be able to do:

    Examples:

    *You like to have Excel/Word export in your application? Well, will never happen from now on because the well known libraries PHPWord and PHPExcel are under GPL.
    *Oh wait, there is the ODF format (Libre-Office). Too bad the according libraries are under GPL (see http://www.odtphp.com/index.php?i=dev&p=Odf ) Same for ODS (the Open Office excel format) see http://sourceforge.net/projects/ods-php/
    *....
    The list goes on. You are creating an unsafe situtation for your users here. Do you really think every user can employ a lawyer to test your pretty fragile claims of compatibility? With this decision you users will be always on the brink of being sued.

    I think if you keep OSL on future versions then any GPL package currently running on CI won’t be legally able to upgrade to newer versions. A great way to lock out any past user base which used CI as part of their open source project - well done (note the sarcasm).

    It would be nice if you can give answers to all my questions above and not leave out the inconvenient ones. CI is a great framework - we want to keep using it - but under safe conditions - and I guess most of your users want the same.

    Best regards

    Carsten

     

     

  • #10 / Oct 23, 2011 6:28am

    Phil Sturgeon's avatar

    Phil Sturgeon

    2889 posts

    We had a private discussion?

    Anyway you are blowing this way, way, way out of proportion.

    The current code sitting in the application folder is ASL, which means you can edit it, reuse it, do what you like. If you delete everything from inside the application folder then it is not ASL anymore, because the code is not there and not carrying the license.

    OSL to me seems to be less restrictive than GPL. You can still put any license code in there as you always have been able to.

    CodeIgniter is OSL, not your entire app. If you download a library and put it into your application folder nobody cares what license it is. Do you think EllisLab are going to come after you with lawyers because your application has a GPL/MIT/FOO license in there?

    Let’s turn it around. What would be better or different if we WERE using license X or Y. Point out the benefits because while I am not a lawyer: what we have seems fine.

  • #11 / Oct 23, 2011 6:52am

    Mytosis

    21 posts

    OSL is reciprocal, like GPL. It might sound less restrictive, but with all it’s contract elements it’s less a license but a very differntiated catalogue of non-trivial things to match - especially compared to the current licensing.

    So for me as a developer, the OSL is more restrictive than the current license - it might have been written with the best intentions but in practice it’s introducing lots of problems if you bring it in after some time where codebases already exist.

    It’s not a permissive license at all. So I think you’re underestimating the burden OSL brings into any derivate of CI code, including that code located in the application folder or even forks on github.

    The way that is outlined here putting the application folder aside does not work when you distribute the application - even if you stretch the interpretation of the OSL far beyond a boundary I would choose.

    The original CI License was permissive, so why the change to a reciprocal license? Is viral now the better way for EllisLab? I didn’t located you in that camp.

    Better with a permissive license like MIT for example would be that it’s much closer to the current “Ellislab License” while choosing something thats known and compatible to existing code bases.

    Because of the viral nature and the requirements of the OSL, it’s a burden to distribute applications based on CI in the future - be it with no costs attached or commercially. It does not help much that someone in a forum says the license will never be enforced.

    This will affect existing projects.

  • #12 / Oct 23, 2011 7:04am

    Phil Sturgeon's avatar

    Phil Sturgeon

    2889 posts

    It does not help much that someone in a forum says the license will never be enforced

    I did not say that, I said EllisLab will not take legal action against you if you add in some code which happens to have a GPL or MIT license into your application.

    Let’s say I make an application that sells shoes and I want to export my sales data. I’ll dump PHPExcel in there which is GPL. In your view this would be a breach of the OSL license. In my view that is absolutely trivial, irrelevant and a non-issue.

    CodeIgniter used to use GPL, now it uses something else. The fact that it was GPL never effected my commercial products, client websites or personal projects for over 6 years. How will this change effect those either?

    The license is for CodeIgniter, not your application. You can use CodeIgniter IN your application, but it is only CodeIgniter that is licensed.

    You say MIT is better. Why, specifically?

  • #13 / Oct 23, 2011 7:51am

    Mytosis

    21 posts

    It does not help much that someone in a forum says the license will never be enforced

    I did not say that, I said EllisLab will not take legal action against you if you add in some code which happens to have a GPL or MIT license into your application.

    CI is a framework, you normally build applications on top of it that are often distributed, for example to a client.

    The OSL is viral which means if you create a derivate of CI, you need to stick to it for your application - with all the obligations - even if you “only added some code”. That’s a change to the current licensing and has impact on any code you put in there which allowed modification under far less terms. Stick to it does not automatically mean that you must release under OSL as well, but this can be an implication. Just saying, see below as well.

    Let’s say I make an application that sells shoes and I want to export my sales data. I’ll dump PHPExcel in there which is GPL. In your view this would be a breach of the OSL license. In my view that is absolutely trivial, irrelevant and a non-issue.

    The authors of PHPExcel might not like that type of proceeding. Additionally that looks like you’ll loose the rights under OSL which will infact make you loose the right to even use CI. If you call that absolutely trivial, well, what could be a matter then?

    It looks a bit like that it’s some kind of understanding here that OSL would be non-reciprocal and wouldn’t have termination clauses, but as written, I have the feeling this gets stretched too much. It’s reciprocal and it has specific termination clauses, this is very similar to the GPL.

    CodeIgniter used to use GPL, now it uses something else. The fact that it was GPL never effected my commercial products, client websites or personal projects for over 6 years. How will this change effect those either?

    I don’t remember CodeIgniter was using GPL, however it wasn’t in the recent past. I guess merely the same reasons it changed away from GPL to BSD-like would apply to not change to OSL.

    The license is for CodeIgniter, not your application. You can use CodeIgniter IN your application, but it is only CodeIgniter that is licensed.

    Well, talk with a lawyer about what a software derivate is, and you then get a feeling that it’s not a topic easy to outline. Anybody who seriously is making use of the CI code under OSL will run into this question and problems and will need to decide upon for the concrete application she or he creates.

    The easiest option the OSL leaves here as a viral license is to put your own code under OSL as well. As I read you that is not what is intended, but I can not see that in the license choice.

    This won’t work for existing applications that would like to benefit from framework upgrades.

    I don’t say that OSL is a bad license, it’s just that CI is not coming out of nowhere and it doesn’t look like a well fitting new suit.

    You say MIT is better. Why, specifically?

    I suggested MIT because it’s a BSD-like license like the one in CI-2.

    MIT/BSD type licenses have a lot of benefits:

    1. Well known.

    2. Easy to deal with, developer friendly.

    3. Compatibility to existing code: It’s a permissive license much closer to the CI 2 license. This would be compatible to the current use-practices.

    4. Generally a permissive license is well fitting for a PHP framework, look around to the other frameworks that exist. For example Zend Framework, Symfony and many others. Wikipedia has a listing.

    5. MIT is generally pretty compatible to any other license out there if it comes to integrate third party libraries. That’s like 2., it’s developer friendly and will offer the needed options for users of a framework.

    6. Less license proliferation. OSL is not commonly used in the PHP world - if at all.

     

  • #14 / Oct 23, 2011 2:54pm

    Sire's avatar

    Sire

    109 posts

    GPL says OSL is a GPL-incompatible license at this link for those interested and explains why.
    http://www.gnu.org/licenses/license-list.html#OSL

    Are there any specific reasons that OSL 3.0 was chosen over a GPL-compatible license like MIT or BSD?  Just curious what the discussion involved in favor of OSL 3.0.

  • #15 / Oct 23, 2011 3:09pm

    Phil Sturgeon's avatar

    Phil Sturgeon

    2889 posts

    Stuff it, we should just use DBAD.

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases