Software License Wrap-Up and OSL 3.0

The content in this article is neither legal advice nor a legally binding interpretation of the licenses discussed, including those distributed with EllisLab products. We are sharing our opinions, thoughts and conclusions which we hope are helpful and spark meaningful discussion. You should consult an attorney with questions regarding your specific legal needs and the terms or interpretation of any software license.

Software License Awareness Week draws to a close today at EllisLab.  The purpose of our articles this week was to reveal our thought processes and our conclusions, and to raise awareness about the need for every developer to do due diligence to reach their own conclusions.

We know that there are many that simply want to know “why OSL 3.0?”, and we could have answered that on the first day.  However, the articles were intentionally structured and ordered to represent the general flow and conclusions that we drew during the months-long process of research for a new license for CodeIgniter.  In this way, you get to see a snapshot of this long process as perhaps a template for your own steps in researching a software license, and also to see that we have not thoughtlessly jumped on a license.

So now we can touch on the results, and answer more directly some of the questions that have been raised.

Why A New License?

CodeIgniter has always had what we viewed as a highly permissive license that also ensured that EllisLab got credit for its work.  Part Artistic License, part BSD, it allowed you to do almost anything so long as you told people what you had changed, didn’t use “CodeIgniter” as part of your product name, and you credited that your work was based on CodeIgniter.  It was, and is, a good license in our opinion.

But as a non-certified license which is used by only our product, a developer had nothing else to go on if a lawyer had some basic questions like “is it GPL compatible, BSD friendly, etc.”  And it also prompted a semi-regular stream of questions from community members in the form of “does the license allow me to do X with CodeIgniter?”  The reality in this industry is that lawyers don’t make the daily decisions about what software to use, developers do.  This makes lawyers squirm, but it is what it is.  And as simply as the CodeIgniter license was written, it prompted skepticism among users and made it difficult for developers to answer questions when asked by their employers.  Surely there were more strings attached.

We decided we had two options: we could either adopt an OSD-compliant OSI certified license, or we could submit the CodeIgniter license to the OSI board for certification.  As desirable as it was to keep the old license, simply having it certified would not satisfy the legal teams who are concerned with there being no other body where the license was in use, and users would still be skeptical if we were really giving away what we said we were.  So…

The Search Began

As highlighted by this week’s articles, our search basically took the following order, narrowing each step:

1. Pool the OSD-compliant and OSI certified licenses
2. Determine whether or not GPL compatibility was a deciding factor
3. Eliminate licenses that would restrict types of use
4. Decide what EllisLab wants in terms of sharing and protecting our intellectual property
5. Look into what would be needed to change licenses, and how the license might have a bearing on accepting contributions
6. Select a license

Most of the open source licenses do not restrict usage, so that became less of a factor, particularly when we were able to see that GPL was not for us and not a compatibility requirement either.  This meant that throughout our search, there were two prevailing details that stood at the fore, the two provisions from the original license that we hold dear:

• EllisLab would like for people to know that a work is based on CodeIgniter, and
• we want to make sure that the CodeIgniter trademark is not inadvertently licensed for use by third parties.

The MIT license is popular, though as the Free Software Foundation (FSF) points out, you should be specific as to whether you’re referring to the Expat license or the X11 license.  We like the X11 license, and in fact chose to use it for our first party free ExpressionEngine add-ons.  The two are essentially the same except the X11 reminds that the name EllisLab cannot be used in advertising or promotion of any resulting software.  However, it does not contain provisions for restricting the use of the CodeIgniter trademark, and does not require that you disclose that the work is based on CodeIgniter.  The OSI certified MIT license is the Expat version, and doesn’t even restrict the use of EllisLab’s name in advertising and promotion.  So the MIT licenses were out.

The BSD-3-Clause license is practically identical to the X11, and was ruled out for the same reason.  The Simplified BSD license is a fair match to the MIT/Expat license, and therefore also ruled out.

These were the first two licenses we looked at, and like many in our community, we’re fond of them.  However we decided that our trademark protection and right to have our work acknowledged were too important to let go of.  We could simply add those as two simple restrictions, but we’d be right back where we were with our original license: having a modified license not in use by anyone else, nor certified by the OSI as being OSD-compliant.

Open Software License v. 3.0 (OSL 3.0)

Eventually this led us to the Open Software License v. 3.0.  Before we dive in here, we request that if you haven’t already, that you take the time to stop and read both the OSL 3.0 itself, and the official FAQ written by its creator, Lawrence Rosen.  Please.

http://www.opensource.org/licenses/OSL-3.0
http://rosenlaw.com/OSL3.0-explained.htm

OSL 3.0 appealed to us because of the OSD-compliant certified licenses, it closely retained our two most important provisions from the original license.  It excludes our trademarks from being included in the license, and it makes people aware that a particular work is based on CodeIgniter.  Well, sort of.  That’s where the copyleft provision comes into play.

None of the licenses allow us to say that you “must include an acknowledgment that they are derived from CodeIgniter” as our original license states.  But a copyleft license at least ensures that anyone who receives copies or modifications of CodeIgniter will receive them under the same terms that we ourselves licensed, including attribution notices and the like.  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. 

The answers to all of your questions regarding OSL 3.0 are contained in those two documents, but the mixing of programming concepts with similar terms in copyright law, along with a heaping spoonful of FUD from the FSF may leave you with additional questions or reaching the wrong conclusions entirely.  Let’s cover the three biggest questions:

Derivative Work

The Linux Journal published an article in 2003 that sets some reasonable definitions for derivative works as follows:

1. The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work.
2. The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.
3. Derivative works are not going to encompass plugins and device drivers that are designed to be linked from off-the-shelf, unmodified, programs. If a GPL-covered program is designed to accept separately designed plugin programs, you don’t create a derivative work by merely running such a plugin under it, even if you have to look at the source code to learn how.
4. In most cases we shouldn’t care how the linkage between separate programs was technically done, unless that fact helps determine whether the creators of the programs designed them with some apparent common understanding of what a derivative work would look like. We should consider subtle market-based factors as indicators of intent, such as whether the resulting program is being sold as an “enhanced” version of the original, or whether the original was designed and advertised to be improvable “like a library”.

Points number 2 and 3 are particularly salient in the context of a programming framework like CodeIgniter, which is little more than a collection of libraries and functions with a hint of context, enabling you to create web applications without ever looking at the source code.  But do these definitions carry through in the legal terms of the software license?  Well, that article was written by Lawrence Rosen, the author of OSL 3.0, so undoubtedly that informed how he decided to frame the definition of derivative works.

As explained by Rosen, the verbs used to define a derivative work in OSL 3.0 (which it does more clearly than any license we could find) reflect the “kinds of activities that we generally do to create derivative literary or other expressive works.”  Functional linking has nothing to do with it.  Whether or not a copyrighted work of PHP code could operate with or without an OSL 3.0 piece of software has nothing to do with it.  “...linking an unchanged Original Work with another independently-written work does not, absent more, create a Derivative Work…such an act is merely the incorporation of a copy of that Original Work into a collective work” (emphasis ours).

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.

As a comparable example, Magento Commerce community edition is distributed with OSL 3.0.  The code that you use to build the application though is not.  To quote Rosen from the Magento forums:

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

CodeIgniter is similar.  None of the files in the application folder are licensed as OSL 3.0, so there is no derivative work created by the addition of your own controllers, libraries, helpers, views, etc.  Only if you make changes to the CodeIgniter core system files that are OSL 3.0 licensed—and if you distribute those changes—must you license that code under OSL 3.0 and make its source available.  And those files are easily identified because a clear attribution notice is included at the top of every file.

When then does the reciprocal licensing and source code disclosure kick in?

Distributions

Physically delivering copies of software to third parties is obviously a distribution

There’s an old adage that if something is obvious you don’t have to say that it’s obvious, and that’s the case here.  If you are letting people download your derivative works, sharing it on GitHub, etc. you are distributing, and these modifications must be licensed as OSL 3.0 and the source code disclosed.

Enter the Application Service Provider (ASP) Loophole

One problem of open source licenses that treat distributions only in the traditional physical sense is that very large organizations with a lot of engineering muscle (read: Google, Microsoft, Apple) can benefit greatly from the software without ever giving back.  They can take that free software, modify it significantly, perhaps with amazing improvements given their resources, deploy it as a service on their network, and never have to share those improvements with anyone else.

With CodeIgniter, we’re not talking about building web sites, we’re talking again about derivative works - modifications to the OSL 3.0 licensed files in the framework.  We think that plugging that ASP loophole is in the best interests of every CodeIgniter user as it ensures that the copyleft provision is triggered even if the derivative is deployed only as a web service.

Interestingly, the FSF feels the same way, that software which is commonly run over a network should be licensed in a way that accounts for such usage.  Their solution is the AGPLv3, since the GPLv3 does not plug this loophole.

Reciprocal Obligations

So let’s say that you have modified and are distributing CodeIgniter per the definitions above.  What’s your obligation?  As a reciprocal license, such affected files must be licensed as OSL 3.0.  That makes you the Licensor, distributing to Licensees.  As an obligation that we share since we are also a Licensor of OSL 3.0 licensed source code, §3 states:

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.

Reasonably calculated to be inexpensive and convenient (to the licensee), for as long as you are distributing CodeIgniter.

We love GitHub.  It has been a great boon for CodeIgniter’s development, and the features make it a joy to work with.  It happens to also be free for anyone to access a read-only copy of source code who has an internet connection, even if it’s only their mobile phone.  You’d be hard pressed to find a less expensive and more convenient way for licensees to access your source code, though it’s certainly not the only option.  Also you can fork our repository for free, even if you have no intention of creating a derivative work.

See how reasonable that is?  As a contrast, here are some things that OSL 3.0 does not place as obligations on Licensors:

• Placing a prominent download link to your independently written code or even CodeIgniter on a web site you build with CodeIgniter.
• Demanding the location or method that you use to disclose the source code.
• Making your users and site visitors click anything to acknowledge that they’re using an application written on CodeIgniter.
• Disclosing and licensing any of your independently written code with OSL 3.0 because it only functions with some derivative work you have made in CodeIgniter by copying and modifying OSL 3.0 licensed code from a default library in a new library that you’ve created and reciprocally licensed with OSL 3.0.
• Distributing CodeIgniter at all with a software package that is comprised solely of your independently written code (your application folder) and its contents even though it requires CodeIgniter to function.

Think about that last one for a minute.  We happen to know a place that anyone in the world can download CodeIgniter for free, even downloading a specific revision.  We’re not making any specific recommendations here, but it demonstrates how important it is to do deep research on these topics.  It would seem that the GPLv3 only requires packaged and distributed works to be encompassed and compatible with the GPLv3.  Since that license does not consider transmission over a network as a deployment, that usage is still private, and no copyleft or copy-forward action is triggered.  And as stated before, OSL 3.0 has no quarrel with GPL.

Hopefully we’ve answered your questions as thoroughly as possible and demonstrated how we arrived at our conclusions.  We chose OSL 3.0 because it allows you to do all of the wonderful things you’ve ever been able to do with CodeIgniter, it protects our trademarks, it ensures that CodeIgniter and its improvements will always be free, that downstream licensees will get CodeIgniter under the same terms we gave them, and it provides CodeIgniter with an OSD-compliant OSI certified license that developers can point to to satisfy their employer’s and their attorney’s questions.

We’ve created a very brief summary of how future versions of CodeIgniter are impacted in this CodeIgniter License FAQ.

We can tell from our analytics that people are spending a lot of time on reading these articles, which we greatly appreciate.  Armed with additional knowledge, and understanding the importance of researching these topics whatever your personal conclusions, we are confident that we have contributed towards helping you succeed on the web, which has been and always will be our primary goal.

Thanks to all for reading and joining the conversation during EllisLab’s Software License Awareness Week!

References and Further Reading

https://github.com/EllisLab/
http://www.opensource.org/licenses/alphabetical
https://ellislab.com/codeigniter/user-guide/license.html
http://www.opensource.org/licenses/OSL-3.0
http://rosenlaw.com/OSL3.0-explained.htm
http://www.linuxjournal.com/article/6366
http://www.magentocommerce.com/boards/viewthread/13938/P15/
http://www.sitepoint.com/podcast-29-roy-rubin-magento/
http://www.itbusinessedge.com/cm/community/features/articles/blog/rosen-says-his-open-software-license-solves-gpl-v3s-problems/?cs=17204
http://www.gnu.org/licenses/agpl.html