I’m proud of what we’ve accomplished in the past ten years but to a large extent its meaningless. That’s not how our industry and our Community works. What follows is not a list of amazing accomplishments and back slaps. It doesn’t matter what we did last year or the year before. What matters is what we’re doing right now and where we’re going next. I am proud of what we did last year (more growth, expansion, hiring, building, shipping). But I am not satisfied, not even close.

I have a very clear picture of where I want EllisLab to be and we’re getting there, but we’re not there yet. I want to go faster. A few days ago Greg Storey wrote:

Lets conquer 2012 together and make it a point in time when we can all look back and agree that’s when it all really began.

That tone resonates deep inside my soul.

I’ve initiated Phase Two of my plan for EllisLab, “Irrevocable Change.” As a team we’ve committed ourselves to the sort of change from which there is no going back. It puts front and center that what we’ve done won’t take us where we want to go. Every single person at EllisLab is working on building and creating better products and services to make your lives and the lives of your clients better.

Here’s what we’re doing for you right now and what’s next.

ExpressionEngine 2.4 will ship this month, most likely early next week (the team is doing its final checks today). This is the first release with EE Reactor contributions and we’re very excited to get it out to you.

ExpressionEngine 2.5 will ship 6-8 weeks after EE 2.4 ships. Yes, that’s two major releases fairly close together. We decided to take this approach because EE 2.5 will ship with a default Editor. We just code reviewed the Editor last week but haven’t had the chance to give it full testing or review. We don’t want to delay EE 2.4 but neither do we want you to have to wait any longer than necessary for the Editor. The solution is to give you EE 2.5 sooner rather than waiting out ExpressionEngine’s full twelve week release cycle.

In February EllisLab is sending Pascal Kriete to CodeIgniter Conference in London. We’ve always wanted to have an official presence at a CI event over the pond and we’re happy we can finally make that happen this year. If you’re going to be there, make Pascal buy you a drink and then talk his ear off about what you want in CodeIgniter. CI is Pascal’s passion and he leads CI development at EllisLab. Between Pascal, Phil Sturgeon, and the impressive CI Community, you’ll have plenty of opportunity to influence what’s next for CI.

MojoMotor 1.2 will be released in February. Brandon Jones worked extra hard over the holidays to get it ready and is working with the team to prep the release. If you want a preview of it (along with EE’s forth coming Editor) sign up for the newsletter if you haven’t already.

There’s a whole lot more in the works, but I think this covers enough ground to get the year started. Here’s to 2012! It’s going to be an epic adventure.

Also, keep in mind that CodeIgniter’s OSL 3.0 license does not apply to your own code (the application folder) unless you have chosen to license that as OSL 3.0 as well.

The content in this article is neither legal advice nor a legally binding interpretation of OSL 3.0. We are sharing our opinions, thoughts and conclusions which we hope are helpful to you. You should consult an attorney with questions regarding your specific legal needs and the terms or interpretation of any software license.

Web Sites and Services for Myself

My name is Webb Tinkerer, and I use CodeIgniter to build web sites and services mostly for myself.  I use it for my personal site, for instance.  I have built sites for my friends and some coworkers, but I’ve not yet billed anyone as a client, as I’m still learning and have a full-time job that’s unrelated to the web.

My use of CodeIgniter is an unmodified stock installation, in fact I update it nearly daily from GitHub’s develop branch.  My application folder is a hodge-podge of my own code, and all kinds of libraries and classes I’ve found around the web.  Some are MIT licensed, some are BSD, there are a couple LGPL, and I even have one commercial script with a proprietary license.  I don’t share my application folder with anyone.

How did I decide to reasonably make the source code of the OSL 3.0 licensed CodeIgniter files on my site available for those who want it?  I have a Powered by CodeIgniter link in my footer that points to the official GitHub repo.  CodeIgniter rocks!

Self-Employed, Powering Sites and Services for Small to Medium-sized Businesses

My name is S. E. Owens, and I am a self-employed web developer.  Most of my clients are small to medium-sized business either looking to improve their web presence, or to execute their idea for the next great tool or service on the web.  Some of them even come to me because they’ve chosen CodeIgniter already so they can ensure that it’s easy to find a skilled developer down the road, and they found me via the CodeIgniter community.

Most of the time I use CodeIgniter off-the-shelf, but every once in awhile I apply a simple hack here or there to change the system to how I prefer things to work.  For instance, there’s this hack that I make to the Session library every single time, and rather than maintain a MY_ class, I have a fork on GitHub that includes my improvements, so that when I make changes to it, it’s super easy to deploy to all of my clients.

How did I decide to reasonably make the source code of the OSL 3.0 licensed CodeIgniter files that I’m distributing available for those who want it?  Well, as I mentioned, I forked CodeIgniter at GitHub, and my fork is public.  My hack to system/library/Session.php keeps EllisLab’s Attribution Notice, but also includes mine:

Modifications to this file by S. E. Owens are Licensed under the Open Software License 3.0 and Copyright (c) 2012, S. E. Owens.  Questions regarding the modifications or the license should be directed to s.e.owens@example.com

And though OSL 3.0 doesn’t burden me with doing so, on my online portfolio, I highlight that I am an top-notch CodeIgniter developer and link to the technologies that my client sites were built with, including CodeIgniter.  I have a lot of PHP projects and CodeIgniter related work at GitHub that I also link to from my web site, including my fork mentioned previously with my Session improvements.

Agency Building Sites for Medium to Large Businesses

My name is Joey Bloggs and I’m the CEO of Fake Foo Creative.  We build sites for many large organizations: Fortune 500 companies, universities, government agencies, and non-profits.  We use a variety of technologies in our work, and typically our clients do not allow us to disclose the technologies nor the source code used to build their sites.

A few projects are for distributable open source applications, so we just licensed the whole shebang as OSL 3.0 and the source code is available from those products’ web sites.  However our client work is largely unshareable, so when we use CodeIgniter, we are careful to make the changes only within the application folder, either with new libraries or by extending CodeIgniter’s classes. This way, we are sure that all of the code that relates to our clients is under whatever license we or they desire, even if we are modifying or extending CodeIgniter significantly.

How did we decide to reasonably make the source code of the OSL 3.0 licensed CodeIgniter files that we’re distributing available for those who want it?  On our company web site, we link to our official presence on GitHub, and one of our repositories is an unmodified fork of the official CodeIgniter repository.  We have separate repositories for our open source OSL 3.0 licensed CodeIgniter applications since those are not linked dynamically to the official CodeIgniter repository.

Conclusion

These scenarios were hypothetical examples that encompass nearly all of the reported use cases of CodeIgniter.  Hopefully you were able to identify yourself somewhere along the way and if you were previously unsure what CodeIgniter’s upcoming use of OSL 3.0 means for you, we hope you’ve gained some clarity.  These examples do not limit your options either.  Remember that the license’s wording is as follows (emphasis ours):

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.

We used GitHub in the examples not because that’s required - OSL 3.0 doesn’t allow us to demand that specific methods are used - but because for most, it will be the most obvious and the simplest.  You could:

• host downloads on your own sites
• use other public source code repositories (BitBucket, Sourceforge, Google Code, etc.)
• mail physical copies to people who call you asking for it
• ...

The interpretation is broad because what OSL 3.0 (and EllisLab) asks is essentially to use good judgment.  If you are using CodeIgniter, acknowledge and share the original or modified work in some way under the same terms you received it in a location and method that is reasonably determined to be inexpensive and convenient.

We hit the ground running and planned a conference for April 9th, 2010. We attended Future of Web Design back in November. That left five months to plan, organize, and do something none of us had ever dreamed of doing. Somehow, we got David DeSandro to speak. Somehow, we got Dan to come down from Pennsylvania to be the keynote. Somehow, we pulled this off. That’s not to say it was without flaws. It was full of issues. But, I get to say I organized a conference at age 15. The event was successful enough that we went back and did it again the next year. And the next year. Which brings us to Friday, January 6th, 2012.

The third annual Student Web Conference. Now a senior in high school, I had one more shot at doing this. No doubt doing this the past two years taught me a lot. I was ready to go out with a bang. There was a major difference between this year’s conference and those of the past; Zac Gordon was no longer my teacher. With that being the case, I hadn’t even envisioned a conference happening this year. I thought it had run its course. Well, apparently, I was wrong. I found a faculty member to be my liaison between the administration and myself, and we were going to make this event happen. At this point it’s October, and we had established the conference to be January 6th. This left three months to organize everything, by myself.

I started thinking about speakers. Having networked with enough people in the area at various events, I had an idea of who I wanted. ExpressionEngine community member Trevor Davis was cool enough to be a speaker. Brian Talbot, User Experience designer at ThinkGeek also came. Yeah, I said someone from ThinkGeek came and spoke. Dan Philibin came again and reflected on what he’s done over the past few years. And for the keynote, the amazingly talented Martin Ringlein agreed to speak. The fact that the people I wanted to speak, agreed to do it, really pumped me up. Also the fact that David DeSandro, Russell Heimlich, and John Croston came just to come, made it worth my while.

The audience was going to be a group of high school students who were interested in computer programming and art. Though a select few knew about the web, the majority were mainly there out of curiosity. For the talks, I wanted to cover as much of the industry as possible. I wanted to hit on design, code, and business. And that’s exactly what we accomplished with the variety of speakers we had coming.

This event being a web conference, I wanted to make it relevant, fun, and interesting. EllisLab was kind enough to donate an ExpressionEngine license for me to give away. So, to enter into the drawing for the license, one would have to tweet something they learned during the event and tag it with a hashtag. This kept them engaged in the event all day, and was a great way to get them involved.

So, the day of the event came. By this point, I was fueled only by caffeine the past 72 hours. Everyone filed in, the speakers presented, everything was perfect. Having done this the past three years, this was the smoothest it had ever gone. Technical difficulties were minimal to non-existent. The speakers connected with the audience. The audience was attentive. I couldn’t have asked for it to have happened any better. I genuinely feel that the students learned something, or at least, a curiosity was sparked about what we all do everyday.

We had five speakers in total. Five people certainly can’t represent an entire industry, which is where my next crazy idea came from. As a finale to the event, I wanted to show a broader, more diverse, concept of the web industry. So, I turned to all the professionals I knew, and asked for a simple clip in Photo Booth having them say why they love this industry. The final result was amazing, and I think the students really benefited from seeing this.

What a way to end the event right? The entire day was surreal, and goes down as a success in my book. I really enjoyed hosting this the past three years, and honestly, planning it, though stressful, was a lot of fun. Perhaps one day I’ll try this type of thing again, but on a larger scale. We all love what we do, and there is no other industry who is as passionate as we are. If the students walked away with anything that day, that was it.

For those interested in reading a more in-depth view of this event, I wrote up a reflection on my blog.

Take the survey.

Update (11:40am Pacific): as we quickly discovered, I forgot to check a box on the multiple choice drop-down form questions that have “Other” that includes “Other” as a drop-down option.  Unfortunately, I cannot edit the survey since it’s already collected responses.  Go ahead and select an item from the list in addition to your answer for “Other”, and we will remove the selected item from the results.  Sorry for the inconvenience!

The A List Apart Web Design Survey is one of the most important tools we have for doing the above. It helps us all measure how we’ve grown as a Community.

Please take a few minutes and take the ALA Web Design Survey.

To get an idea of how important this information is, take a look at the ALA 2010 Web Design Survey results.

We’re the part of EllisLab with whom our users most often engage, so we set the bar for their experience with us. We understand that it’s often the small details in a person’s experience that matter the most. And we’re looking to add another full-time Customer Advocate to our team.

You will be interacting with the best of web professionals on a daily basis, helping them troubleshoot and solve issues related to building, developing, and maintaining websites using ExpressionEngine and MojoMotor. Though experience with our software isn’t required, you do need to be familiar with basic concepts behind CMS software and understand how websites are built.

We need someone with the following traits:

• Focused on an excellent customer experience for each customer.
• Learns quickly and is generally self-sufficient in finding resources and understanding difficult concepts.
• Experience in stressful customer service and technical support environments.
• Skilled in communicating clearly through written mediums, especially concerning technical concepts.
• Experience with HTML, CSS, and other web technologies used in web design.

Experience with ExpressionEngine and MojoMotor are preferred.

Perks: Work from your favorite Internet connection, medical stipend/benefits, computer/software allowance, and absolutely no being micro-managed by cubicle super-villians.

If that sounds like your kind of gig, and you want to join a team that’s changing the world every day, get in touch with us. Just send an email to jobs@ellislab.com with your resume and several URLs to your recent sites, with preference to sites powered by ExpressionEngine and MojoMotor.

This is an entry-level position, and salary is dependent on experience. Individuals who can legally work in the United States (citizen, work visa) are welcome to apply. Third-party contractors, agencies, recruiters, etc. will not receive a response.

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
http://codeigniter.com/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

The conference was fantastic! Robert and his wife Loise did an amazing job hosting the event. It was fun, educational, and overall, just nice to take a break from the day job.

For those who attended, we really had fun meeting and hanging out with all of you!

Dev Day

Talk about hard core geeking out! A room full of nerds, coding to their heart’s content, learning from each other. The best part about this community is how willing everyone is to share their knowledge with you.

The turnout was great and we think people really learned new techniques in ExpressionEngine!

The task of the day was to build a web site for a fictitious band. Everyone was separated into groups, and each group had to come up with a working site at the end of the day.

People took their work very seriously, to the point where they made a real site for it. Check out Team 14’s site.

All in all, everyone had a blast building their site, and it was a great opportunity to chat and meet new people.

The Conference

The amount of people that showed up was outstanding! The place was packed!

The topics presented were timely and informative. From how to be successfully self-employed to making your sites more efficient, EECI was the place to get educated.

Did you not have a chance to get in on all the action? Would you like to see the slides from the speakers? Well, then this is the list for you:

Speakers and Slides

• Leslie Camacho – Opening Keynote
  Learn about how EllisLab has empowered all of you to change the world. Read up on our plan for the next few releases of ExpressionEngine and more.
• Paul Burton – Don’t Call Me A Freelancer
  “Freelance is not a business”. Learn what it takes to be successfully self-employed, and how to get the respect you deserve.
• David Dexter – Powerful E-commerce with BrilliantRetail and ExpressionEngine
  Have an upcoming e-commerce site? Check out the features BrilliantRetail has to offer.
• Lowell Kitchen – How to Install, Manage, and Host over 250 Expression Engine installations
  Learn Blue State Digital’s method for managing and updating over 250, yes 250 EE sites.
• Lodewijk Schutte – Parse Order Pro
  Why isn’t my page rendering correctly? Because the parse order matters you say? Low gives the lowdown on the EE parse order.
• Aaron Gustafson – Progressive EEnhancement
  Progressive enhancement is something we all need to think about. Check out Aaron’s talk on how we should be progressively enhancing our sites.
• Travis Schmeisser – The Business of Add-ons
  ExpressionEngine enables developers to make a living off selling add-ons. Travis goes over the basics of being successful in selling your add-ons.
• Matt Weinberg – 10 Ways to Rock ExpressionEngine
  A top 10 list from an EE expert. Definitely worth checking out.
• Erik Reagan – Debugging Site Problems (Workshop), Environments & Version Control: The Why & How
  Erik did a workshop at Dev Day on how to debug site issues. For his talk, he talks version control, and how you can git it on.
• Jacob Russell – EE, Faster
  Want to make ExpressionEngine run like a beast? Check out Jacob’s tips for being the most productive with your system.
• Brian Warren – Happy Clients
  Brian goes over steps you can take while setting up your ExpressionEngine site to make it easier for your clients to use.
• Fred Boyle – EE + Mobile
  Fred goes over how to create a great mobile experience for your ExpressionEngine site.
• Mark Huot – Add-on Development
  Ever want to build your own add-on? Mark walks through each type of add-on, and walks through the process of building an add-on.
• Rob Sanchez – The Beast Within
  Ready to dive head first into the core of EE? Well, Rob will help you get started.
• Ruthie BenDor – No Guessing: Prototyping Interaction For EE
  Ruthie goes over why you should start working directly in EE from the beginning. (Slides currently unavailable)
• Greg Aker – His Slides
  When things go wrong, handle it like a professional. Greg had an open mic discussion on how to handle different situations.

Wow! That is one list full of awesome!

EllisLab

Most of EllisLab was present at EECI. (Which was super cool!) We hope you came up and said hi. (I heard James personally thanked and shook people’s hands as they were leaving the conference. How sweet is that!?)

We had the amazing Nate Croft take pictures for us which you can check out here.

Aside from the EL team having the times of their lives, what news did they share about us as a company?

Check out our fearless leader’s keynote presentation:

EECI was a huge success. We all had a blast. We look forward to seeing all of you again next year! We’re truly thankful for the wonderful community we’re apart of.

Over the next few weeks, we’ll be posting some more specific information from the keynote, such as end of life for EE 1, EE Reactor, and more. If you haven’t read it already, you should check out our post on CodeIgniter’s new license.

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.

This article will discuss Contributor License Agreements, their relationship to ExpressionEngine Reactor and CodeIgniter, as well as make a proposal to the CodeIgniter community for contributions moving forward.

CLAs and Their Use

A Contributor License Agreement (CLA) is a mechanism that defines the terms under which a work is contributed to another company or project. They are most often used for open source software, but they can be used for commercial software as well. The purpose is to allow contributions to be made with no strings attached - or clearly defined strings, as the case may be.

OSS Watch strongly recommends the use of a CLA when accepting third party contributions, in order to ensure that the organizer of the project has the necessary rights to redistribute, modify, relicense, defend, etc. the resulting work. While they are typically light-weight agreements compared to other contractual agreements, they can still be a hassle.

This need becomes immediately clear when you consider situations like our ExpressionEngine Reactor program, where commercial entities would like to freely contribute to the project of another commercial entity. For example, Barrett Newton’s contributions to ExpressionEngine will certainly directly benefit Barrett Newton, but for EllisLab to ensure that they retain the rights to redistribute, sell, alter, and defend that code, it is wise to have a legally binding agreement stating what Barrett Newton is and isn’t relinquishing.

Open source software projects often view this a little differently, particularly on GitHub, where it could be easily argued that a pull request to a project with an existing copyright is an implicit grant of rights to that project. Also, bug fixes and corrections are rarely able to even be copyrighted works by law because they are too insubstantial. These types of contributions are by far the most common to occur outside of the core project team.

The table below shows some popular projects and the type of CLA they use:

* http://symfony.com/doc/2.0/contributing/index.html
† http://cakefoundation.org/files/cla.pdf
‡ http://framework.zend.com/cla
§ http://www.apache.org/licenses/icla.pdf

The details of each CLA differ slightly, but the gist is that copyright and patents are granted freely and in perpetuity to the organization. Some projects like Joomla even have a different agreement for minors. Symfony2 doesn’t employ one at all, which is not an uncommon decision, as browsing GitHub can easily show.

Alternative to a CLA

There is an interesting alternative to a CLA that is employed by perhaps the largest open source project on the planet in terms of contributors: the Linux kernel. Supposedly, somewhere near 4000 developers have contributed to the Linux kernel, so it’s easy to see how collecting and maintaining CLAs would be unwieldy. So what Linus Torvalds implemented instead is a Developer Certificate of Origin (COO).

Developer’s Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
  have the right to submit it under the open source license
  indicated in the file; or

(b) The contribution is based upon previous work that, to the best
  of my knowledge, is covered under an appropriate open source
  license and I have the right under that license to submit that
  work with modifications, whether created in whole or in part
  by me, under the same open source license (unless I am
  permitted to submit under a different license), as indicated
  in the file; or

(c) The contribution was provided directly to me by some other
  person who certified (a), (b) or (c) and I have not modified
  it.

(d) I understand and agree that this project and the contribution
  are public and that a record of the contribution (including all
  personal information I submit with it, including my sign-off) is
  maintained indefinitely and may be redistributed consistent with
  this project or the open source license(s) involved.

A COO basically states that the author of the patch has the rights to submit the code under the copyright and license associated with the file and project. Rather than requiring each of the thousands of developers to sign and submit a CLA, they sign their patch in their commit message with their name and email address:

Signed-off-by: Random J Developer <random@developer.example.org>

Git even introduced this as an automatic feature with the —signoff (or just simply -s) flag of the commit command.

The sign-off indicates that they confirm that their contribution conforms to the COO. Simple, and has been effective for the Linux kernel community for the past seven years.

Proposal for CodeIgniter

CodeIgniter currently does not have a CLA or other formal mechanism in place for contributions. Like Symfony2 and many others, grant of rights for contributions have been assumed to be implicit. Contributions have been made to CodeIgniter because the contributors want those improvements to be included in CodeIgniter for everyone and all uses that CodeIgniter allows.

The law also makes a distinction between copyrighted work and registered copyrighted work, only the latter of which would have a standing to file a lawsuit if a dispute ever arose. There also has to be proof of financial loss as a result of the misapplication of the registered copyright. There aren’t any contributions to CodeIgniter under registered copyright, and even if there were, it doesn’t seem likely that such a person would file a law suit against every individual who has ever earned money as a result of using CodeIgniter. A nightmare to file and a bigger nightmare to prove damages. I mean, it’s free software and the contributions were made freely.

Legal burden or not, something we have been highlighting recently at EllisLab is the need for respect in the community. We want to honor and respect contributors by making sure that they understand what a contribution to CodeIgniter means, as well as ensure that existing contributors have the option to retroactively make that determination. We’d also like to make a prominent contributor page on the CodeIgniter.com web site so contributors have some well-deserved recognition. We would like to propose that this occur with three steps:

Adopt a COO for New Contributions

Rather than mess with a slow and cumbersome CLA we are proposing the adoption of a COO akin to the Linux kernel community. Since CodeIgniter source is maintained with Git, the burden on contributors should be minimal: remembering to use the -s flag when committing. If you’re using Tower, there is even a "Sign-Off" checkbox in the commit window. You could even alias git commit to use the -s flag so you don’t have to think about it.

The COO would be prominent on the GitHub home page for CodeIgniter as well as in the documentation, so it would be clear and easy for all to read. Pull requests that come in without a sign-off would be gently pointed to the COO by the Reactor team or EllisLab, and the commit messages can be easily modified by the submitter to include their sign-off.

Allow Historical Contributors a way to Opt-out

There are currently about 71 contributors to CodeIgniter, with maybe a half dozen or so with substantial, copyrightable contributions. We would like to send a message to existing contributors regardless of the scope of their contribution, thanking them and outlining what the inclusion of their contribution means for CodeIgniter. And if they decide that they do not want their work to remain in CodeIgniter, we will happily remove it.

What would it mean if contributions were removed? Well, as mentioned, most contributions are not copyrightable works. We would revert the changeset, noting the original contributor’s objection, and likely immediately recommit the same or similar bug fix / correction by a contributor who signs off on the COO. Contributions of major changes or large sets of functionality would be trickier; we’d have to revert, acknowledge their objection, and decide whether or not the functionality needed to stay in CodeIgniter. If so, it would need to be reimplemented from scratch by a developer who acknowledges the COO.

Since the contributions were made freely, we’re hopeful that we won’t have any who decide to remove their contributions, but rather than stick with the legal theory that it’s not necessary, we want to take the high road, the ethical road, the one that respects the community, and let each one decide.

Prominently Acknowledge Contributors

The last step would be to create a Contributors page on the web site, perhaps in the documentation. Something like the MODX wall of fame but recognizing code contributions rather than financial contributions.

The more substantial the size and frequency of contributions, the more prominent the recognition. Such a page would accurately reflect the worldwide nature of the CodeIgniter team beyond the core contributor, EllisLab.

Summary

We only recently educated ourselves on CLAs, as contributions to CodeIgniter were fairly sparse and minimal until we moved to GitHub a few months back. That dramatic influx and the beginning of the ExpressionEngine Reactor program brought the issue to our attention.

Now that we have educated ourselves, we agree with the OSS that they are important. We see that using a CLA or COO demonstrates respect for those who freely contribute to a project and therefore it is the right thing to do.

For ExpressionEngine Reactor which is a handful of contributors with more corporate-to-corporate IP sharing, a CLA is probably more appropriate. For CodeIgniter, we think that means a COO.

Lastly, we’d like to hear from the CodeIgniter community on our three part proposal for handling contributions and recognizing contributors.

References and Further Reading

http://www.oss-watch.ac.uk/resources/cla.xml
http://elinux.org/Developer_Certificate_Of_Origin
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches
http://www.garfieldtech.com/drupal-symfony2
http://forge.mysql.com/wiki/ContributingFAQ
https://www.djangoproject.com/foundation/cla/
http://developer.joomla.org/contributor-agreements.html

We need someone with the following traits.

• Customer Focused.
• Solid Front End Development skills.
• Solid Visual Design skills.
• Desire to help make the web better.

Sound like you? Good, let’s talk.

Send your cover letter to James Mathias (Chief Creative Officer), along with a URL to your online portfolio and a PDF attachment or URL to your resume, and let’s talk.

EllisLab makes ExpressionEngine, CodeIgniter and MojoMotor. We make online lives better, and we all get to work from home.

Salary is dependent on experience.

Individuals that can legally work in the United States (citizen, work visa) are welcome to apply. Third-party contractors, agencies, recruiters, etc… will not receive a response.