Open-Source Licensing Mistakes

Determining the kind of open-source license you should use for your software comes down to understanding what kinds of rights different types of licenses provide and how to comply with specific open-source licensing requirements.

This article explains what open-source licensing is and the different types of open-source licenses. It covers common open-source licensing mistakes and explains how to avoid them.

What Is Open-Source Licensing?

To be considered open source, software must fulfill certain criteria, including being licensed under an approved open-source license and containing accessible code that can be used, modified, or distributed based on the terms of the software's open-source license.

There are two main categories of open-source licenses: permissive and copyleft licenses.

With permissive licenses, you can do pretty much whatever you want with the software, including using it in proprietary products. Copyleft licenses require you to include the open-source code in any modified versions of the software that you distribute.

For example, the MIT, Apache 2.0, and BSD are permissive licenses that allow you to use open-source code in proprietary software and don't require you to share modifications while the GNU General Public License (GPL) and Affero General Public License (AGPL) are copyleft licenses that require you to license modified versions of distributed software under the same terms as the original source code.

If you are an open-source software developer, you'll want to take care to prevent common open-source licensing mistakes. Let's take a look at eight open-source licensing mistakes and how to avoid them.

8 Open-Source Licensing Mistakes and How to Avoid Them

Open-source licensing mistakes can harm your reputation, cause legal trouble, and lead to financial losses. Understanding how to avoid open-source licensing mistakes can help you save time and money otherwise spent rewriting software or dealing with lawsuits.

Here are eight open-source licensing mistakes and how to avoid them.

Mistake # 1: Not Getting a License

Without an open-source license, your software isn't technically open-source. The license is what gives other people permission to use, modify, and distribute your code. In addition, a license can help provide legal protection.

For instance, the short and sweet MIT gives users the rights to use, change, distribute, and sell the software without limitations and contains a liability disclaimer that explains that authors and copyright holders are not responsible for any harm that may befall a user as a result of accessing the software.

Maintaining an open-source license that is appropriate for your intended use is an essential part of working with open-source software.

For instance, if you want conditions on how your software is used, you will likely want a copyleft license. On the other hand, if you don't want restrictions on how the software is used-including in proprietary projects-you may prefer a permissive license.

Whichever license you choose, you should make sure it's approved by the Open Source Initiative (OSI). The OSI is a non-profit corporation that maintains the Open Source Definition as well as a list of open source licenses that have gone through the OSI's license review process. You can browse the list of licenses approved by the OSI here.

If you need help determining which license best suits your needs, you can use a site like choosealicense.com that explains what types of licenses work well for different situations.

Mistake # 2: Violating License Terms

The terms of an open source license can vary depending on the specific license and whether it is copyleft or permissive.

Licensing terms may require you to attribute authors, include a copy of the license in distributed software, or make changes to the license if you change the code.

For example, the Apache 2.0 open-source license states that distributed copies of the licensed software must include a copy of the full license text and that changes made to the software are documented in the copy of the license for the modified software.

To avoid violating terms (and facing potential legal issues and financial penalties), it's essential that you thoroughly read and understand the terms of the licenses for any open-source software you are working with.

Mistake # 3: Assuming Open Source Software Can Be Used for Commercial Purposes With No Restrictions

Some people mistakenly think that just because software is open source, it can be used for any objective-including commercial purposes-without restrictions, but that is not the case. Many copyleft open-source licenses have conditions on how the open-source software can be distributed.

For example, the GPLv3 open-source license requires developers who want to distribute open-source software to share the source code and to distribute derivative software under the same license.

If you want to use open-source software commercially-including in proprietary products-with less restrictions, you'll likely want to use a permissive open-source license, such as the MIT or Apache 2.0 license. While you can use a copyleft license for commercial purposes, you'll need to make sure that you comply with any conditions related to distribution.

Mistake #4: Not Providing the Source Code

Another big no-no in the open-source world is distributing open-source software without making the source code publicly available. To be considered open source, the software's source code must be accessible, among other requirements. Failure to supply the source code when required by the license can result in legal trouble.

For example, in 2008 the Free Software Foundation (FSF) brought its first lawsuit against a company for licensing violations when it sued Cisco for distributing GPL products without providing the source code. The FSF claimed that by violating the license terms that required the source code to be provided, Cisco was denying users their right to freely share and modify the software.

Cisco ended up settling with the FSF in 2009, agreeing to provide the source code, designate a director to ensure Cisco's compliance with software license requirements, notify users of their GPL rights, and make a financial contribution to the FSF.

You can provide the source code by creating a "LICENSE" file in a public repository that contains the full terms of the license and including the source code with the distributed software.

Mistake #5: Mixing Incompatible Licenses

Care should be taken when combining licenses, as you don't want to mix incompatible licenses. Typically, permissive licenses are compatible with each other and copyleft licenses.

However, certain strong copyleft licenses may be incompatible with one another. For example, GPLv2 and GPLv3 are incompatible as the licenses contain different terms and both licenses require extended programs to be under the original license.

GPLv3 includes a termination clause that calls for automatic termination of a user's rights under the license if they violate its terms, but provides for reinstatement of rights if the user stops violating the license.

In contrast, GPLv2 does not explicitly allow for rights to be reinstated after termination.

One example of a company that struggled with open-source license compatibility issues that resulted in a relicense is Facebook.

Prior to 2017, Facebook had licensed many of its open-source projects under the BSD + Patents license, causing contention in the open-source community. Many in the community felt that the added patent clause was too restrictive, and the license was not considered compatible with other licenses (such as Apache 2.0) due to the patent clause.

In 2017, Facebook engineering director Adam Wolff announced that the company would relicense its open-source projects React, Jest, Flow, and Immutable.js under the MIT license.

To avoid compatibility challenges that could lead to relicensing, be sure to review the terms of each license and check for compatibility issues before starting a project that contains software with different open-source licenses. You can find information about license compatibility on sites such as the GNU Operating System website, which maintains information about which licenses are compatible with the GPL.

Mistake #6: Not Training Your Team

You can run into trouble if your team doesn't understand open-source license requirements and the consequences of non-compliance. Implementing a team training program can help ensure that all developers understand how to comply with open source license rules.

You might also consider maintaining an Open Source Policy that describes how to use open-source software so that your staff are all on the same page.

For example, Citi's Free and Open Source Software Contribution Guidelines explains that free and open-source software (FOSS) projects must be approved by the company's Open Source Program Office (OSPO) and details how FOSS licenses are managed.

Additionally, it's not a bad idea to appoint someone on your team to regularly review your open-source software and licenses to make certain that everything is compliant.

Mistake #7: Not Attributing Authors

Many open-source licenses require you to give credit to the original author, include the full text of the original license, and include any copyright notices from the original license.

For example, the Apache 2.0 license requires developers to attribute authors when distributing copies of the software.

Be sure to read license terms carefully and comply with any attribution clauses.

Mistake #8: Not Using Automated Tools to Help Detect Issues

While you can rely on the human eye to check your open-source licenses and code for compliance issues, if you're dealing with complex code or larger projects you may be better off using automated scanning tools.

Automated tools such as FOSSA, FOSSology, Black Duck Software, and Mend SCA can be used to help you detect any potential issues with your open-source license.

For example, Fossa can help you ensure your software is updated and your open-source licenses are compliant.

If you're unsure of the potential legal implications of using certain licenses, consulting with a legal expert can help you determine best practices for your specific project.

Summary

Open-source licenses describe how open-source software can be used, modified, or shared.

Common types of open-source licenses include permissive and copyleft licenses.

Open-source license mistakes you want to avoid include:

• Not getting an open-source license
• Violating the terms of the open-source license
• Assuming open-source licenses can be used for commercial purposes without restrictions
• Not providing the source code when required by the license
• Combining incompatible licenses
• Not training your staff on how to comply with open-source license requirements
• Not using automated tools to help detect potential compliance issues

Following these tips can help you avoid common open-source licensing mistakes:

• Maintain an OSI-approved open-source license that is compatible with your needs
• Understand and abide by licensing terms
• Choose a license that allows commercial or proprietary use if needed
• Make the source code accessible if required by the license
• Ensure combined license types are compatible
• Train your team on how to comply with open-source license requirements
• Comply with attribution clauses
• Use automated scanning tools to help detect potential compliance issues