Licensing assessment in Tech Due Diligence: MIT vs GPL vs LGPl vs AGPL vs Mozilla (MPL) vs Apache vs BSD

In today’s software landscape, open-source software (OSS) has become an integral part of development practices, offering developers access to a vast array of libraries, frameworks, and tools. However, using open-source code comes with legal obligations, specifically in terms of licensing. Properly managing software licenses is crucial for avoiding legal risks and ensuring compliance during technology due diligence. This blog post explores the types of licenses in code, the importance of license assessments in due diligence, and key considerations like permissive vs. restrictive licenses and special clauses.

Types of Licenses in Code

When it comes to software licenses, there are two main categories: open-source licenses and proprietary licenses. Open-source licenses give developers the freedom to use, modify, and distribute code, but each license comes with its own set of rules. Proprietary licenses, on the other hand, generally restrict usage and modification, and software under such licenses must be purchased or licensed directly from the owner.

Open-source licenses can be further divided into permissive and restrictive licenses, each having different implications for businesses and developers. Choosing the right license impacts how your code can be used and redistributed, making it a critical factor during any tech due diligence process.

License Assessment in Code Assessment and Due Diligence

When conducting technology due diligence—whether for mergers, acquisitions, investments, or partnerships—assessing the software’s legal compliance is vital. Part of this process involves a license assessment, where you evaluate all software components and their associated licenses.

A license assessment helps to identify potential risks that come from using software governed by restrictive licenses, which may impose obligations such as releasing proprietary code when it interacts with open-source components. It’s also important to ensure that the company is compliant with all licenses and is not violating any terms, which could lead to costly legal disputes down the road.

License assessments usually involve:

• Inventorying all third-party software used in the product, including libraries and tools, you can rely on a Software Bill of Materials (SBOM) to handle inventorying.
• Checking license compliance to ensure all obligations, such as attribution or redistribution clauses, are met.
• Evaluating future risks such as viral licenses that may force open-sourcing of proprietary code.

Permissive vs. Restrictive Licenses

Understanding the differences between permissive and restrictive licenses is key when choosing what licenses to use or review during due diligence.

Permissive Licenses

Permissive licenses, such as the MIT License and the Apache License 2.0, allow developers to use, modify, and redistribute code with minimal restrictions. These licenses are favored because they provide flexibility and encourage innovation by allowing developers to integrate open-source components into proprietary software without any major obligations.

For example, the MIT License only requires that the original copyright notice and license terms be included in any distribution of the software, whether the software is modified or not. The Apache License 2.0 adds provisions for patent rights but remains permissive, requiring attribution and documentation of any modifications.

Restrictive Licenses

Restrictive licenses impose more obligations on the use and distribution of software. The most notable examples are the GNU General Public License (GPL) and its variants like LGPL and AGPL.

• GPL (General Public License): The GPL is a copyleft license, which means that any derivative works or software that links to GPL-licensed code must also be released under the GPL. This “viral” nature is why many companies are cautious when using GPL-licensed components.
• LGPL (Lesser General Public License): LGPL is slightly more lenient, allowing the use of LGPL-licensed libraries in proprietary software, provided that the library itself remains open-source.
• AGPL (Affero General Public License): AGPL extends the GPL’s reach to network-distributed software, meaning if you modify AGPL software and make it available over a network, you must release the source code to users. This can be particularly restrictive for SaaS companies.

For tech due diligence, it’s essential to distinguish between permissive and restrictive licenses, as the latter can create legal obligations that may not align with business models, especially for proprietary or SaaS products.

DON’T

Don’t use restrictive licenses in commercial products, specially in distributable products and frontends, unless you comply with the license terms.

What might go wrong if open-source license terms are violated? The Artifex Software vs. Hancom Inc.

The Artifex Software vs. Hancom Inc. lawsuit is a notable case in open-source software licensing. Artifex, the developer of Ghostscript, an open-source PDF and PostScript rendering tool, sued Hancom, a South Korean software company, in 2016 for violating the terms of the GPL (General Public License). Hancom had integrated Ghostscript into its office suite without purchasing a commercial license or complying with the GPL’s requirement to release their source code. After ignoring Artifex’s cease-and-desist letter, Hancom was sued for copyright infringement and breach of contract. The U.S. District Court in California ruled that the GPL was legally enforceable, and Hancom settled the case out of court in 2017. This lawsuit highlighted the importance of adhering to open-source license terms and served as a warning to companies using open-source software without proper compliance.

Special Clauses in Licensing (Common Clause, etc.)

In recent years, new types of licenses have emerged, introducing special clauses to address modern use cases. One example is the Common Clause, which modifies existing open-source licenses to prohibit commercial use of the software without explicit permission. While the Common Clause aims to protect developers from exploitation by large corporations, it has sparked debates over whether software governed by this clause can truly be considered open-source.

Another example is patent retaliation clauses, found in licenses like Apache 2.0, which prevent users from initiating patent litigation based on the licensed software. These clauses offer legal protection for the original developers and must be carefully considered when assessing the overall risk profile of a software stack.

Conclusion

Licensing is a crucial part of technology due diligence, particularly in the age of open-source software. Choosing the right licenses and understanding the obligations they entail can make or break a business deal. Permissive licenses like MIT and Apache provide flexibility, while restrictive licenses like GPL and AGPL can impose significant legal requirements. Special clauses like the Common Clause and patent retaliation clauses add complexity to license management, making it essential to conduct thorough license assessments as part of your due diligence efforts.

Did you know?

Codenteam AI identifies all licenses used by your code depdenendies, you can see it in the report and discuss with the AI why it marked it as such.

Understanding the intricacies of software licensing not only protects against legal risks but also ensures that the technology stack is aligned with the company’s business objectives and future scalability.