Thread

lol now that’s (DBAD) a license bound to gain in popularity.

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

It might stop you from using GPL on your own apps:

1. GPL is not compatible with OSL. The Free Software Foundation says so: http://www.gnu.org/licenses/license-list.html#OSL
2. If we use GPL libraries in our apps, we must license our apps under GPL as a whole. (The Free Software Foundation (which holds the copyright of several notable GPL-licensed software products and of the license text itself) asserts that an executable which uses a dynamically linked library is indeed a derivative work. ) http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
3. Even if EllisLab does not care we use GPL in our app, 3rd party library’s author might care.

1. and 2. are mere FSF opition, but at least, CI user must consider legal issue about GPL, if they want to use GPLed libraries. It costs.

Other major PHP frameworks choses GPL compatible lisence to avoid the costs.
Choosing OSL is a disadvantage of CI in this prespecitive.

More questions.

If we extend CI libraries(or core or helpers), CI libraries are licensed under OSL, so we must license them under OSL.

So we must make public the source files (MY_*.php), even if we do not distribute public our app (we make it for one our client only), but if our client launch a web site using our app.

We must make public the source files (MY_*.php), even if we use them for our public web site.

5) External Deployment. The term “External Deployment” means the use, distribution, or communication of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Work or a Derivative Work as a distribution under section 1(c).

My understanding is right?

Next to what Kenjii highlighted, I’d like to add the OSL 1(c) text:

1 c) to distribute or communicate copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work or Derivative Works that You distribute or communicate shall be licensed under this Open Software License; [bold is underlined in the source]

Source: opensource.org/licenses/OSL-3.0

As any controller extends from CI bases classes, it’s more than highly likely that anybody coding in the intended way to use the CI Framework is always creating derivative works under the OSL.

Controller classes inside the application folder are therefore a much better example to make the impact of the OSL licensing visible in my eyes.

Put simple: It does not play much of a role if you’re looking for GPL’ed distribution or anything permissive even, the OSL is reciprocal and requires you to put derivative works under OSL as well.

And by the nature of the OSL, it’s more that it’s an AGPL-like license: Even communicating the work requires you to provide the source-code-form of the work.

Choosing such a license implies that this is by intention. I highly doubt it, but.

Houston, we have a problem.

Derek can you give us the reason behind this changes? Is it because there are several Framework out there, or any CMS, which use CodeIgniter then getting clamorous, as ElisLab competitor, so ElisLab thinking : we better apply this OSL and AFL thingy, so our EE will not lost in market competition against those who want to sell CodeIgniter (because they usually sell it cheaper than EE)? I believe you guys doesnt think like that, so please explain to us. I didnt see any notice lately, either from IRC, News section or from any other available public space, just trying check to fetch from my local repository and bam : OSL 3.0 everywhere on my screen.

Despite the fact that changing from one reciprocal (like BSD to OSL, in this case), is unlikely to contradict the implied expectations of any open source contributor, but this will still generate negative impact for those who use CodeIgniter, and heavy rely on it, for create a commercial project/company, with zillion custom function extends (and sometimes hack it litle bit). Off course they can still sell their modified/derivative works, but for legal issue(s) : we all know that everything has change now. For example, without our notice, someone can grab some packages which built for custom client, just because it modified or extending the “Original Work” (so it being of what called “derivative work”).

I’m actually agree with Phil this time, when he said :

...we should just use DBAD.

Phil thats actually a good idea. Its the fittest stuff i can imagine for this case. But…although I think DBAD license,is ethically appropriate, but in the real world, unfortunately, this license does not have clear scope and tight constraints, both to protect developers (original work), derivative works and in the end of this cycle: the client.

Is there another option about it, or is this another “republican” move? :(

I’m actually agree with Phil this time, when he said :

...we should just use DBAD.

Phil thats actually a good idea. Its the fittest stuff i can imagine for this case. But…although I think DBAD license,is ethically appropriate, but in the real world, unfortunately, this license does not have clear scope and tight constraints, both to protect developers (original work), derivative works and in the end of this cycle: the client.

Is there another option about it, or is this another “republican” move? :(

You have to be the only person who read it that actually took it seriously.

@toopay, wouldn’t it have the opposite effect in that if CI is OSL 3.0, then would it make EE fall under OSL 3.0 too?  I wouldn’t think Ellis would have that as the intention.

Mirge, despite that DBAD is more likely a poetry rather than a legal statement, but i think Phil was serious too when he wrote that(yes, i might be wrong about this). Beside the fact that the essence of that (DBAD) statement is actually relevant.

Sire, in practical terms, this upgrades is a cleaned-up expression of the rights grant implied in traditional academic licenses. It is intended to prevent the making of unauthorized copies or derivative works so that the author can profit from his own work without competition. With many of CMS based on CodeIgniter out there, which try to sell out their “modified” CI as a public products (some of them have “paid license”), off course i will suspect that ElisLab do this intentionally, its logical in market competition perspective, to protect their product which is build on top of the CI too. Thats why i hope Derek come to explain. Because under OSL, every derivatives works (which modified the original works, like extends some class for example) must be have same/public license too, and this is bad for any sofware company which build some of their php (based by CI) application for limited use (and not for selling their “modified” CI as a public products).

Because under OSL, every derivatives works (which modified the original works, like extends some class for example) must be have same/public license too, and this is bad for any sofware company which build some of their php (based by CI) application for limited use (and not for selling their “modified” CI as a public products).

I wonder how the code in the application folder could be under “Academic Free License (AFL 3.0)” as it’s part of the CodeIgniter application (the original work).

This does not conform with the terms of the OSL licensed files in the package. As OSL 1(c) has been already broken in the software package as-is (the code in the application folder is a modification of OSL’ed code and/or AFL code incorporated into an OSL’ed work), the termination of 9) must be already in effect. So the practice doing this looks contradictory, which legally might just render both licenses invalid at large fragments, see further OSL-3.0 13) and 16).

As Derek told that the AFL in the application folder files supersedes the OFL in the other files, that AFL must have the special powers here, not the OSL.

But anyway telling everybody the code in the application folder is available under AFL seems misleading to me. Even if it would be in it’s very earliest form, provided in the CI package, it can’t be alone under AFL but OSL applies as long as it makes use of CI core components or vice-versa (and does not form an independent work of software on it’s own).

Derek, can you explain in your own words what the intend of the license change actually is?

Is ExpressionEngine already making use or is it planned that it makes use of OSL’ed CI code as well?

How about the next time you guys make sweeping license changes like this you actually setup a survey form and get the community involved. Sure some of us out here are complete idiots “I speak for myself” and we wouldn’t know a license if it fell into our laps and bit us in the ass, BUT, at the very least please try to maintain good relations in the community that helped CI become the “almost” household name that it is.

You catch more flies with honey!!

There is a voice: Less restrictive license
http://codeigniter.uservoice.com/forums/40508-codeigniter-reactor/suggestions/1824139-less-restrictive-license?ref=title

I think it it better MIT or new BSD for frameworks, especially CI which is BSD-like license (not copyleft).

But it is sure, it is better EllisLab explains the intention of the license change.

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.

I’d also like to raise the point. We are a large Open Source project and have chosen CodeIgniter as a framework and ported all our code a few months ago. The reason for chosing CodeIgniter was the free license and the quality of the framework of course (great work, guys!).

I now heard that following CI versions will use OSL which is really a bad choice from our point of view. Can you please explain if this decision is already made and what were the reasons for chosing OSL instead of a GPL or Apache license?

I don’t want to blame anyone without knowing the arguments the decision was based on, but I think when switching to OSL you will loose a lot of long term users and contributors because of the incompatibility between OSL and GPL which is used at most of the bigger Open Source projects.

Are there any chances you re-think your choice?

Thanks for any hints/answers,
Marcel

I posted to uservoice:

GPL compatible non-copyleft popular licesne
http://codeigniter.uservoice.com/forums/40508-codeigniter-reactor/suggestions/2344554-gpl-compatible-non-copyleft-popular-licesne

If you agree with it, please vote to it.

I have wrote a blog article about OSL 3.0, my current understanding.

What is Open Software License (OSL)

I was a little surprised to hear of the license change, though the confusion didn’t surprise me at all. I’ve read through most of these licences before and trying to figure exactly who could and could not do what left my head spinning. So I had to go run off and read up on this one. While any tricky situation would definitely be left to the lawyers, here’s a bit from the author of the OSL himself:

” 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). “

It seems to me that is the crucial part. Even extending a core library (MY_* files) is not modifying the original work, it’s simply linking to it and including it in our own applications. To me, this means everything we do, unless it is modifying the core files, is free from the viral nature and we can do whatever we want with it.

And since the application folder’s contents are licensed AFL, that means those files can be modified and redistributed (which we all do with every app) and put under any license we need to.

It seems the biggest problem is the long-running one… communication. But the change itself just seems to be one that is more specific, in legal terms, about what can or can not be done with the software they’ve given us. Granted, I kinda like the old license that basically said do with it as you would as long as you keep the copyright notices avaialble in the source code and let people know your app was built on CodeIgniter.

Read the original doc here