Intro to open source software licensing ($$$)
The concept of open source software is simple in principle, but complicated in practice.
Disclaimer: I wrote this, and didn’t publish it, about a year ago. I don’t have time to proofread, so please — any revisions are appreciated.
FOUR PLAYERS AT THE TABLE
The Owner(s): These would be the founders of the project who claim the copyrights.
The Contributor(s): Community members who make contributions to the repository.
The Implementor(s): When you include a library in your project, we could say that you are implementing it. These are usually developers and the companies they work for.
The End User(s): The software created by the implementor is then distributed to their end users.
As the owner of a public repository, you may choose to use an open source license, although there’s nothing forcing you to do so.
The simplest way to make a program free software is to put it in the public domain, uncopyrighted. — Free Software Foundation
Or, you can explicitly maintain copyrights with a copyright notice. You may have seen “copyright Author Name 2016” in code comments at the beginning of a file.
A copyright alone, without a license, means you reserve all intellectual property rights, and nobody can safely use your code.
Contributors won’t contribute to your code, and implementors wont implement your code, unless they have assurances about the costs and legal ramifications of doing so.
This is where a license comes in.
The license is a legal contract that defines what is/is not allowed, and relieves the owners of any liability if the code causes catastrophic losses. All open source licenses guarantee free (no cost) use, so the owners can’t suddenly decide to demand payment. There are generally two types of open source licenses: permissive and copyleft.
The permissive licenses (such as MIT, BSD, and Apache) pretty much allow anything, for free, for anyone, and for any purpose. Including commercial for-profit use.
The copyleft license (such as the GPL) also allows anything, for free, for anyone, for any purpose, including commercial for-profit use, with one significant caveat:
This is a viral license, which requires anyone who uses GPL licensed code to also use the GPL license and publish their own source.
A drawback to the copyleft license, is that closed source projects can’t use GPL licensed software. For example, if Adobe wanted to use a GPL licensed library in their Photoshop application, they would have to release Photoshop under the GPL license, destroying their business.
Thankfully there aren’t many GPL licensed projects, and I’ve never had to worry about this. There is, however, a few interesting applications of this concept [link to Monetized Open Source Software, also a Contributor-Share system, where modifications are automatically shared with the author, who is given the right to include them, for profit, in their software]
THE CONTRIBUTOR LICENSE AGREEMENT
The open source licenses discussed thus far are for implementors. Or, at least, dictate how the software is to be implemented. They don’t, however, cover the rights of the contributors.
Imagine you help someone with their repo, and end up writing 40% of the code. That person then tries to close source the project and sell it for money. Technically, you retain copyrights, unless you’ve agreed to give them away.
The CLA is a contract between the contributors and the owners, and defines how the copyrights of the contributions are transferred to the owners. Not all repos implement one, but I’ve been seeing them more frequently.
If your repo doesn’t have a CLA, then technically your contributors maintain intellectual property rights for their own contributions. If you ever wanted to change the license, you’d need to contact all contributors and get their permission to relicense it. I think. I’m not an expert (or a lawyer).
Some repos simply put a CLA in the root folder of the repo, and it’s an implicit/passive agreement. Others have strict enforcement. You have to (virtually) sign a CLA before you can submit a pull request. Here is Google’s CLA, for example.
DUAL LICENSING OPEN SOURCE SOFTWARE FOR PROFIT
Owners can use a dual licensing strategy that involves publishing their code under the GPL, and also selling less restrictive licenses to those who don’t want to open source their code. The GPL source code helps build a community and attract contributors. Anyone trying to use the code to make money (without purchasing the appropriate license) faces legal consequences if they aren’t following the GPL license agreement.
I haven’t seen it in action, but apparently MySQL uses this strategy. I read about this strategy in this great article from 2006, and have wondered why I haven’t seen it done more often.
CAN YOU CHANGE YOUR LICENSE?
If you sell your bike on Craigslist, are you allowed to change your mind a week later, and reclaim your bike?
Let’s say you add an MIT license to your new project, and push your code to GitHub. You then decide to remove the MIT license, and retain full copyrights. Anyone who got their hands on the MIT licensed code is legally allowed to use, modify, distribute, etc.
Having said that, if you do change the license for future versions of your code, then you effectively halt any new contractual agreements. The holders of the old versions are allowed to use them as they have been, and any newcomers are passively agreeing to your new license contract.
When you publish your code with a license, its a legally binding agreement. That doesn’t mean you can’t change it. I doubt it would ever matter, though. In the next commit, just change the license, and the new version of the code is legally bound to the new license.
As with many intellectual property concerns, it’s largely about interpretation. The who, what, when, where, why, and how any of these contracts are upheld is dependent on specific details. I’m not a lawyer.