Reddit’s /r/ProgrammerHumor has recently treated us to this politically incorrect and quite childish little Open Source rant
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
- The Free Software Foundation
- The Eclipse Foundation
- The jQuery Foundation
- Joyent (Node.js)
- The Apache Foundation
- Our own (jooq.org)
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.
If you fork a repository, submit a pull request that doesn’t change the license, do you still need a CLA?
— Assaf Arkin (@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.
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:
Choose wisely when integrating third-party software. Even if it is Open Source
|Reference:||Open Source Completely Underestimates Contributor License Agreements from our JCG partner Lukas Eder at the JAVA, SQL, AND JOOQ blog.|
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.