You’ve got a great project and you want to share it with the world. Like, really share it — let people see the code, alter the code, or use the code for their own projects. You want to make your work open source! Awesome — it’s time to get a license.
What is a license and why do I need it?
A license turns plain old code into an open source project. But my code is already public on Github, you may be saying, it’s easy to find and anyone could just copy and use it. True as that may be, we need a license to officially give permission to those who may want to use the code, as well as direct them in which ways they are allowed to use it.
WhiteSource does a great job explaining the actual role of open source licenses, describing them as legal and binding contracts between the author and the user of a software component, declaring that the software can be used in commercial applications under specified conditions.
Great! So what are the conditions?
Copyleft vs Permissive Licences
Open Source Initiative identifies and officially endorses over 80 licenses, so it stands to reason that there are subtle differences that make each one unique compared to the others. With that being said, it’s helpful to understand that each of these licenses falls somewhere on the spectrum between copyleft and permissive.
Copyleft as we know it was defined by Richard Stallman of GNU. In his 1985 GNU Manifesto, he wrote:
Copyleft uses copyright law, but flips it over to serve the opposite of its usual purpose: instead of a means for restricting a program, it becomes a means for keeping the program free.
The central idea of copyleft is that we give everyone permission to run the program, copy the program, modify the program, and distribute modified versions — but not permission to add restrictions of their own. Thus, the crucial freedoms that define “free software” are guaranteed to everyone who has a copy; they become inalienable rights.
The piece focuses on technology’s (and society’s) right and responsibility to share the tools that might benefit others without restriction. This does not mean sharing them at no cost, but it does mean making them public. To maintain the purity of this freedom, copyleft dictates that a product’s code, all versions of that code iterated on by others, and all products that in some part implement the code must be made publicly available. If a version of GNU software was going to be a part of a larger project, that project had to be free for all to run, modify, and redistribute.
In light of Stallman’s focus on freedom, it’s ironic that the opposite end of this spectrum has come to be called permissive. In requiring those who wanted to use GNU software to make their own work public, copyleft actually proves quite restrictive. Permissive licenses, on the other hand, state that a project’s code can be used for any purpose, public or private.
More simply put: copyleft means that our open source code may not be used for a proprietary product, while permissive means that it may.
And…
There are of course other factors written into the various licenses that we come across, notably details about patent licenses and litigation and legal jurisdiction. What we will most often notice, however, is what restrictions, if any, a license places on reproduction and distribution. Let’s look at a few examples:
- GPL: the GNU Public License is the poster child for copyleft and is therefore quite restrictive on use. Any software that incorporates any part of a GPL licensed project must release their full source code and the rights to reproduce and distribute that code.
- Apache: A permissive license distributed by the Apache Software Foundation, Apache allows for use, modification, and distribution of software for personal, internal, or commercial purposes. Licensed software can be applied to both copyrights and patents.
- Ms-PL: Microsoft Public Licenses allow for reproduction and distribution of the work in question, but you are not obligated to distribute source code. There’s also a nifty non-warranty clause, protecting the author if their code doesn’t work out for someone who integrates it into their work.
- EPL: The Eclipse Public License is more copyleft than permissive — it states that you must disclose modified code if you use it as part of your software, but does not require the entirety of the software to be made public. According to WhiteSource, The Eclipse Foundation makes clear that, in their opinion, ‘merely interfacing or interoperating’ with an Eclipse plugin does not make your code a derivative work of the plugin.
- MIT: This is among the most popular licenses because it is very easy to understand: use the software however you like, just make sure to add a copy of the original license and copyright to your work. In that sense, it is extremely permissive.
There is a tremendous amount of detail behind each of the dozens of written licenses for open source software, so choose carefully if you are building something that might turn out to be highly valuable to third parties. Keep in mind that the spirit of open source software is the development and enrichment of our community and that hopefully your software, and your license, promote those values.
Sources:
WhiteSource’s Open Source Licenses Explained
OpenSource.com’s advice on how to choose a license
Open Source Initiative’s conditions for being called Open Source (Open Source Definition)