Open-source Licenses: What Are They and Why Do We Need Them?

An open-source license is a strange concept. Why would you need a license to use something that people use for free? However, open-source software is free only as in "free speech," not "free beer." There are still rules and guidelines needed to regulate its use. Otherwise, it can turn into chaos real quick.

In order to understand the need for open-source licenses, one has to come to grips with one fact: Any code you write is subject to copyright laws. Why? Because software is treated as literary work under the law. You, and only you, are entitled to use, publish, and modify that code, and the copyright lasts until 70 years after your death.

That puts developers in the same position as authors, songwriters, architects, etc. They are artists, and this is not hyperbole. However, there is one problem: An author would probably not want somebody else to build upon his work and modify it. Likewise, a songwriter would not be happy if someone changed the lyrics of one of her songs. These literary works are one-and-done. Software code is not.

Some developers want to enable other people to work on, modify, and improve the code they wrote. Just putting the code out there does not cut it because the code is protected by copyright laws. Anybody, no matter the intention, would be infringing on copyright once they start modifying the code. If you want people to use your code but only on your terms, then what you need is an open-source license. These licenses afford copyright owners differing levels of control over the code they wrote, define the terms on which downstream users can make use of the code, and make collaboration on open-source projects possible.

There are more than 80 open-source licenses approved by the Open Source Initiative (OSI), a non-profit organization that defines what open-source is and promotes its use. However, most of the use cases in the software world are covered by a small portion of that number (around 10-15 most popular licenses).

Open-source licenses can be grouped into two main categories: Copyleft and permissive.

Copyleft

Copyleft licenses are the ones that allow derivative works but subject them to the same requirements as the original work. Suppose you modify an existing open-source code under a copyleft license. In that case, you are liable to publish your modifications under the same license. These licenses require a developer to give back to the community after using open-source code.

This "give-back" requirement helps keep the community alive. But, on the other hand, it stifles business growth. Every minor modification made to the code triggers the obligation to republish the work, which makes the commercialization of a product almost impossible.

Distribution is the key action for copyleft licenses. The term refers to the transferring of a copyrighted work from one legal person to another, and this transfer is what triggers the clauses in the copyleft licenses. There are two types of copyleft licenses:

Strong copyleft: This license involves a "viral effect." This effect requires the modified version of a source code to be distributed under the same license as the source code. If a piece of code that is under a strong copyleft license is added to a project, all the components of that project have to be licensed under the same terms. GPL 3.0 is an excellent example of this license type.

Weak copyleft: This particular type of license lacks the viral effect of the strong copyleft. Works under a weak copyleft license can be integrated into an aggregate project without affecting the latter's existing license. Among the weak copyleft licenses are Mozilla Public License and Eclipse Public License.

Permissive

Also known as "attribution style licenses," permissive licenses give users the freedom to use, modify, and redistribute open-source code while also permitting proprietary derivative works. That's why people prefer permissive licenses over copyleft licenses for commercial purposes.

Application security company Mend has recently conducted a study on the WhiteSource database, which includes 4 million open-source packages and 130 million open-source files, to determine the most popular open-source licenses. The study revealed that permissive licenses have been gaining popularity at the expense of copyleft licenses for a decade now. Only 41 percent of open-source licenses were permissive in 2012. The figure gradually increased to 78 percent by 2021. In the meantime, the share of copyleft licenses fell from 59 percent to 22 percent. Apache 2.0, MIT, and BSD have been the most popular permissive licenses in this period.

Choosing the right open-source license

One of the most strategic decisions you can make at the start of an open-source project is to choose the right open-source license. Having the foresight and ability to do so helps you avoid potential roadblocks and compatibility issues down the road. Here is a short list of guidelines to keep in mind presented by Mike Miles, Senior Technical Solutions Officer at Genuine at the time of the recording:

• What licenses are already being used by your software? The licenses already in use by your software may dictate which licenses you may or may not choose.

• The terms of service of the platform that hosts your software are crucial. If you are to keep your code on GitHub, you are expected to consent to the creation of derivatives on your open-source code.

• Copyleft would be a good choice if you want derivatives, additions, and distributions to use the same license and follow the same guidelines. If not, go with a permissive license so you will only get cited for your work.

• Whether you plan to let others use your software in their own proprietary software matters. If you don't care, go with weak copyleft. Otherwise, pick strong copyleft.

Understanding what open-source licenses are and how they work can save you a lot of headaches managing your open-source project. Make up your mind on the goals of your project (whether you are going to monetize it or keep it purely developmental); then, your decision tree will become a lot simpler.