What are Open Source (OS) Licenses?
OS dependencies are being used very broadly among developers due to their amazing benefits.
Studies show that ~85–97% of the software applications rely on OS components, and the average project now has 203 dependences, according to GitHub’s State of the Octoverse survey.
Simply put, the license is what turns a code (project) into open source software.
An open source license is basically a legal and binding contract between the author of the OS dependency and the client who consumes the service, in this case, the open source code.
The license states that the software can be used in commercial applications only under specified terms.
As a developer, you can’t just use, copy, modify or distribute open source dependencies. In order to properly (and legally) use an OS dependency in your software, it is mandatory to be aware of the permissions, limitations, and conditions of each license of each open source dependency you use in your code.
What are the different types of OS licenses?
Every open source package uses one (or more) license and there are more than 100 different OSI licenses Approved.
These licenses can be divided into 2 main groups:
- Permissive
- Copyleft
Permissive – as the name suggests, the licenses that fall under this group provide more freedom to use, copy, modify, and distribute the OS dependency code.
These have very minimal restrictions on the way you can use them in your software, allowing its use in proprietary derivate projects.
Copyleft – These types of licenses are less permissive, and they typically contain a restriction to use, modify, and distribute the content of the OS dependency.
We can think about the code as intellectual property of the author of the OS dependency, which needs to “approve” you to use its content.
Thus, one of the most noticeable limitations of using such dependencies is the obligation to make their code open for anyone.
These are a few of the most popular licenses and their type:
|
Copyleft license |
Permissive license |
|
GPL (GNU General Public License)
|
|
|
|
|
|
|
BSD (Berkeley Source Distribution)
|
Table 1
Comparison:
The GNU’s General Public License, or GPL, was created by Richard Stallman in order to protect the GNU software from becoming proprietary. This license falls under the copyleft type, which requires anyone using an open-source dependency with a GPL license to release their code as open source.
The Apache license was created by Apache Software Foundation (the ASF) in order to allow free usage, modifications, and distribution of Apache-licensed products. Apache 2.0 falls under the permissive type of licenses, but nevertheless, there are a few limitations and conditions that must be fulfilled, in order to properly use its products.
In Table 2, we can see a comparison between these two licenses:
|
|
GPL 2.0
|
Apache 2.0
|
|
Conditions |
|
|
|
Limitations |
|
|
|
Permissions |
|
|
Table 2
*In GPL 3.0, the GNU organization added the patent use aspect to the permissions list, allowed developers to add local disclaimers, and expanded the development options. All of these are in order to expand the usage of GPL worldwide.
Why you should be concerned
Without any doubt, writing and distributing an uncompliant software may put your business at risk. The risks to a non-compliant business are not limited just to just lawsuits, but may also force you to share your code with the world, damage your business reputation among the OS community and your clients, hurt your chance to make a successful IPO, prohibit you from commercially distribution your product, and much more.
Law suite examples:
In an ongoing scenario, Elastic Vs Amazon, Elastic had to change its license to a different, restrictive license in order to prevent Amazon from using its service to distribute an Elastic-built software from Amazon Web Services.
“The move to block users from buying Elastic-built software from Amazon Web Services — by switching to a restrictive software license — capped a years-long dispute between the two companies that started in 2015, when Amazon’s cloud unit launched its own competing product based on Elasticsearch’s code, and named it Amazon Elasticsearch Services — causing confusion about who created the software, and diverting customers from Elastic”.
Elastic changed their license from Apache 2.0-license to the Server Side Public License (SSPL) which was explained in:
“Our license change is aimed at preventing companies from taking our Elasticsearch and Kibana products and providing them directly as a service without collaborating with us.”
This battle is yet to be decided in court, but in case Elastic will prove right, Amazon might have to pay a big chunk of money due to using Elastic licenses’ in a non-compliant way and not following the conditions and limitations it requires.
So, what should you do?
Every organization has to make sure they are properly managing their open-source licenses risks.
Managing your open-source dependencies and their risk can be a very tedious, overwhelming challenge due to:
- The high number of open-source dependencies your organization use on the code
- Challenge of collecting each license they are using
- Categorizing these licenses into risks
- Prioritizes these license’s risks
- Fixing the compliance issues
For that, Checkmarx Software Composition Analysis (SCA) solution enables your organization to address open source license issues earlier in the SDLC, and cut down on manual processes by scanning your code, identifying the license type and the risks it contains, so you can deliver secure & compliant software faster and at scale.
For a free demonstration of Checkmarx SCA, please contact us here
