Software licensing is a crucial component of the software industry, governing the terms and conditions under which software can be used, modified, and distributed. Software licenses can vary widely in terms, restrictions, and permissions. Understanding the different types of software licenses is essential for anyone involved in software development or distribution.
Example license for Jenkins automation server.
In this blog post, we will explore the most common types of software licenses, including open source licenses and closed source licenses, and their implications for your software supply chain and policy management. By the end of this post, you will better understand the different types of software licenses and how they can impact the development and distribution of software.
Open source licenses
While many different open source licenses exist, their requirements fall under two broad categories: “permissive” and “copyleft.”
A permissive license allows developers and organizations to use, modify, and distribute software with few restrictions. These licenses are a popular choice among organizations looking to sell software. They enable developers to create and innovate while allowing organizations to keep their software proprietary and monetize it.
However, it's important to note that although the term 'permissive' suggests leniency, failure to comply with the legal obligations of these licenses can still result in serious consequences. These include expensive lawsuits, publication of proprietary software, and loss of business.
Examples of permissive licenses include the Berkeley Software Distribution (BSD) and the Massachusetts Institute of Technology (MIT) license. BSD licenses were originally 4-clause licenses; however, BSD licenses can now have 0–4 clauses. The MIT License was originally developed for X Window System in the 1980s, and is now one of the most popular open source software (OSS) licenses available.
While these licenses more generally address “attribution” or giving the author credit for their work, some have no legal obligations. These are the “zero clause” licenses, including the BSD 0-clause and MIT “No Attribution,” which behave the same as those in the public domain.
Public domain OSS is free to use and is not owned by any organization. While anyone can use the software in the public domain, users assume all risks of the software. So it’s important to continue other security measures.
Examples of public domain software licenses include CC0 (Creative Commons Zero).
Copyleft and weak copyleft
A protective license with clear restrictions, copyleft requires anyone distributing the software to make the source code available. A reciprocal license is another term that describes copyleft licenses like the General Public License (GPL) or Affero General Public License (AGPL). This is because Copyleft licenses like GPL require any derivative works or modifications to be released under the same license as the original software.
Anyone who uses or modifies software with a GPL license must also share their changes and improvements with the wider community. Put simply, a GPL license can spawn more GPL licenses. It is important to note that the reciprocal nature of these licenses is intentional and aims to promote the sharing and free distribution of software.
The GPL’s concept of sharing software code changes has been suggested as a driving force behind the success of Linux. However, because numerous organizations have included GPL-licensed software commercial hardware and software, they have been required to share intellectual property, including source code. As a result, Sonatype’s license policy standards has pre-set the strictest of these licenses as “Banned” so components containing strong copyleft licenses will not make it into production.
Within the copyleft license category, there is a so-called weak copyleft license. These licenses have fewer restrictions, allowing the linking of original software without requiring your software to be released under the same license. While the changes to the original software must still use the same license, the rest of the software can be released under a different license. This makes using the original software in proprietary projects easier than standard copyleft.
For example, Beerware is a term used to describe a software license based on the "beer-buying" tradition in some cultures. This means if you ever meet in person, you need to buy the owner of the component a beer. Oftentimes these licenses, like the WTFPL, aim to poke fun at other copyleft or permissive licenses.
Closed source licenses
A type of software license that contains non-open source terms, often requiring payment for the use of the software. Some additional requirements of commercials include a right to audit the licensee and forbid any modifications or de-compilation, which is the process of reverting machine-executable code into source code.
Non-commercial/forbidden right to use
A non-commercial license prohibits using the software for commercial purposes, meaning it cannot be used to generate any profits or revenue. An example would be the Creative Commons non-commercial license. Non-commercial licenses can be permissive or copyleft, but may not be used for any business purposes.
Note that while the Creative Commons project recommends against their use for software, it remains common due to its popularity.
Forbidden right to use is a license that blocks use by some industries. For example, the Apple Public Source License 1.0 forbids it to be used in any company associated with nuclear facilities.
These are not licenses your organization would run into on any given day. A proprietary software license is not publicly available and is only used through a private agreement.
How do I manage all these software licenses?
In the early days of open source, following license terms was easy. However, as software has grown, projects contain upwards of 260 dependencies on average, making even basic licenses difficult to manage.
With thousands of licenses across various categories, understanding, cataloging, and meeting all the license requirements may seem like a monumental task. You may even wonder if it’s time to forgo open source software altogether. But with the right tools, open source software can be a competitive edge, helping you innovate and grow.
License management with Sonatype Lifecycle and Advanced Legal Pack
With the Advanced Legal Pack (ALP) add-on, Sonatype Lifecycle provides efficient license management through extended legal data and legal workflow automation. Thousands of licenses are cataloged and pre-set into license eight default “Threat Groups” ranging from “Banned” to “Liberal” to help DevSecOps teams manage legal risk.
Threat groups listing inside Sonatype’s ALP software.
The usage of all software, regardless of license, is up to the organization's discretion. Sonatype’s ALP does have default license threat groups to help guide your policy management. License status can be customized to enforce the usage of components with licenses that suit the needs of their software.
As the industry becomes more regulated, not complying with licenses could have serious consequences. The ALP saves developers and legal reviewers time and rework and generates reports to help you fulfill your license obligations for both attribution and weak copyleft. Without it, your organization could face a lot of manual work, inconsistent policy, and legal complications.
Discover the full potential of Advanced Legal Pack by diving deeper into its features and benefits. Take the next step towards optimizing your development process by requesting a personalized demo today.