Open Source Completely Underestimates Contributor License Agreements

Lukas EderApril 14th, 2014Last Updated: January 5th, 2015

0 35 4 minutes read

Reddit’s /r/ProgrammerHumor has recently treated us to this politically incorrect and quite childish little Open Source rant

Open Source according to /r/ProgrammerHumor

Obviously, like most “discussions” on reddit and specifically those discussions about Open Source, things got quickly very serious with people referring to Richard Stallman and how these critiques are childish and immature and what’s-wrong-with-our-industry™ etc.

Let’s not delve into useless polemics but let’s have another look at a real problem in Open Source:

Two types of Open Source

There are essentially two types of Open Source:

Hobbyist’s Open Source
Professional Open Source

Hobbyist’s Open Source

Hobbyist’s Open Source projects are geeky side-projects by some engineers / hackers / script kiddies / etc. who have fun experimenting with 1-2 things and who are hoping to have “the public” comment / use / profit from their work. They most often have no interest in money / fame / rewards. They’re just doing it for the fun. Most often, they also choose funny licenses, like the Beer License. There’s nothing wrong with that.

Professional Open Source

Professional Open Source may evolve from the above (as in our case), or it may be conceived as professional Open Source from the beginning (as most Apache, Red Hat, or Oracle projects). When doing professional Open Source, choosing the right license is of the essence, as it is almost impossible to change that license again. Why? Because all contributors effectively own their copyrights of their contributions under the terms of the original license or worse under their own terms.

This is less of a problem if you’re choosing a license like the ASL 2.0, which also manages contributions (and any trademarks, patents foregoing a contribution) in section 5:

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

However, you may still not change the license form ASL 2.0 to anything else (like GPL, or commercial) without the express permission of all your contributors. At least not for the contributed code.

Managing contribution restrictions with CLAs

At Data Geekery, we want to stay in full control of both source code maintenance, but also copyright. We take copyright very seriously, which is why we have bought / internalised all essential contributions by our contributors through a CLA (Contributor License Agreement). This allows us to continue publishing our jOOQ code under the terms of the ASL 2.0 and our more restrictive commercial license.

Few Open Source projects / platforms actually do this. Among the most famous ones are

If you’re serious about your Open Source project, do take due diligence seriously as well. Copyright is not an option, you have to get this right, also in the best of interest of your customers / users. If you do not agree on contributor license terms with your contributors (e.g. by blindly merging all sorts of pull requests in your GitHub repository), you will:

Restrict yourself to the current license forever
… this includes not being able to dual-license your software
… this includes not being able to commercially license your software
… this may include the risk of having to pay royalties later on (not with ASL 2.0)
… this may include the risk of your users having to pay royalties later on (not with ASL 2.0)

CLAs on GitHub

GitHub has become the number one hosting service for Open Source projects, world-wide. Yet, many projects are not getting licensing right. While GitHub offers a simple way to specify a popular license for your repository, there is currently no easy way to have your contributors sign CLAs.

I’ve recently had a short discussion on Twitter with Assaf Arkin and Stefan Tilkov:

If you fork a repository, submit a pull request that doesn’t change the license, do you still need a CLA?
— @assaf@labnotes.org (@assaf) March 22, 2014

We all agreed that this is currently not handled correctly, in most cases. I have thus sent off a feature request to GitHub:

I would like to enable a checkbox which all contributors have to check (after reading a document), to confirm that they’re complying with the contribution terms. You already have a similar feature with licenses when creating a new repository, which is great. But many people inevitably run into due dilience cases, because they just blindly merge all pull requests offered by anyone. So it would be useful to have a couple of default texts to chose from, and a possibility to create our own.
Right now, I’m sending off PDFs by E-Mail for a signature. I hadn’t thought of Google Docs, yet, good idea.
One source of inspiration could be the Eclipse Foundation, which has a fully automated CLA process, integrated into BugZilla. If a user submits a patch, you can immediately see if they have already signed the Eclipse Foundation CLA.
I think that this would be a killer feature for GitHub, at least for the more professional OSS repositories.

This feature request was well-received with GitHub support. If you think that this is a good idea, send them some love as well. It would really be great to finally get this right.

Conclusion

If you’re a user of Open Source software, beware of the above. Don’t just integrate any geeky script / tool that you happened to have found on the internet in your corporate, enterprise software. You are putting your employer at great legal risk if you do so. Open Source is not an excuse to pretend everything is free (of charge and of obligations). It is as well-defined a business as anything else. We cannot say this enough: