Every developer, team and organization owe it to themselves to be aware of and understand at least the basics of open source licenses.
Using open source dependencies with different types of licenses for a commercial project? Or are you looking for more information on open source licenses as part of setting a license for a package of your own?
Then you may be looking for answers to questions like:
- What are open source licenses?
- What are the main differences between copyleft and permissive licenses?
- Why do I have to care about licenses for the packages I use?
Questions that this post aims to answer and provide some context for popular open source licenses on the way.
But wait, aren't open source packages free to use? Open source code is free and available for anyone to use — but there are limitations and restrictions.
The open source license restricts users on what they can or cannot do with a package.
And it's up to each developer or business to remain compliant.
Disclaimer: Information in this post should not be considered legal advice.
Open Source Licenses - the basics
Open Source Software Licenses allow developers to share their code and components as open source.
With the use of open source packages being the modern standard, the number of dependencies for most projects count in the hundreds.
All these open source dependencies come with license obligations.
Each license defines how other developers are allowed to use these components in their own work. Typically this can be thought of as:
- Do's - things the license allows you to do
- Don'ts - things you are not allowed to do
- Must's - things you must do
There can be a wide variation between different licenses on what you are allowed and must do.
By using open source components you’re implicitly signing a contract that binds you (i.e. developer or company) to the do’s and don’ts of how you use that piece of code.
Standardized licenses vs non-standard
Most open source packages one encounters uses some form of standardized license.
The benefits of using standardized licenses are many: Reliable identification of licenses, recognizability, trust and more. People naturally shy away from the unknown and prefer to use open source packages with standard licenses.
There are several organizations who provide guidelines and definitions regarding open source software licenses.
The Open Source Initiative defines a list of some 80 certified open source licenses and the SPDX License List provides a list of commonly found licenses.
Non-standard licenses, on the other hand, are any license or license text that does not fit into the standardized format. It can be a completely custom license, a custom copyright provided by the author or simply some license that does not fit into the term open source.
What non-standard licenses have in common is that they usually require some kind of manual review and approval from users.
Npm package licenses
For npm packages, license(s) information has its own section in the package.json file.
But it is important to know that there are no rules forcing package maintainers to provide any license information in package.json. Licenses might just as well be found in a LICENSE.md file or as part of any other file of a project.
Multiple licenses for a single package are also something that needs to be considered. A single package can have multiple licenses that either define the obligations for a specific scenario or for an individual piece of code.
What about open source code without a license? A software component without a licence is not free to use. By default it is fully copyright protected, so developers have no legal rights to use, modify or share it.
One package. Multiple licenses
The npm package abbrev has the licenseISCdeclared inpackage.json, but two different licenses are available in project files!Want help identifying licenses in your projects? Visit Bytesafe License Compliance page!
Copyleft vs Permissive
To allow for easier categorization and understanding of the basic principles of licenses, open source licenses can generally be divided into two main categories: copyleft and permissive.
This categorization is based on the requirements and restrictions that the license places on users.
A copyleft (or strong copyleft) license allows derivative work, but requires you to release such work under a compatible copyleft license.
Copyleft licenses are linked to the principle of reciprocity where authors want to ensure that any derived work (modifications, improvements) are also made available as open source and to the benefit of the public (and not released as closed source).
A permissive (or non-copyleft) license places minimal restrictions on how others can use the open source components.
Permissive licenses allow for modifications, use in software distributed under other licenses, as well as use in non-open source (proprietary) software.
As such permissive licenses are usually the go-to type to be used by organizations with commercial intentions for their software.
Weak copyleft is a variation of the copyleft type, that is aimed at creation of software libraries. Software that uses a library with a weak copyleft license are not necessarily forced to release derived work under a compatible license (rather it depends on how it is used).
Popular Open Source Licenses
Let's look at an overview of some of the most common standardized licenses and the characteristics for them.
To read the full license text, use the links below (directing to GitHub supported choosealicense.com).
MIT & ISC - The go to permissive licenses
The MIT License (MIT) is one of the most recognizable open source licenses.
It is permissive and places minimal restrictions on what you can do and must do. The license allows distribution and use of the component for commercial use while requiring only that the original license notice and copyright is included in any copy of the software.
The ISC License (ISC) is functionally identical to the MIT License, but with some wording deemed unnecessary removed.
The ISC License is the default license used when setting up a new npm package with the npm init command.
With their permissive and simple nature, both the MIT and ISC licenses are popular for open source components. Especially if the primary intent is to be shared as dependencies for other open source projects.
As such they are among the most used licenses for packages in the npm ecosystem.
Apache-2.0 - permissive and suitable for use by larger organizations
Apache License, Version 2.0 (Apache-2.0) is another popular permissive license.
The main characteristics of Apache-2.0, compared to other permissive licenses, is that it provides users with a grant of patent rights from contributors.
This makes an open source component under this license safer to use.
The fact that Apache-2.0 addresses patent licenses, makes open source component under this license particularly appealing to any organizations that want to make sure they are not infringing patents when using a piece of software.
Gnu Public License (GPL) - copyleft at its core
The Gnu Public License is the original for the copyleft concept, where use of a GPL licensed component forces derived work to be released to the public under a compatible license as well.
Developers and organizations that promote collaboration and code sharing before anything else may prefer a license like GPL.
But for many organizations the use of open source components with a GPL License is not preferred compared to a more permissive license with fewer restrictions and limitations.
Why you need to care about licenses for the packages you use
Part of dependency management is knowing what packages your projects are using. Including the licenses attached to those dependencies.
Without this knowledge you could possibly be in breach of open source licenses agreements already.
A short-list of possible consequences for license non-compliance:
- Restrictions on selling your software product
- Involuntary release of your source code
- Negative press coverage for non-compliance
- Loss of reputation with customers or with the open source community
For a more extensive list of possible consequences, check out our Open Source License Compliance page.
Identifying non-standard licenses
The npm package jsbn has the standardized licenseMITdeclared inpackage.json, but a custom license is also available in project files.The Bytesafe License Scanner can help you identify non-standard or problematic licenses.
License compliance can be complicated
Make sure to address open source software licenses in your code supply chain. Start by:
- Identify what open source licenses you are using
- Identify potentially problematic unlicensed or non-standard licenses
- Prune dependencies using unwanted licenses
And if you use open source components, don’t forget to support the open source communities.
Thanks for reading!
Top comments (1)
For anyone wanting some further reading, I find the recent discussions on Elastic's change from Apache-2.0 to Elastic licenses interesting reading (elastic.co/blog/elastic-license-v2 and many other discussions/articles).
Basically the move away from Apache-2.0 license addresses managed solutions of their product being offered to others (and this explains a bit of why Apache-2.0 licensed code is appealing to large businesses like Amazon AWS)