Adjusted OSS to open source as per normal project practice, adjusted intro to mention security, improved introduction, OpenChain certification description, OpenChain Project explanation, SPDX Project explanation, added table of contents, updated Reciprocal licenses section.
- Introduction
- Learning open source
- Receiving the benefits of open source
- Risks caused by failure to comply
- Supply chain issues
- Delivery of open source software
This leaflet is designed to help companies in the supply chain manage Open Source Software (open source). It was created by the OpenChain Japan Work Group and is maintained by the OpenChain Project global community. The OpenChain Project maintains OpenChain ISO/IEC 5230:2020 for open source license compliance and OpenChain ISO/IEC 18974:2023 for open source security assurance. These standards can help companies manage open source. You can learn more about the OpenChain Project and its standards at www.openchainproject.org.
Open source has become essential to modern software development and is incorporated into almost every electronic product, including supercomputers, cloud servers, personal computers, consumer electronics, automobiles, industrial equipment and IoT equipment. Open source is an indispensable part of helping companies to bring high quality products or services to market quickly under intense competition.
Much open source is developed through the collaboration of expert developers from different organizations throughout the world. Open source is often a vehicle for advanced innovation in various fields. Software engineers who participate in open source development have opportunities to improve their skills and to experience this innovation firsthand.
Open source can be used, modified, and distributed by anyone who complies with the associated license conditions. When open source is distributed, the distributor is required to comply with the terms and conditions of the license at the point in time when distribution occurs. There have been cases where distributors were sued and lost because they failed to satisfy their legal obligations. There are best practices to help prevent this happening.
By the same token, similar to all other software, security issues sometimes occur around open source. By managing open source it is possible to prevent and address many of these issues before they become a concern. The key thing is for all relevant personnel to have an understanding of the basic principles of open source.
This leaflet is licensed under CC0-1.0 (effectively public domain). You can use, share, study and alter it without restriction.
This pamphlet explains the following:
1． What is Open Source?
2． What you need to do to receive the benefits of open source
3． Risks associated with failure to comply with open source obligations
Unfortunately, there have been cases where a company’s failure to comply with their open source license obligations resulted in successful litigation by the copyright holder.
4． Supply chain issues
- What you need to do to ensure that everyone benefits from open source
Points 3 and 4 may be intertwined. If open source is acquired through a supply chain then all links in the supply chain must comply with the conditions of the license. If any link fails to satisfy the conditions of the license, then entities later in the supply chain will not be able to remedy the missing conditions. An employee or company acting alone cannot meet all the responsibilities and requirements by themselves.
When an item with open source software is delivered to another party, information related to all included open source must be provided. The following staff are required to know the proper procedures to follow when acquiring and distributing open source:
- Developers and engineers: In addition to software developers, hardware engineers are deeply involved in developing device driver software, board support packages (BSP) and software development kits (SDKs) for their hardware.
- Procurement personnel: Open source may be included in deliverables from the supply chain, such as software, hardware modules, SoCs, semiconductor products, and products designed and developed by ODM/OEM manufacturers.
- Sales personnel: Sales personnel are required to understand the reasons that customers need the open source-related information, including copyright and license information.
- Quality assurance personnel: Open source that is included in a product may affect its quality or introduce bugs. QA personnel need to be aware of such issues.
- Legal/Intellectual Property personnel: Legal and intellectual property personnel are required to know the laws, legal precedents, and legal remedies that relate to open source license interpretation and adherence.
- Executives and managers: Executives and managers develop strategy around using, contributing to, and distributing Open Source; build teams to promote open source usage; and oversee open source processes, and investment in required software tools.
- Security Personnel: Open source that is included in a product may be referenced in published security disclosures. Security personnel need to know the included open source that they can track exposure to any existing or newly-discovered vulnerabilies.
*ODM: Original Design Manufacturer OEM: Original Equipment Manufacturer
It is not easy to answer precisely “What is open source?”. Different people have different answers. However, most people would agree with the following:
Open source is software for which the source code is provided. And the copyright holder allows others to use, inspect, modify, and share the software.
Linux is probably the most widely known example of open source. An Operating System (OS) is software that is designed to provide a platform for other software. Linux is one such operating system. Linux is everywhere. It is incorporated into almost every major computing system, including supercomputers, stock exchange servers, Internet servers, smartphones using the Android software stack, consumer electronics products, automobiles, and industrial equipment. Linux supports a large portion of the world’s core technological infrastructure.
Linux has been developed through the collaboration of tens of thousands of developers from around the world. Linux development continues actively every day. Anyone can freely use, modify and distribute Linux, provided they abide by the conditions of the license that the Linux developers have chosen. It is very important that companies that use Linux understand and comply with the license terms for Linux.
In addition to Linux, there are a huge number of other open source projects. These include the Apache project used for HTTP servers, the widely used compiler GNU Compiler Collection (GCC), and the Eclipse integrated development environment, to name just a few.
A copyright holder of open source does not waive their copyright in the code, but grants users certain rights to the software based on the user’s adherence to the conditions of the software’s license. In some cases, a copyright holder may grant users a patent license. It is critical for users of open source to understand the license of each piece of open source they use.
Almost all open source licenses disclaim liability for open source developers. In almost all cases, the open source developers do not take responsibility for usage of open source; but require users, product integrators, and vendors to take this responsibility on themselves.
Not all software is covered by copyright. If you need to judge whether a particular piece of open source is copyrighted material or not, you should consult with a lawyer or intellectual property expert.
With some open source licenses, the copyright holder grants others the right to use or distribute the software. This license grant occurs without direct communication between the copyright holder and the user, but this right-of-use is only granted if the user adheres with conditions provided by the copyright holder in the license. When a user fails to comply with these license conditions, a serious issue arises.
With some open source licenses, the copyright holder of open source grants others the right to freely use the patents that are practiced by the software and owned by the copyright holder. Not every open source license grants such a patent license. Examples of licenses that include such patent grants are the Apache license, and the GNU General Public License (GPL) version 3.
The Open Source Initiative (OSI) is an organization that promotes open source. It defines the criteria for what constitutes open source and approves dozens of different licenses as valid open source licenses.
https://opensource.org/licenses https://opensource.org/osd
Most open source is licensed under an OSI-approved license. In addition, some software that is licensed under non-OSI-approved licenses may be treated as open source as well. Whether software should be treated as open source is usually determined by agreement between the software supplier and the recipient, potentially using the Open Source Definition (OSD), Free Software Definition (FSD) or similar.
When you use open source, the most important thing to know is your obligations related to distribution of the software.
Almost all open source licenses define the following:
- The open source developer disclaims liability for the effects of using the software
- Some obligations must be fulfilled when the software is distributed by an individual or legal entity (distributor).
In the following sections, a distributor can mean either an individual or a legal entity such as a company.
Anyone who complies with the conditions of the license may freely use and distribute the software.
However, the conditions differ from license to license. Some licenses require only that a license notice and a copyright notice be included in the source publication. Other licenses require the disclosure of the source code and a written offer to obtain it. Some licenses have terms that affect what other open source the first software may be used in combination with. A distributor is required to comply with all of the obligations defined in the license.
There are several different ways open source may be distributed. In every case, the distributor is required to comply with the open source license.
-
One way to distribute open source is to develop a product using an SDK (software development kit) provided by a semiconductor vendor. If open source that is included in the SDK is incorporated into a product during development, then this means that the semiconductor vendor is distributing open source via inclusion in the SDK, and the product developer is distributing open source via inclusion in the product. In this case, the product vendor has responsibilities to fulfill to comply with the license. But they are dependent on the semiconductor vendor. If the semiconductor vendor does not provide appropriate information about the open source included in the SDK, the product vendor cannot comply with the open source license.
-
Another way that open source might be distributed is when an ODM or OEM is entrusted with the design and development of a product for manufacturers. The ODM or OEM may incorporate open source into the product, which the product distributor needs to know about.
Even though an OEM or ODM made the product, the brand owner of the product distributes the open source incorporated into the product. The brand owner is required to comply with the open source license. If the ODM or OEM manufacturer does not provide appropriate information about open source, the brand owner of the product cannot comply with the open source license.
-
Other ways of distributing open source include shipping a product, releasing mobile application software, or providing an update of software for a previously shipped device.
If open source is included in a product, mobile application, or software update, this constitutes distribution of open source. The entity who ships the product or releases the software is required to comply with the open source license.
-
JavaScript used in web pages constitutes distribution:
An interesting case of open source distribution may occur when a web page is transferred to a user’s machine.
JavaScript that is included in web pages is transferred from the web server to the browser on the user’s machine, as part of the page data, when the user accesses the page. If the JavaScript program is open source, then this constitutes distribution and the license terms will apply.
The obligations that need to be fulfilled when open source is distributed vary from license to license. It is important to identify all of the open source and associated licenses in a product or program that is distributed.
This is required to clearly understand all the different license terms that must be satisfied.
The MIT license, the BSD license and the Apache license require few obligations. These licenses require the distribution of the software’s copyright notice and the license text. The notice should be clearly displayed in a place where the person receiving the open source can read it.
Reciprocal licenses like the GPL, the LGPL, the AGPL and the Mozilla Public License require disclosing the source code of software covered by their terms. They also require the distributor to disclose all source code modifications. This type of license is designed to create a situation where modifications and improvements can be shared by all users and developers of the software.
In addition to disclosure requirements, these licenses have other requirements to be met as well. For example, they also require that license and copyright information must not be removed from the source code. You must understand and follow the requirements of these licenses to distribute software covered by their terms. If needed, you should consult with your legal and intellectual property staff.
In some cases, an open source license may require a distributor to grant their users a license for patents embodied in the software that the distributor uses or adds to the open source. If you have such a patent, that you cannot grant your users a license to, you must not distribute open source covered by such license terms.
Litigation by an open source copyright holder against a company for failure to comply with the license has occurred.
Unfortunately, it has occurred that failure to comply with the open source license resulted in litigation against the user (and distributor) by the open source copyright holders. In at least one case, a judgement required the defendant to suspend the shipment of their products containing open source.
In December of 2009 there was a lawsuit related to Open Source software called “Busybox”. The Busybox program is widely incorporated into embedded systems and is licensed under the GPL version 2 license. In this case, 14 companies were the subject of the lawsuit, including some in the consumer electronics industry. The remarkable thing about this case was that companies suffered litigation on products that had been made by an ODM manufacturer.
In every case, it was the distributor’s failure to comply with the open source license that resulted in the litigation. To avoid litigation, an entity working with open source should:
- Identify every piece of open source in the software to be distributed
- Understand the obligations defined by the open source license, and comply with them.
When a company is litigated, one of the largest damages to the company is to its reputation (reputational risk). A bad reputation of not complying with software licenses may cause a company to lose the trust of other companies. The more that a company understands the importance of its trust relationships, and endeavors to build trust throughout its industry, the more serious that company is about avoiding risks to its reputation.
To respond to litigation requires a lot of work and expense. In the absence of litigation, the human resources involved in legal, procurement, engineering, and compliance could be used in more constructive tasks. This means that a company spending time responding to litigation might miss out on other business opportunities that those human resources could be working on. In particular, employing a competent lawyer for open source litigation is very expensive.
A settlement or a legal judgement may require payment of money or a fine. In the extreme, a judgement could result in the suspension of shipment of a product, which could be quite damaging and costly.
To reduce the risk of litigation, it is essential to understand open source principles and to comply with the obligations of the open source licenses. In addition, it is highly recommended to contribute to the open source community and to build good relationships with the developers of the open source that you use.
If you understand why the authors selected a specific Open Source license for their software, and the intent of the open source community that supports an open source project, it will help you move beyond just fulfilling the letter of the open source license. Understanding the intent of the developers is one of the most important benefits of having a good relationship with the open source community.
A good relationship with the open source community may enable a company to have its own new ideas adopted into the open source. The open source community may improve software based on your ideas and requirements. Also, engineers in your company may have the opportunity to collaborate with highly skilled open source developers, and this could result in more satisfaction and skill for your engineers.
As the system software increases in size and functionality, it becomes more and more complex. It is harder and harder to produce software without bugs. However, if a company has a good relationship with open source developers, the community may help your engineers find and resolve bugs, as the software is developed.
There are many ways to contribute to open source communities: proposing bugfixes and new features, translating documents, providing places and forums where community members can communicate, and sponsoring and participating in projects and trade associations that support open source, such as The Linux Foundation.
As software becomes larger and more complex, the supply chain for software also tends to become larger and more complex. A modern software supply chain may include an open source community, a software supplier, a semiconductor vendor that provides an SDK, and a final product vendor. If any member of a large and complex software supply chain fails to comply with license obligations or fails to provide the appropriate license information, it will cause a large impact to a vendor who is obligated to comply with the license (Figure 1). Compliance failure could result in product shipment being suspended. If the vendor does not know about the failure before shipping, the vendor may receive an inquiry regarding the failure from a copyright holder or a third party, which it cannot respond to.
However, if software compliance is managed appropriately in the upstream supply chain, these problems can be avoided. To facilitate compliance with open source licenses, all participants in the supply chain must do their duty, build trust throughout the supply chain, and communicate appropriate information regarding included software.
It is recommended that each company in the supply chain establish a program to ensure open source compliance. The OpenChain Project created ISO/IEC 5230:2020 to explain the key requirements of this type of program, and to make it clear that even small teams can address open source compliance cheaply and effectively. At its most basic level, ISO/IEC 5230:2020 helps a company check its compliance process and improve it where necessary based on 30 years of industry knowledge. Free self-certification is available on the OpenChain Project website and there are also options for third-party certification if a company or its customers require it.
When a supplier distributes software, the supplier is required to provide to each recipient the information that is needed to comply with the open source license. A recipient should review the data and files carefully and verify that they are accurate.
A software distributor may include software from multiple suppliers for a single product. In this case, the distributor is required to receive information about each open source component it receives, along with the software.
If information about an open source component is not received, such open source should not be incorporated into a product.
Software developers should manage, record and store the configuration of the software. This includes the following:
- open source and its license
- Linkage (e.g. libraries used by the software, dynamic or static linkage, etc.)
- Modifications. That is, the technical details of any modifications made to the software.
These items must be identified and listed. Any time the software configuration changes, the list should be updated. The license may change from one release of software to the next, for a particular project. It is recommended to create and manage the list so that each open source item is easily referenced and reviewed. Some licenses (for example, the GPL license) require a distributor to disclose the source code. It is highly recommended that source control management software is used to track the original source code and any changes to the source code.
Software procurement personnel must receive information about any open source in the incoming software, for software engineers to record. Open source may be included in software like the SDK provided by a semiconductor vendor.
Procurement personnel are required to pay attention to the software in all the different kinds of deliverables that the company receives.
Sales personnel are required to communicate with customers regarding open source. A customer may have special requirements related to the use of open source. For example, a company may have an open source policy that precludes it from using open source with specific licenses.
It is important for sales personnel to learn of customers’ requirements regarding open source, and communicate this information to internal software developers.
Cooperation with legal and intellectual property personnel is indispensable for understanding open source licenses. Legal and intellectual property personnel should review the licenses that govern the open source used by a company and advise developers as to its use:
- What approvals are needed for using open source? (In general, open source licenses disclaim liability for the developer of the software.)
- What is required in order to distribute the open source?
- Can the inclusion of open source cause a problem when the software is used by downstream recipients?
Using open source effectively and appropriately requires the cooperation of different staff inside a company.
Executives and managers may need to facilitate coordination between internal organizations and may decide to establish a dedicated team to manage open source-related issues. This includes investments in human resources, training, and development environments.
To ensure that everyone benefits from open source, people must know what information regarding open source must be provided with software deliverables.
This pamphlet has explained the importance of maintaining the list of open source and of complying with open source licenses.
What information regarding open source should be provided with software deliverables? This section explains the specific information that must be distributed with open source. Because the required information varies depending on business and company policy, please communicate with each recipient company for details.
When no open source is included in software deliverables, you should clearly communicate that “the deliverable does not include any open source” to recipients. The recipient may then act accordingly.
When open source is included in software deliverables, you must clearly identify such software, and its license. For example, the license may change between different versions of open source. The name and version of each open source component is indispensable information. For each component it is helpful to provide the download location or main project source site or web site for the software. This allows recipients to verify the information about the software, its version and license.
When the open source license requires the distributor to disclose source code, please provide the source code. The source code that is specifically required depends on the open source license. For example, version 3 of the GPL/LGPL 3 license requires that in addition to the source code for the software, you must also provide information needed to re install a modified binary based on the code.
The following information must be distributed with your deliverables that include open source.
- List of open source components
For each open source component:
- Information which identifies the software (version number, origin of the source code (for example, website URL) and how the software can be obtained)
- List of applicable licenses, and (if more than one) the license your company is distributing the open source under
- Any modifications you made to the software
For open source where the license requires the distributor to provide license and copyright notices:
- The actual license text and copyright notices
For open source where the license requires disclosure of source code:
- The required source code (In the case of GPL, in addition to the source code you must also provide the scripts used for generation of the executables created from the source)
In some cases, where an open source component itself includes a secondary piece of open source, you must provide information for the secondary open source component as well.
The preceding information is fairly general. One customer may require certain pieces of information, while a different customer may require other information instead. It is important to communicate with your customers regarding the pieces of information they require and the format of them.
SPDX (Software Package Data Exchange) is a project hosted by the Linux Foundation that has developed a standardized format for exchanging license information. The SPDX format was published as ISO/IEC 5962:2021 after many years as a de-facto industry standard. Anyone can use SPDX and it is highly recommended for use throughout the supply chain. Please find information about it at:
There are scanning tools that can detect open source in software packages and automatically generate some information. For example, the Fossology project hosted by the Linux Foundation has developed such a scanning tool. The Fossology tool is available under an open source license and can be freely used by anyone. There are also other scanning tools available, with commercial licenses. It is recommended to use tools such as these to verify open source licenses in software packages during development and before shipping.
Some scanning tools have the ability to generate reports based on the SPDX specification. These scanning tools are useful for generating information that can be directly included in the deliverables to a customer.
The OpenChain Project builds trust in open source by building business process standards, supporting reference material, services and a partner ecosystem. The result is that open source license compliance becomes more predictable, understandable and efficient for all participants in the software supply chain. The OpenChain Project is run by users of open source for the benefit of users of open source. It invites all parties to engage and participate in its activities.
https://www.openchainproject.org
The Linux Foundation is dedicated to building sustainable ecosystems around open source projects to accelerate technology development and industry adoption.
Founded in 2000, The Linux Foundation provides unparalleled support for open source communities through financial and intellectual resources, infrastructure, services, events, and training. Working together, The Linux Foundation and its projects form the most ambitious and successful investment in the creation of shared technology.
https://www.linuxfoundation.org/
Suppliers should be aware of and potentially include processes to address regulation from government such as the United State's White House Executive Order [1], the NTIA Minimum Requirements [2], the European Union's Cyber Resilience Act (CRA) [3] and the EU Product Liability Directive [4].
[2] https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
[3] https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
[4] https://single-market-economy.ec.europa.eu/single-market/goods/free-movement-sectors/liability-defective-products_en (2022 draft revision)