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]
  • #46 / Oct 28, 2011 8:53am

    Mytosis

    21 posts

    the license was actually changed in the develop branch on [october] the 20th so anyone who develops against edge is now technically beholden to that license. And quite a few of like to keep our projects relatively current to edge.

    Not if you don’t take that specific commit by taking care about the files / changes you take in on the licensing side. It’s still very easy to fork it w/o being bound to OSL at the current state and keeping current. And it will be for a longer time.

    In the end, this is something the developers decide, not EllisLab. But it would be nice to see EllisLab and the developers on the same side.

  • #47 / Oct 28, 2011 8:56am

    kilishan

    183 posts

    True but if you’re going to say that “CodeIgniter is X” most people will assume you are talking about the current version.

    That is exactly the same as saying “CodeIgniter is currently on version 3.0” purely because that is the version number in the development branch.

    It will be, but it is currently not.

    Good point. I missed the fact that there was a release/2.1 branch and was thinking that develop was 2.1.

    [quote author=“Dennis Rasmussen”]And while we’re at it, what’s so good about OSL?
    I “love” this part of the license in section 9:
    If You distribute or communicate copies of the Original Work or a Derivative Work, You must make a reasonable effort under the circumstances to obtain the express assent of recipients to the terms of this License.
    That basically means we can’t fork/clone CI for redistribution on any public version control systems such as github.com

    Yay ! (/sarcasm off again)

    I guess I’m wrong since GPL’s pages seem to interpret this the same way you do when they’re comparing licenses, but it seems to me that by saying obtain the express assent of recipients that means you just have to let them know in the readme on a public vcs, or next to a download link for the app, that the release is copyrighted under the OSL. Doesn’t seem like that much of a restriction to me.

    Personally, because the terms are more clear and linking to a file does not make it a derivative package, I find OSL to be a better license than the GPL. It’s entirely possible I’ve misunderstood things, but I believe GPL says considers linking or a extending a class to be a derivative and must then be covered under the GPL. If that’s true, then I personally think that is a crock and is why I have stayed away from using GPL classes in my own works.

  • #48 / Oct 28, 2011 9:18am

    Mytosis

    21 posts

    I guess I’m wrong since GPL’s pages seem to interpret this the same way you do when they’re comparing licenses, but it seems to me that by saying obtain the express assent of recipients that means you just have to let them know in the readme on a public vcs, or next to a download link for the app, that the release is copyrighted under the OSL. Doesn’t seem like that much of a restriction to me.

    Where have you read such a guideline from the license? Rosen put that in to ensure the reciprocity of the software is enforced and not teeth-less.

    Personally, because the terms are more clear and linking to a file does not make it a derivative package, I find OSL to be a better license than the GPL. It’s entirely possible I’ve misunderstood things, but I believe GPL says considers linking or a extending a class to be a derivative and must then be covered under the GPL. If that’s true, then I personally think that is a crock and is why I have stayed away from using GPL classes in my own works.

    I beg to differ, the GPL is much more clear as it has a much larger community including the FSF so you find much more valuable information about it. This implies that there is a lot of misinformation, too, but that’s how it is if you’re successful. Many users, many opinions and a community process around it. Same would apply to OSL, but this is much slowlier, as it’s not widely used.

    The GPL offers a compromise here btw., and that is the LGPL license. As much as the GPL is clear about linking, it’s clear for the LGPL, too.

    Anyway, Rosen picked up - at a time - the problem that linking is not a term used in US copyright. He therefore decided to not use that term. But it does not automatically mean only because you “link” something you’re not creating a derivative work.

    Especially as PHP code is not linked in that discussions sense. Linking referred to linking between binaries. And even then, there are two ways of doing it: statically and dynamically. Both do not apply to PHP user code. What I can imagine is using an .so file as a PHP module, but that’s for the PHP interpreter, not the user code.

    But maybe you can describe what linking means in your eyes. Would be good to know to better understand what you’re talking about.

  • #49 / Oct 28, 2011 9:43am

    kilishan

    183 posts

    Where have you read such a guideline from the license? Rosen put that in to ensure the reciprocity of the software is enforced and not teeth-less.

    That was just my interpretation of section 9. By putting up a notice of the licensing of the work you are stating that software is bound by it and it is generally accepted anyone using it is also bound by so, by using the software, they basically grant their express assent. Yeah, I’m not a lawyer, and I’m trying to understand all of this myself, but even in the previously linked discussion about the OSL by Rosen he states:

    However, in accordance with expected practices in the open source community, licensees should provide whatever notices are appropriate in order to fairly warn recipients that the Original Work or Derivative Works they receive remain subject to the terms and conditions of the copyright and patent licenses granted by the original Licensor(s) of those works (meaning the OSL 3.0 license itself, its patent defense and all other of Licensor(s) reserved rights and remedies under copyright and patent law)

    I’m not trying to say it’s not enforceable. Not at all, just that you don’t have to have a checkbox that says I agree to the terms of the license and recording that information somewhere so you have proof of that contract between you and them.

    What’s my definition of the linking / creating definitive works? It seems to me that, in PHP, any library we use is dynamically linked, since it is linked at runtime for every script execution. Rosen seems to make it pretty clear that linking and unchanged original does not create a derivative:

    The definition of Derivative Works in § 1(b) is particularly important. For one thing, that defined term includes no reference whatsoever to linking or to any other technical manner of making programs interoperate. The verbs used in § 1(b) [“translate, adapt, alter, transform, modify, or arrange”] reflect the kinds of activities that we generally do to create derivative literary or other expressive works, and those things—not functional linking—create Derivative Works as defined in this license. As a result, linking an unchanged Original Work with another independently-written work does not, absent more, create a Derivative Work subject to § 1(b); such an act is merely the
    incorporation of a copy of that Original Work into a collective work, authorized by § 1(a).

    And he follows this with more discussion that says the same thing under the section on when you must disclose your source code:

    If linking (by whatever technical means) can be accomplished by making and using unmodified copies of the Original Work, then 1(a) and 1(c) permit that; only the Source Code of the Original Work must be disclosed.

    To me, this sounds like I can create a MY_Controller which extends the OSL-protected CI_Controller without it being forced into the OSL since the CI_Controller class is the unchanged Original Work.

    Like I said, I’m just trying to understand this myself, and in so doing, help others understand it, because I sense there was a bit of a knee-jerk reaction when the license was changed.

     

  • #50 / Oct 28, 2011 10:54am

    Andrew Tomaka

    5 posts

    Regardless of what you think is legal or not, any court would look at the INTENT of the copyright holder if it ever became a legal issue.

    Maybe, but intentions change.  If the license is unclear of certain points that may cause problems with some developers, it’s in their best interest to find another solution; even if it is not the intention of Ellis Labs to cause that issue.

    I haven’t read through the new license and compared it to how it might effect me (something I’ll do this weekend) and to see if the change is being blown out of proportion, but seeing some of the comments in this thread are scary.  If there is a loss clarity or compatibility when compared to using a more common license, it would be irresponsible for many of us to continue using Codeigniter compared to something with a “safer” license.

  • #51 / Oct 28, 2011 11:10am

    matula

    8 posts

    Couple of quick questions…

    Has anyone, anywhere, EVER been sued because they used two differing open source/public licenses that weren’t totally in agreement? 

    Also, if the framework is under a OSL 3, does that mean that any code that extends the framework is ALSO under that license? IANAL, but my reading of it is that you can do whatever the hell you want in the application folder, with any GPL/MIT/WTF licenses and that’s all peachy.  It’s only if you start messing with the system folder, and trying to add in GPL code there that a problem would arise.

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

    Mytosis

    21 posts

    What’s my definition of the linking / creating definitive works? It seems to me that, in PHP, any library we use is dynamically linked, since it is linked at runtime for every script execution.

    Sounds like your understanding of linking can be generally described as executing different fragments of source code together in a script interpreter.

    If linking (by whatever technical means) can be accomplished by making and using unmodified copies of the Original Work, then 1(a) and 1(c) permit that; only the Source Code of the Original Work must be disclosed.

    To me, this sounds like I can create a MY_Controller which extends the OSL-protected CI_Controller without it being forced into the OSL since the CI_Controller class is the unchanged Original Work.

    Like I said, I’m just trying to understand this myself, and in so doing, help others understand it, because I sense there was a bit of a knee-jerk reaction when the license was changed.

    If extending a base class is or is not creating a derivative work of it, that’s something you should ask your lawyer. What I have learned, it is. But it’s your own right to contact a lawyer on your behalf that can clarify it for you. Let’s just don’t speculate about it, but hypothetically say you’re right with your assumption as there is another point I’d like to highlight:

    Your interpretation and understanding of “linking” shouldn’t stop you from taking over (unmodified parts) of the original works (it must be works then, as CI core files “link” to each other all over the place as well) as long as you take at least one of the original works (a file or a function) under OSL intact. Until you’ve replaced everything, then you don’t use any work under OSL in the end.

    So if you’d like to take the stance that this is all dynamical linking, well, then OSL is a pretty ineffective license at all. I wonder why it has been chosen, if I follow your arguments, nothing stops you from taking only the parts you want and just drop the license for anything else including over the core files (which are merely undefined).

    Do you really think Rosen didn’t think about that? Or is this just a common loophole in the OSL license? I place my bet that you first need to find out if you’re really creating a derivative work or not and then you would know if you would have created the named collective work you want to benefit from. Take note as well the other work (your application) must be an independently-written work. Ask your lawyer what that means 😉.

    And your argumentation still does leaves problems with popular and widely used licenses like the GPL as this won’t work for it. This might not be an issue for you personally, but I think you’re clever enough to imagine that this is a problem. It’s not only OSL specific by the way, but you find some comments to the OSL here as well: Make Your Open Source Software GPL-Compatible. Or Else. (by David A. Wheeler).

  • #53 / Oct 28, 2011 11:42am

    Mytosis

    21 posts

    Has anyone, anywhere, EVER been sued because they used two differing open source/public licenses that weren’t totally in agreement?

    I think if somebody get’s sued it’s a little late. Normally if that are FLOSS projects, conflicts are getting resolved out of court as nobody has a real interest in suing somebody else. Those conflicts lead to resolutions, for example to obtain GPL compatibility.

    Also, if the framework is under a OSL 3, does that mean that any code that extends the framework is ALSO under that license?

    If that extending results in a derivative work, sure. That’s what the license is about.

    IANAL, but my reading of it is that you can do whatever the hell you want in the application folder, with any GPL/MIT/WTF licenses and that’s all peachy.  It’s only if you start messing with the system folder, and trying to add in GPL code there that a problem would arise.

    You mix a couple of things here. If you intend to distribute your application and it contains GPL’ed code (regardless where), you must distribute the whole package under GPL. As it contains OSL code which is not GPL compatible, you can’t do that. So for GPL’ed code this makes always a difference. That’s why most common licenses are GPL compatible. Pretty simple.

    For the other licenses it depends. As long as you’re creating a derivative work, you must distribute it under OSL. If you create a collective work, the independent written work can stay under it’s own license, the OSL licensed work stays under the OSL. Both licenses do apply for or in your collection of works. In case that you use code that is incompatible licensed to the OSL for collective works, you’re blocked as well.

    So it can not be generally answered that this or that is always okay and everything peachy as you worded it. That’s why there is so much criticism with the license change to OSL. It’s not commonly used, it has strong copyleft (which must not be an issue as long as you want to share your code under OSL), it’s incompatible to the GPL. And to know if your application is a derivative work or not, you need to contact a lawyer.

  • #54 / Oct 28, 2011 12:04pm

    matula

    8 posts

    If that extending results in a derivative work, sure.

    I guess I’m just unclear as to what “derivative” means in the open source context. So here’s a (probably very rough) example…

    I make a class file: awesome.php

    class Awesome {
        public function do_awesome_stuff($var) {
            return "Hey Buddy! Here's the awesome thing you sent: " . $var;
        }
    }

    Now, I release that class with the OSL 3 license.  Someone else comes along and wants to use that class in their code, but they release THEIR code as GPL:

    require_once('awesome.php');
    $awesome = new Awesome();
    echo $awesome->do_awesome_stuff('Bad Wolf!');

    If the new code is released and packaged with the original class file, and they both follow the “rules” of each license, what’s the problem? As long as I don’t go into the original class file, muck about, and try to re-release it… I can’t see how there would be an issue.  Though, again, I’m not a lawyer… so if I’m WAY off base with my assessment, I want to know.

     

  • #55 / Oct 28, 2011 12:16pm

    Mytosis

    21 posts

    I guess I’m just unclear as to what “derivative” means in the open source context.

    That’s by copyright law, so nothing specific to the category of software but it relates to software (as a copyrightable work) and other copyrightable works in general. See http://en.wikipedia.org/wiki/Derivative_work

    If the new code is released and packaged with the original class file [OSL], and they both follow the “rules” of each license [OSL + GPL], what’s the problem?

    As written, the OSL does not allow you to distribute the package under GPL, GPL requires this, OSL requires that it’s OSL. Conflict.

  • #56 / Oct 28, 2011 8:26pm

    kenjis

    118 posts

    I guess I’m wrong since GPL’s pages seem to interpret this the same way you do when they’re comparing licenses, but it seems to me that by saying obtain the express assent of recipients that means you just have to let them know in the readme on a public vcs, or next to a download link for the app, that the release is copyrighted under the OSL. Doesn’t seem like that much of a restriction to me.

    I wonder if I run a web site, say a shopping site, by OSLed CI, I have to put the readme (or something other way) on my site to obtain the express assent of recipients. Because in OSL, use over a network is also a distribution (5. External Deployment).

     

  • #57 / Oct 28, 2011 9:40pm

    kenjis

    118 posts

    What’s my definition of the linking / creating definitive works? It seems to me that, in PHP, any library we use is dynamically linked, since it is linked at runtime for every script execution. Rosen seems to make it pretty clear that linking and unchanged original does not create a derivative:

    The definition of Derivative Works in § 1(b) is particularly important. For one thing, that defined term includes no reference whatsoever to linking or to any other technical manner of making programs interoperate. The verbs used in § 1(b) [“translate, adapt, alter, transform, modify, or arrange”] reflect the kinds of activities that we generally do to create derivative literary or other expressive works, and those things—not functional linking—create Derivative Works as defined in this license. As a result, linking an unchanged Original Work with another independently-written work does not, absent more, create a Derivative Work subject to § 1(b); such an act is merely the
    incorporation of a copy of that Original Work into a collective work, authorized by § 1(a).

    And he follows this with more discussion that says the same thing under the section on when you must disclose your source code:

    If linking (by whatever technical means) can be accomplished by making and using unmodified copies of the Original Work, then 1(a) and 1(c) permit that; only the Source Code of the Original Work must be disclosed.

    To me, this sounds like I can create a MY_Controller which extends the OSL-protected CI_Controller without it being forced into the OSL since the CI_Controller class is the unchanged Original Work.

    To me, I could interpret it like you. But

    linking an unchanged Original Work with another independently-written work does not create a Derivative Work

    I could read it as:

    linking an unchanged Original Work with another dependently-written work create a Derivative Work.

    This means if you do not change Original Work, it does not always mean your work is not Derivative Work. Is my interpretation wrong?

     

  • #58 / Oct 28, 2011 10:04pm

    kenjis

    118 posts

    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?

    This point is still unclear.

    At first, all of Reactor Engineers agree to the license change?

     

  • #59 / Oct 29, 2011 5:31am

    Mytosis

    21 posts

    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?

    This point is still unclear.

    At first, all of Reactor Engineers agree to the license change?

    Github contributors have not been asked, that’s a fact.

    I can’t prevent myself from getting the feeling that EllisLab wants to use the OSL but they don’t want to be bound to it for themselves (OSL 3.0 (6)):

    You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work.

    Where is the attribution of the contributors works?

    Attribution in copyright law, is the requirement to acknowledge or credit the author of a work which is used or appears in another work. Attribution is required by most copyright and copyleft licenses, such as the GNU Free Documentation License and Creative Commons licenses.

    Attribution is often considered the most basic of requirements made by a license, as it allows an author to accumulate a positive reputation that partially repays their work and prevents others from claiming fraudulently to have produced the work. It is widely regarded as a sign of decency and respect to acknowledge the creator by giving him/her credit for the work.

    From Wikipedia: http://en.wikipedia.org/wiki/Attribution_(copyright)

    There are no copyright assignments for CI but EllisLab claims the copyright being it’s own:

    Copyright (c) 2008 - 2011, EllisLab, Inc.

    There is an email address given, .(JavaScript must be enabled to view this email address) . Probably someone (preferable a contributor) can ask for full attribution notices for the development branch and share them here to show the full picture?

    Is termination already in effect? From what I read from the license, it is. That’s really an ambiguous situation. Derek (or whoever from EllisLab can) please clarify ASAP.

  • #60 / Oct 29, 2011 12:50pm

    Thecodingdude

    15 posts

    Really loving the input from the admins.

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

ExpressionEngine News!

#eecms, #events, #releases