Synopsys analyzes the details of mainstream custom open source licenses and variant versions

How much do you know about the software you develop? Do you have information about the open source components? What licenses are used and are they compliant?

Open source code is so ingrained in modern software development that even code owners often don't know what open source components are included in their software. Therefore, the importance of open source auditing has become increasingly prominent. Among them, the issue of open source license conflicts has received more and more attention. Synopsys points out that with open source auditing, enterprises can obtain a complete and accurate software bill of materials (SBOM) for open source and third-party software. This provides developers with insights into licenses, vulnerabilities, and the vitality of various components.

Synopsys' Black Duck audit services team analyzed the results of more than 1,700 audits of commercial and proprietary code bases involved in M&A transactions and released the 2023 Open Source Security and Risk Analysis (OSSRA) report. 96% of the codebases audited contained open source code, and 54% contained license conflicts.

Fu Hongxun, director of software application security technology at Synopsys China, noted: "In addition to establishing a comprehensive SBOM, the Black Duck audit services team is also responsible for identifying licenses and prioritizing components for legal review. Legal review requires no investment Too much time is spent on common standard loose open source licenses, and license conflicts need to be reviewed first. However, license conflicts are not the only items that require legal review. Enterprises also need to study the fine print of open source licenses and variant versions.”

Custom open source licenses and variant versions

In approximately 30% of code bases audited by Synopsys (and 70% of M&A transactions), code was found to have a one-time license, a custom variation of a standard license, or no license at all. Components are marked as "unlicensed" when the source of a component can be identified - a repository or website - but no license or terms of use are found at that location or in the code.

Variants of the standard license can be tricky, as they may be considered MIT or BSD licenses, etc. But closer inspection often reveals that developers have taken it upon themselves to add their own ideas to the standard.

JSON license

The most common variant is the JSON license, where the MIT license adds the annotation "This software is strictly prohibited for malicious purposes and can only be used for good intentions." The Apache Software Foundation has suspended the use of JSON-licensed code due to the ambiguity of such terms.

There are even variations of the JSON license. In this variant, the following note is added to the license: "If you are notified in writing that you have not complied with the Code of Conduct, you will need to take appropriate action within 30 days to continue using the license; otherwise your license will be terminated immediately termination."

Commons Clause License Variants

The Commons Clause is a variation that seeks to modify the standard open source license to restrict commercial use of the software. An excerpt reads: "...the license does not give you the right to sell the software." At first glance, software covered by a license such as the Apache License might be rendered completely unusable by this clause.

Proprietary and commercial licenses

It's not uncommon for code bases to contain content from third-party commercial software companies. Open source audits often uncover copyrights from Adobe, Microsoft, Oracle and other companies. As part of software due diligence, it is necessary for the acquirer to check that appropriate licenses are in place and disclosed. Even if the permission is justified, lawyers will want to ensure that the change of control does not introduce any risks in the future.

Dual licensing

More and more companies are using dual licensing, which is a clever business model. Software is made available to developers under an open source license, but at the same time the license contains obligations that make it difficult to use for commercial purposes.

The AGPL license often comes up in this situation: most companies can't use AGPL-licensed code in their products (there are other licenses that more explicitly prohibit commercial use without a commercial license). If a developer uses code licensed under the AGPL, the company needs to sign a commercial license with the supplier for the same code.

When an open source audit uncovers dually licensed software, staff will highlight this so the acquirer can ensure the target company is properly licensed.

Understand what's in the code

A complete understanding of whether code is properly licensed requires an accurate and complete bill of materials, as well as an analysis of possible conflicts between the intended use and the included open source license. There are other licensing issues beyond standard open source that require deeper research and more legal scrutiny. Importantly, as part of software due diligence, open source audits can trace license information to facilitate expert IP lawyers in assessing the risks in their clients’ specific situations.