If you’ve read a little bit about software licensing or Linux you probably know a few things about copyleft and it’s restrictions and requirements. If not and you’re just curious about what copyleft is, welcome anyway.
A little history
To give you a bit of history, copyleft is a concept created in the mid-80s by Richard Stallman. Long story short, he was working on a Lisp interpreter and when another company called Symbolics asked him if they could use it, he provided it to them via public domain. Symbolics improved the interpreter, but when Stallman wanted to access those improvements they refused. This highlighted a pretty big flaw in using the public domain, especially for cooperative works. Anyone could break away at any time and restrict access to their modifications.
This prompted Stallman to create a new type of license called Emacs General Public License (this later evolved into the popular GNU GPL). The concept was based around four freedoms:
- freedom 0 - to run the program in any way and for any purpose
- freedom 1 - to study the source code and change it
- freedom 2 - to copy and share the program with others
- freedom 3 - to distribute copies of your modified version
This however was not yet copyleft. In order to protect those rules from being changed a further rule had to be added, that all derivative works also follow those same rules. So that the author of a modified or improved version could not impose any restrictions that violate those basic rules. Today it simply means that any modified or improved version has to be distributed under the same type of license i.e. copyleft.
Credits: undraw.co
These rules allow a certain degree of flexibility as long as it does not infringe on their basic premise. For example you can require modified versions to use a different name or logo than yours or to identify their modifications.
Advantages
Copyleft licenses are sometimes referred to as viral licenses because all derivative work ‘carries’ the copyleft license. Despite that moniker, there are actually significant advantages to using them:
- preventing companies from using software and giving nothing back to the community,
- preventing others from using your work to create a competing product.
The first argument being a reference to situations like the above-mentioned Symbolics affair. The second refers to cases where a company can create a product that will compete with yours by using your own code. Taking into account that it may also have significantly more resources available it might not be a fair competition at all.
Strong vs weak copyleft
Another advantage is that the copyleft is quite flexible in applying its core rules. This has led to two main branches of licenses called strong and weak copyleft.
strong copyleft - means the provisions of the original license are imposed on all derivative work. Derivative work can be relicensed under a different copyleft license, but only if it is compatible with the original license. The most popular examples are GNU GPL and EU Public License.
weak copyleft - is a compromise between strong copyleft and permissive licenses. It allows more flexibility in the provisions such as linking from code licensed under different types of licenses (even non-opensource ones) or incorporating code in larger software (even if it isn't copyleft). The most popular examples are LGPL and the Mozilla Public License.
Popularity
All in all, copyleft remains immensely popular among developers, even though it has been declining for the past few years. According to WhiteSource three of the six most widely used licenses are copyleft with versions two and three of GPL carrying the torch. Lots of popular programs like VLC media player, 7-zip, Firefox, and Openoffice are licensed under copyleft licenses.
Credits: undraw.co
Read up
Most developers advise those considering a copyleft license for their work to think about the long term plans and goals of their project. Another important factor is considering the environment where you want your project to fit in, platform or language, and how compatible your chosen license is with those most used there. So read up before you make up your mind.
A guest blog post for GraphQL Editor blog by Michal Tyszkiewicz
Speed up your GraphQL API development
GraphQL Editor is a supportive tool for both advanced GraphQL users as well as those taking their first steps with GraphQL APIs. Our all-in-one development environment for GraphQL will help you build, manage & deploy your GraphQL API much faster thanks to dozens of built-in micro features. Try GraphQL Editor for free!
Top comments (5)
Good overview. I would argue that the more strict versions of copy-left licenses are a bit more controversial. E.g. AGPL v3 is used a lot by companies that want to restrict people's freedom of what they can do with the software without paying for a commercial license. I've always found this ironical.
A reason contract licenses such as Apache 2.0 or simple copyright waivers like the MIT and BSD licenses are extremely popular on Github is that they are a lot less restrictive on users. There are a few funnily worded variants of the MIT license that basically state "do whatever the F*** you want. It's a model that works well for authors of small libraries that mainly just want to remove obstacles for people to actually enjoy their work. I usually slap the MIT license on anything I put up on Github.
Some of the more popular GPL projects like Linux use GPLv2. Part of the reason for the success of Linux is a few unintended loopholes in the wording of this license allowed electronics manufacturers and linux distribution providers to bundle non OSS software and get away with that. This lead to GPLv3 but the linux ecosystem never moved to that. IMHO without these loopholes, we'd probably be using some BSD variant by now. E.g. Android would not be very practical in its current form with a stricter license requiring everything to be open sourced.
Most big companies seem to gravitate to Apache style licenses as it just uncomplicates the legal due diligence of actually using each other's software. I worked in Nokia around the time it was doing Linux phones and I can tell you that legal departments were very defensive when it came to their competitors finding any excuse to go to court. They dealt with copyright, trademark, and patent issues all the time and were settling cases (mostly in favor of Nokia because they were good) for very non trivial amounts of dollars all the time.
This is true for most big corporations. Most of them would not touch anything AGPL licensed because it's just not worth the risk and actively enforce policies to prevent this happening. GPLv2 was OK (obviously) but they vastly preferred Apache 2.0 and MIT style licenses.
The reason Linux is still GPLv2 is because they didn't include "or later version" is the license text, which basically prevents them from upgrading to GPLv3. If they wanted to change this they need to track down every contributor to ask for permission.
Technically, yes. But the net effect has been that it's become very popular with companies that depend on the unfixed loopholes. You are right that the reason switching for Linux never happened is also that it would require permission from the copyright holders.
But if I recall correctly, Linus Torvalds was biased against this in any case (probably for the reasons I outlined). Either way, the license has served Linux well.
I would even say that without the GPL attached to it (with linking exception) the Linux kernel wouldn't have been where is was now.
Makes me think of GPL.