Open source components have changed the way we develop software. Ready-made libraries from the open source community enable busy developers to focus on creating the secret sauce needed to release the new and exciting software products of tomorrow, today. And it doesn’t cost a cent. Or does it? Downloading an open source component doesn’t require your credit card number, but the open source license attached to the component does demand you abide by certain terms and conditions. Especially when it’s an open source copyleft license.
While the copyleft license used to be the most common open source license in use, over the past few years we’ve seen a decline in copyleft license use and a rise in permissive licenses. That said, the copyleft GPLv3 license is still the third most popular open source license out there, and overall, copyleft licenses account for nearly 40% of the open source licenses in use.
Considering open source components comprise between 60%-80% of today’s software, chances are you’re using a copyleft license and need to know what that means.
According to the GNU, the founding fathers of the copyleft open source license, copyleft is a method for making a software program free, while requiring that all modified and extended versions of the program also be free, and released under the same terms and conditions.
When an open source software project is published with a copyleft license, other developers have the right to use, modify, and share the work as long as the reciprocity obligation is maintained. Any software created using an open source component with a copyleft license must be released as open source as well. The result is that any software product containing an open source copyleft license, even when it’s only a few lines out of mountains of code, must make its entire source code available for free, along with the rights to modify and distribute it.
The birth of the copyleft open source license, or the reciprocal license, is one of the most significant milestones in the history of free and open source software (FOSS), and it starts with the GNU GPL license.
It all began in 1984, with Richard Stallman’s decision to develop the GNU project, a complete operating system that would be developed and released based on his concept of free software, which grants its users four essential freedoms:
Stallman needed to find a method to ensure that his creation is released subject to these four basic freedoms. Sounds simple? At the time, it was unheard of.
According to David Bretthauer’s publication on the history of open source, each of the traditional methods of making software available — releasing it into the public domain, or closing the source code and using copyright and licensing terms to protect from modification, presented a problem for Stallman. Bretthauer explains “releasing software in the public domain means anyone can take it and appropriate it for their own use, including copyrighting it themselves and licensing it as a proprietary product. Releasing it with restrictive copyright and license terms prevents the entire user review, bug fix, and feature addition mechanism which Stallman had found valuable.”
This is where copyleft open source licensing comes in, taking copyright terms and reversing them. In the GNU’s words: “To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program’s code or any program derived from it but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable.
Proprietary software developers use copyright to take away the users’ freedom; we use copyright to guarantee their freedom. That’s why we reverse the name, changing “copyright” into “copyleft”.
The first version of the copyleft GNU GPL was born in 1989, followed by the second version’s release in 1991. In 2007 the GPLv3.0 to clarify the previous version and keep the GPL up-to-date, as software and technology evolved.
Releasing software under the copyleft open source license and free software, in general, were revolutionary concepts, and since the release of the first GNU GPL, copyleft has received criticism from all sides. Early on, it rubbed many software development organizations in the public sector the wrong way. Today, many in the community criticize copyleft open source licenses for being too strict, and prefer permissive open source licenses.
Detractors call the copyright open source licenses “viral” because they see it as “contaminating” any work that derives from it, destroying users’ intellectual property along the way. Happily, many see the benefits of using a copyleft open source license.
In his blog, software developer Richard L. Apodaca, explains that one of the main reasons that developers choose copyleft open source licenses for their projects is to stop commercial companies that give nothing back to the community from using their software. The second reason is that developers want to prevent other projects from using parts of their open source projects (otherwise known as forking), to create a competing product based on the original work.
Ben Cotton of Red Hat advises developers considering using a copyleft open source license for their software projects to think both of their philosophy and their goals for the project. Another factor that he recommends developers consider is the ecosystem that they would like their project to fit into since projects based on a specific language or technology will often use the same or similar licenses.
As open source usage became mainstream, and the community of developers grew exponentially, it became important to provide developers with all of the information that they need in order to choose the license that suits their projects’ needs. If you want to make an educated decision about using a copyleft license, or which one to choose, GitHub’s choosealicense.com offers simple explanations about open source licenses.
Whether you end up going with a copyleft open source license or you decide to choose a more permissive one, when choosing an open source license, it’s best to remember Ben Cotton’s sound advice: “If you want your project to be able to play nicely, you may need to make sure the license you choose is compatible.
*Disclaimer: This post is not legal advice, it is for informational purposes only. If you need legal advice, you should consult with an attorney who has reviewed all relevant facts and applicable.