Skip to main content

License Compliance Management

There are several key points that a large enterprise should consider to ensure compliance with open-source license obligations:

  1. License identification: The first step is to identify the open-source licenses used in your products and understand the terms and conditions associated with each license.
  2. License compatibility: It is important to ensure that the licenses of the open-source components used in your products are compatible with each other and with your own licenses.
  3. License obligations: Each open-source license has its own obligations, such as the requirement to distribute source code, include a copyright notice, or provide a copy of the license.
  4. Legal review: It is important to have a qualified legal professional review the open-source licenses and obligations to ensure compliance.
  5. Employee education: The enterprise should educate its employees on the importance of compliance with open-source licenses and the obligations associated with each license.

See Also: Licenses describes what software licenses are.

1. License Identification​

For Individual Software Projects

For Individual Software Projects

Individual software projects often include direct and transitive dependencies on other pieces of open source software.  There are plenty of tools for cataloguing licenses being used:

  1. Scancode, recommended here: https://softwarerecs.stackexchange.com/questions/40068/tools-to-scan-code-for-open-source-licenses-and-copyrights

  2. License Checker which is an NPM module you can use in node projects to list the licenses used by the project.

  3. FINOS' Security Scanning project provides GitHub Actions which will report licenses on Java (Maven), Node and Python projects via the use of license-maven-plugin, node-license-validator and pip-licenses respectively.

It is expected that developers would set up these tools to run on the CI/CD pipeline of their projects and generate license reports every time a build is run.

Developer Role Details

Across an Estate

Across an Estate

Where an organisation is running and managing many projects at once, setting up license scanning on a per-project basis isn't really effective.  Part of the problem is that all the tools listed above have their own output formats.  

Instead, you need tools that will scan open source projects wherever they come from and produce a report in a standard format.  This is called a Software Bill of Materials (SBOM).  There are various tools you can use to identify licenses across an estate of projects such as:

  • OSS Review Toolkit (ORT). An open source Linux Foundation project for automating many parts of open source project review.
  • FOSSA is an open-source license compliance and vulnerability management platform.
  • Mend is a security-focused open-source scanning tool that helps developers detect and remediate vulnerabilities in their code using machine learning.
  • Snyk is a cloud-based platform that helps developers and security teams manage open-source dependencies by identifying and fixing vulnerabilities in real-time

OSPO Role Details

License Identifiers​

As described in the License article, most open source software is licensed under one of a limited number of common licenses, such as the Apache 2.0 License, MIT License and BSD License.

Each of these de-facto standard licenses has an associated SPDX Identifier. For example, the SPDX identifier "Apache-2.0" refers to the Apache 2.0 License.

2. License Compatibility​

Determining the compatibility of licenses involves evaluating the terms and conditions of the licenses used in your software to determine whether they are compatible with each other and with your organization's open-source policy.

There are several factors to consider when determining the compatibility of licenses, including:

  1. License conditions: Some licenses have conditions, such as copyleft or patent retaliation clauses, that must be followed in order for the license to be considered compatible.
  2. License compatibility: Some licenses are designed to be compatible with each other, while others are not. For example, the GPL license is considered to be incompatible with many other licenses, while the Apache license is considered to be more compatible.
  3. Corporate open-source policy: Your organization may have its own open-source policy that specifies which licenses are acceptable for use in your software.
  4. Legal considerations: Some licenses may have legal implications for your organization, such as the potential for patent infringement or the requirement to provide source code.

By evaluating these factors, you can determine the compatibility of the licenses used in your software and establish a policy for compatible and incompatible licenses. It's important to seek the advice of a legal expert if you are unsure about the compatibility of a particular license.

3. License Obligations​

Please review the License article in particular the section on License Obligations.

4. Legal Review / License Policy​

Having established which licenses are used by your organisation and the obligations of those licenses, you need to categorize these licenses to account for when and where (if at all) they should be used.

It's important to document the findings of the legal review, including any recommendations for using or avoiding the software based on its license. This documentation can be used to inform decision-making and to ensure that your organization remains in compliance with open source licenses.

Categorizing Licenses

Categorizing Licenses

Legally reviewing an open source license involves evaluating the terms and conditions of the license to determine its legal implications for your organization.

Open source licenses may have legal implications for your organization, such as potential liability for patent infringement, the requirement to make source code available, or the potential for intellectual property disputes. During the review process, it's important to consider any legal implications of the license and to seek the advice of a legal expert if necessary.

Context​

Note: what consitutes an acceptable license depends on the software, the license and the context it is used in. You might need to set up different categories for use in different places. For example:

  • Allowed for internal development
  • Allowed for distribution within proprietary products (e.g. public websites)
  • Allowed for internal publication
  • Allowed for external publication

FINOS Categories​

As an example of the license categorization exercise, the FINOS Foundation creates 3 categories of license:

Category A: Public Domain Licenses​

"Code licensed under the following licenses (and public domain dedications) may be included in Foundation contributions. If the license requires attribution or other notices, these should be included in the project's NOTICE file."

This category contains many of the common permissive open source licenses, such as MIT, Apache 2.0 and BSD.

Category B: Allowed, but Restrictive​

"Third-party code licensed under the following licenses may be included in Foundation projects. However, because these licenses contain certain restrictions on downstream users (such as a reciprocal licensing requirement), a notice must be included in the project's CONTRIBUTING file if the third-party code appears directly in the project's repository."

This category is more nuanced and contains things like Mozilla Public License and Eclipse Public License.

Category X: Excluded​

"Category X dependencies are excluded either because their licenses would not permit the Foundation project to be licensed under the Apache License, or because they contain other problematic terms. Category X licenses include any proprietary license or EULA, as well as many free and open source software licenses with reciprocal licensing requirements and other restrictions."

This includes CopyLeft licenses like GPL and AGPL.

5. Employee Education​

Using the correct licenses will form part of License Policy and it will be necessary to ensure developers in your organisation are aware of the limitations around the use of open source.  Although these limitations will vary from firm-to-firm, the Linux Foundation provides several training courses suitable for orienting developers on their responsibilities relating to open source licensing:

Introduction to Open Source License Compliance Management

This course is intended for developers, project managers and executive decision makers who already know the basics of what open source software is and how copyrights work and are ready to take the next step towards building a formal compliance program for their organization.

Implementing Open Source License Compliance Management

This course is intended for software developers, project managers, legal associates, and executive decision makers who already know the basics of what open source software is and how copyrights work, and are ready to take the next step towards building a formal compliance program for their organization.

Final Points to Consider​

  • The enterprise should have a process in place for tracking open-source components, monitoring license changes, and ensuring compliance with all license obligations.  That is, it is important that license management is performed continually:  dependencies can change license, projects can take on new dependencies, risk appetite can change.
  • Cataloguing the usage of third-party open source software should be done as part of Software Composition Analysis and so license usage should be considered part of this analysis.

Further Reading​