Thread

I was and still, not aggree and somehow feel that OSL is really EllisLab’s “legal team” movement, instead Derek, Phil or anyone as a person. And i think, time will show the result, whether this plan works or not. And as far as i understand those OSL statement, it actually true that this license is a good one, for an open source project, like CI. 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, or like this statement

It’s the closest provision we can find to requiring a small tip of the hat to EllisLab for creating and sharing CodeIgniter with the world, and ensuring that what we distribute for free continues to improve and remains free.

That absolutely EllisLab right, even if they do it like a republicans, it still their right. Being open-source, is a good thing, although this license is way too much.

But, as developer, choosing a framework, by only based on its license, is ridiculous. Plain silly.

Recently my company choose CI (this before the OSL things came up) for a project. License was an issue(s), both investor and developer(s) is hesitate. We’re not considering something like “they have great community”, “they have great doc” things here, even thats are valuable points to choose CI overall. Investor want a stable PHP framework, which widely used (industry standard), so they will not have any difficulties when there are some substitutions in developer team. Developers, want something that can make job done faster, so they can enjoy their weekend, reading a good novel in midnight and other “human” activities. This is a common case, and some of best choice among PHP frameworks out there, is CI.

And as long as EllisLab hold their words :

While OSL 3.0 is a copyleft license with a reciprocal licensing requirement, it is not a viral “copy-forward” license, so using OSL 3.0 software as part of a collective work does not affect the licensing requirements for any of the other parts of the collective work.  Short version: your code really is your code, and you can license it however you like.

I dont see any reason not to use it in any commercial project.

The biggest issue I have with OSL is still that if I make any change to the core files or any files licensed OSL, on my own website, I am obligated to provide these changes to every visitor of my site.  The author of the OSL has confirmed this, regardless of EllisLab’s interpretation of how they will enforce OSL with CI.

Of course, there’s no way to know if I don’t tell you, for my own site, but I’m still violating the license if I do so and my rights to use CI is terminated.

As a result, I’ve been looking into alternatives to CI.  I will continue to use 2.x versions, but when 3.x is released I’ll be using something else.

As a result, I’ve been looking into alternatives to CI.  I will continue to use 2.x versions, but when 3.x is released I’ll be using something else.

We switched to “Yii” framework. The architecture doesn’t differ much, it is very lighweight and covers all our needs: http://www.yiiframework.com/

The biggest issue I have with OSL is still that if I make any change to the core files or any files licensed OSL, on my own website, I am obligated to provide these changes to every visitor of my site.  The author of the OSL has confirmed this, regardless of EllisLab’s interpretation of how they will enforce OSL with CI.

Please show me where in OSL it says that you have to provide the source of your modified OSL licensed files to every visitor of your site.  This is patently false.

Also:

regardless of EllisLab’s interpretation of how they will enforce OSL with CI

To the contrary, this is all that does matter.  Nobody has copyright to CodeIgniter but EllisLab.  The software license is not a contract between you and the OSI or the FSF, it is a unilateral conditional contract between EllisLab and you, that you gain all of the provisions of automatically as long as you follow the conditions and terms.  The understanding between the licensor and the licensee of what the contract obligates absolutely is material under court of law.  And our thoughts I think are fairly clearly published here.

We switched to “Yii” framework. The architecture doesn’t differ much, it is very lighweight and covers all our needs

I dnot believe this.

Even if EllisLab was not decide to change the license, do you bordering yourself to not using other framework(s) as well? A framework is right tool for a task at a hand, it absolutely fine, to use other framework for other task.

From Larry Rosen:

“Only if you make changes to the Core folder—and if you distribute those changes—must you license that code under OSL 3.0 and make its source available.

Under OSL 3.0, “distribution” includes “External Deployment”. If you distribute copies of your changed Core folder, or if you provide access to that software by placing your Magento store on the web for other people to buy things, that’s a distribution under OSL 3.0. So be careful to make your private changes to the Local or Community folders, not the Core folder, if you don’t want to disclose them.

http://www.magentocommerce.com/boards/viewthread/13938/P15/#t61566

Sire: This quite clearly says that if you modify CodeIgniter’s system/ folder then you need to distribute that system folder with licenses intact.

ALL the OSL means for us is “Don’t hack CodeIgniter and distribute the hack”.

If you are tracking all of your CodeIgniter modifications with Git (using GitHub’s fork option) like any sane core-modifying person should be doing then you have met the requirements of this license entirely!

That forum post in no way shape or form says that you have to distribute your websites source code to everyone who looks at it. I don’t want to be offensive but to put it plainly: that is absolutely ridiculous!

@Sire: Yes, external deployment as is the case of a web site is considered a distribution in OSL.  That triggers the copyleft provision, and successfully plugs the ASP loophole that would allow large organizations to make meaningful improvements to the software without requiring them to share their work.

So the question is: Once the copyleft is triggered, what does OSL require of you, and how would that impact your web site’s visitors?  In my above link, refer to the “Reciprocal Obligations” section for details, but the basic term in the license is that since you are now distributing the software, you become an OSL Licensor, and must share your OSL code thusly:

Licensor reserves the right to satisfy this obligation by placing a machine-readable copy of the Source Code in an information repository reasonably calculated to permit inexpensive and convenient access by You for as long as Licensor continues to distribute the Original Work.

Nothing more, nothing less.  And as Phil points out, this would only apply to OSL licensed files - not your own independently written works, unless you also choose to license them as OSL.

How is what you are saying any different from what I said here:

The biggest issue I have with OSL is still that if I make any change to the core files or any files licensed OSL, on my own website, I am obligated to provide these changes to every visitor of my site.

Let me add:  this is ridiculous.

I decide to use CI to make a site of my own.  I modify any of the system/ files and now I have to make sure my changes are available to everyone who visits my site.  Like I said, I’d rather just go with another framework and avoid the hassle.  Not because I don’t want to share my code, but I prefer the freedom not to be obligated.  Maybe some of my changes are for my own security purposes, unique to my site.

I’d just use Fuel, or Kohana, or Yii instead and not bother with an OSL framework.

Sire, maybe you should describe to me what you think that means you have to do - the actual mechanics of it.  Lay out a scenario for me, please?  It could be that we have a different idea of what is burdensome or not, though it seems to be more than that; it sounds like you think that your obligation will have some meaningful impact on your visitors?

Anyone using Fuel or Kohana is already sharing their modifications.

Every user who is modifying things has a fork on GitHub…

@derek, you know how with Apache and Nginx for example, you can turn server tokens off?  The purpose is to help avoid security issues that might plague you when an exploit or vulnerability is found in specific versions.  Obviously this is important enough to be a feature in nginx and apache.  It’s also available in open source software, and even in commercial software where you can pay a small license fee to remove what powers your site, and specifically what versions.  I usually opt to do this for security reasons.  If my site is using OSL and powered by CI, I’m obligated to reveal the version, code, and any modifications I may have made to it myself.

@Phil, isn’t that kind of what you were objecting to with Mytosis?  You’re saying Anyone and Every User.  I think not.  If I use Fuel or Kohana to power my site, I may or may not have it publicly available on Github.  Odds are, I would not.  I highly doubt everyone is sharing their modifications.

Anyway, who cares?  I just won’t be using 3.x is all.

Sire: Ok, not “every user” but you’ll have a hard time finding a quality developer who doesn’t. I can certainly say that in all my time in the Fuel IRC and in every conversation I have ever had with a Fuel developer (or any other developer I have met) nobody has ever condoned hacking core files. That might not be every, but it’s everyone I know… except you.

If you are modifying the core of a framework, library, CMS, anything you should be tracking it with version management. That is not just me making assumptions, that is just logic. Hacking files means upgrading wipes out changes, which you should never do. If you are making changes to CodeIgniter why would you not make them with version management?

In the past you might not have bothered because CodeIgniter was using Hg or SVN and you couldn’t, but now it has Git of course you should be doing this.

You’ve modified CodeIgniter for your application right?

This falls into two categories:

1. You’ve added new features.
2. You’ve fixed some bugs.

Well if you’ve fixed some bugs then you should be putting them on GitHub for the rest of the community.

If you’ve added a new feature to CodeIgniter itself that cannot be achieved with a MY_Foo library then somebody else is almost definitely in the same position and would like that change. All you have to do is put it on your fork.

What are the other benefits of doing this?

When I work with any library I make a fork. Then if me or my company needs a feature I just make it and send a pull request. I dont give a damn if they end up merging it or not because I have my work with my feature. Lovely.

My fork however cannot be randomly relicensed, I do not own it, I cannot distribute it for cash unless the license allows me to. OSL asks that you keep the CodeIgniter license in place, keep it licensed under OSL and keep it public. That is all you are being asked to do.

In Short: When you make modifications to CodeIgniter do it publicly, because all forms of logic dictate you should be doing that anyway.

@phil, I don’t disagree and it’s not a big deal for you of course as you’re a much better developer than I am.  Sometimes, I need to hack at something a bit.  Maybe to add some obscurity or maybe a restriction that I want in a core file so it applies across the board for me.  I’ll learn to code smarter, and I’ll get better at it eventually, and then it won’t be an issue for me either.  If it was just a bug fix or a new feature, I don’t have much trouble sharing that unless it gives me a temporary advantage against a competitor where it matters.  OSL doesn’t give me that freedom, so CI 3.x won’t either.  Fuel does.  Kohana does.  Yii does.

@Sire - security by obscurity is not security.  The reality of the impact that you describe is no different from the previous license’s requirement that you note that your project was derived from CodeIgniter.  A malicious user would simply try all known attack vectors across any known weak version.  Such features as you describe are demanded typically by behemoth IT departments of enterprise firms, and are more about providing lists and reports to board members that have checkboxes to show compliance rather than real security measures.  That logic would mean that someone should safely be able to run XSS and SQL injection vector ridden software - so long as you aren’t advertising that you are.

Honestly this particular complaint, that users must share changes they make to CodeIgniter core files, I find a bit disconcerting.  Isn’t one of the entire purposes of open source software that the community feeds back into itself and everyone benefits?  Particularly if you are making a modification for increased security to software that you received for free - don’t you want other users to be able to benefit from your change?  Doesn’t that benefit you in both the short and long term?

As for hacks vs. proper coding, the community here is rich with experience.  Both here and at GitHub, I am willing to bet that you can find help in converting hacks to more maintainable code, if that is your objective.  If you ultimately stick with your decision to not use CodeIgniter, I certainly hope that you take efforts with whatever framework you choose to use their respective communities to assist you in developing those sound habits.