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.
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:
|None*||Three page PDF, snail mailed†||Two page PDF, snail mailed‡||Two page PDF, snail mailed§|
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.
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
(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 <firstname.lastname@example.org>
Git even introduced this as an automatic feature with the —signoff (or just simply -s) flag of the commit command.
git commit -s -m "This is my commit message, and it will automatically be signed"
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.
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:
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.
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.
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.
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.