5 Open Source Licenses and Compliance Risks to Know About

What Is an Open Source License? 

The modern software development process involves reusing code. Rather than coding everything from scratch, teams reuse open source components that may include code snippets, functions, libraries, frameworks, and sometimes entire applications. 

The practice of reusing code facilitates rapid development. However, it is crucial to understand that software code comes with specific rights and obligations. Open source software may be provided free of charge, but it still has a license with binding terms and conditions. Even copying code snippets from a programming website might carry certain legal obligations.

There are many open source software licenses, each stipulating certain obligations and rights. License noncompliance can result in harsh penalties, and licensors can sue those violating the license. For example, noncompliance can result in being forced to publish the source code. 

Organizations can protect their code only if they understand an open source license before reusing any code, including frameworks and libraries.

This is part of a series of articles about DevSecOps.

In this article:

• 5 Popular Open Source Licenses
• MIT License
• Apache License 2.0
• GPL License
• Microsoft Public Licenses (Ms-PL)
• MPL-2.0 License
• Open Source License Compliance Risks
• Open Source License Scanning

5 Popular Open Source Licenses

MIT License

The MIT License is a highly permissive open source license, allowing you to do anything with the software provided that you: 

• Include the original copyright and license notice in the software copy. 

You can easily integrate it into software, including copyleft licenses, as it has few restrictions on how to reuse the software and is also simple to understand. As a result, it has become one of the most commonly used licenses in open source projects.

Apache License 2.0

This permissive open source license allows you to do anything you want with the software, provided you: 

• Include the original copyright and license notice, and
• State all significant changes, and
• Include the NOTICE file if one exists. 

These exceptions mean the Apache License 2.0 is slightly less permissive than the MIT License, but it is still used widely.

GPL License

The GNU General Public License (GPL) is the most popular copyleft license for open source software. When writing software using a GPL component, you must:

• Release your entire source code, and 
• Give your users the same GPL rights you have received. 

The GPL aims to protect open source software from becoming private or proprietary, making it highly popular amongst programmers. GPL restrictions help ensure the original work remains acknowledged and free.

Microsoft Public Licenses (Ms-PL)

The Ms-PL is a free open source license created by Microsoft for the company’s open source projects. It allows you to reproduce and distribute derivative or original works of software licensed under this license, provided you: 

• Do not use the contributors’ names, trademarks, or logos. 

The Ms-PL aims to protect the project’s authors. In addition to prohibiting the above, it does not provide any express guarantees or warranties for using your code. It means the author is not liable if the code does not work well in all cases.

Here are the limitations related to the distribution of code:

• You can distribute the software (or a portion of the code) without distributing the source code. However, you must retain all patent, copyright, trademark, and attribution notices originally present in the software.
• You can distribute the software (or a portion of the code) in its source code form only under the Ms-PL and include a complete copy of the license with your distribution. 
• Distributing the software (or a portion of the code) in its object code or compiled form is allowed only under licenses compliant with the Ms-PL.

MPL-2.0 License

The Mozilla Public License 2.0 (MPL) is a copyleft license by the Mozilla Foundation. This copyleft license requires you to: 

• Include the original software copy, and 
• All modified files that contain MPL code. 

The MPL is compatible with the GNU licenses, which means MPL files are dual licenses, and you can decide how to distribute them.

Open Source License Compliance Risks and How to Avoid Them

Here are some of the main risks associated with open source licenses: 

• Misunderstanding license obligations—a common mistake is to assume that open source software has no restrictions. However, while the software license is free, you must acknowledge and comply with its requirements.
• Legal consequences—failing to comply with the license terms is a breach of your legal obligations. Competitors can exploit non-compliance to damage your business’s reputation, slow down projects, or cost you money. 
• Security risks—unknowingly using vulnerable or dependent software also carries risks. You must understand the technologies supporting your project to avoid introducing flaws.

Ask the following questions to avoid open source license compliance issues:

• What components are you introducing to the software? Make sure they are open source. 
• What licenses and requirements apply to the code you use? Ensure you understand the software licenses and terms for all dependencies. 
• How can you ensure compliance without impacting other business objectives? 

Here are some tips for avoiding compliance issues: 

• Meeting compliance requirements—use a detailed license compliance checklist to verify that you’ve completed all compliance actions before releasing the product.
• Providing the correct source code version—add verification processes to ensure the version of the source code you publish matches the distributed binary.
• Releasing modifications to open source components in the product—use tools to identify changes to software components. Ensure you always use the newest version of each component and register updates in the compliance process. Incorporate source code modifications into the checklist before release. 
• Marking modified code—inspect your source code before each release and ensure that all changes to source code are marked and have a description before release. The compliance process should include a milestone to verify modification marking. Train employees to update source code change logs during development.

Related content: Read our guide to DevOps security (coming soon)

Open Source License Scanning 

The need to identify open source licenses

A typical open source project has an overarching license, which might not apply to all individual files or lines of code within a file. Licensing can quickly become complex as the project grows and evolves, accumulating many contributions from thousands of sources. 

Some open source software projects allow any contribution under an open source license, even if it differs from the overall project’s license. The team might not assess the licenses of new contributions, or the leaders have decided to accept contributions under different, compatible licenses to facilitate collaboration and sharing across projects. 

The result is that individual pieces of code can have different licenses from the project. Even a project that requires all inbound contributions to have the same license carries the risk that contributors might make mistakes and incorporate code under an incompatible license. These licensing issues could impact the project downstream. 

How scanning helps address licensing issues

A source code scanner can prevent downstream licensing problems by comparing the project’s source code to the available code in public repositories. It identifies potential code matches and notifies you of the license terms applicable to each match. The scanning tool tells you when the team allows incompatibly licensed code to enter the project. 

Scans may be periodic (for instance, monthly or quarterly) or occur at specific compliance checkpoints, such as whenever the team is about to release a new update. Some open source scanning tools can automatically scan code while you build the application, ensuring compliance during the development process.