There are several key points that a large enterprise should consider to ensure compliance with open-source license obligations:
- 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.
- 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.
- 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.
- Legal review: It is important to have a qualified legal professional review the open-source licenses and obligations to ensure compliance.
- 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
License Checker which is an NPM module you can use in node projects to list the licenses used by the project.
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.
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
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:
- 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.
- 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.
- Corporate open-source policy: Your organization may have its own open-source policy that specifies which licenses are acceptable for use in your software.
- 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
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.
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.
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
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."
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."
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."
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.
Open Source Licensing Basics for Software Developers
This course is designed for developers who utilize open source code.
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.
TLDR Legal: a web resource that provides plain-English summaries of various software licenses, helping developers and project managers understand the legal terms without having to interpret dense legal language.
OpenChain: an ISO standard for open source license compliance, developed and hosted by the Linux Foundation. It provides a set of requirements to create effective open source management systems, helping companies to minimize legal risks related to open source software use and improve efficiency and trust in the software supply chain.
The 8 Best Free and Open Source License Management Software. Opinionated discussion of what to look for in license management tooling.
The Legal Side of Open Source. A very basic introduction on why open source software needs a license.
Open Source Software: A Legal Guide. Documentation aimed at legal teams to explain their responsibilities towards open source.
A Developer's Guide To Open Source Licenses. Delves into the details of what developers need to know about licenses.
FINOS License Categories. How licenses are categorized for the FINOS Foundation.