A discussion of open-source compliance, the challenges faced when establishing a compliance program, an overview of best practices and recommendations on how to deal with compliance inquiries.
Traditionally, platforms and software stacks were built using proprietary software and consisted of various software building blocks that came from different companies with negotiated licensing terms. The business environment was predictable, and potential risks were mitigated through license and contract negotiations with the software vendors. In time, companies started to incorporate open-source software in their platforms for the different advantages it offers (technical merit, time to market, access to source code, customization and so on). With the introduction of open-source software to what once were purely proprietary software stacks, the business environment diverged from familiar territory and corporate comfort zones (Figure 1). Open-source software licenses are not negotiated agreements. No contracts are signed with software providers (that is, open-source developers). Companies now must deal with dozens of different licenses and hundreds or even thousands of licensors and contributors. As a result, the risks that used to be managed through license negotiations now must be managed through compliance and engineering practices.
Figure 1. A new computing environment necessitates open-source compliance due diligence.
Open-source software initiatives provide companies with a vehicle to accelerate innovation through collaboration with a global community of open-source developers. However, accompanying the benefits of teaming with the Open Source community are very important responsibilities. Companies must ensure compliance with applicable open-source license obligations. Open-source compliance means that open-source software users must observe all copyright notices and satisfy all license obligations for the open-source software they use. In addition, companies using open-source software in commercial products, while complying with the terms of open-source licenses, want to protect their intellectual property and that of third-party suppliers from unintended disclosure.
Open-source compliance involves establishing a clean baseline for the software stack or platform code and then maintaining that clean baseline as features and functionalities are added.
Failure to comply with open-source license obligations can result in the following:
Companies paying possibly large sums of money for breach of open-source licenses.
Companies being forced by third parties to block product shipment and do product recalls.
Companies being mandated by courts to establish a more rigorous open-source compliance program and appoint an “Open-Source Compliance Officer” to monitor and ensure compliance with open-source licenses.
Companies losing their product differentiation and intellectual property rights protection when required to release source code (and perceived trade secrets) to the Open Source community and effectively license it to competitors royalty-free.
Companies suffering negative press and unwanted public scrutiny as well as damaged relationships with customers, suppliers and the Open Source community.
There are three main lessons to learn from the open-source compliance infringement cases that have been made public to date:
Ensure that your company has an open-source management infrastructure in place. Open-source compliance is not just a legal exercise or merely checking a box. All facets of a company typically are involved in ensuring proper compliance and contributing to the end-to-end management of open-source software.
Make open-source compliance a priority before a product ships. Companies must establish and maintain consistent open-source compliance policies and procedures and ensure that open-source license(s) and proprietary license(s) amicably coexist well before shipment.
Create and maintain a good relationship with the Open Source community. The community provides source code, technical support, testing, documentation and so on. Respecting the licenses of the open-source components you use is the minimum you can do in return.
Companies face several challenges as they start creating the compliance infrastructure needed to manage their open-source software consumption. The most common challenges include:
Achieving the right balance between processes and meeting product shipment deadlines. Processes are important; however, they have to be light and efficient, so they're not regarded as an overhead to the development process and to avoid making engineers spend too much time on compliance activities.
Think long term and execute short term: the priority of all companies is shipping products on time, while also building and expanding their internal open-source compliance infrastructure. Therefore, expect to build your compliance infrastructure as you go, doing it the right way and keeping scalability in mind for future activities and products.
Establish a clean software baseline. This is usually an intensive activity over a period of time. The results of the initial compliance activities include a complete software inventory that identifies all open-source software in the baseline, a resolution of all issues related to mixing proprietary and open-source code, and a plan for fulfilling the license obligations for all the open-source software.
Here are the essential building blocks of an open-source compliance infrastructure required to enable open-source compliance efforts (Figure 2):
Figure 2. Open-Source Compliance Building Blocks
Open-source review board (OSRB): comprises representatives from engineering, legal and open-source experts. The OSRB reviews requests for use, modification and distribution of open-source software and determines approval. In addition, the OSRB serves as a steering committee to define and manage your company's open-source strategy.
Open-source compliance policy: typically covers usage, auditing and post-compliance activities, such as meeting license obligations and distribution of open-source software. Usual items mandated in a compliance policy are approval of OSRB for each piece of open-source software included in a product, ensuring that license obligations are fulfilled prior to customer receipt, mandatory source code audits, mandatory legal review and the process and mechanics of distribution.
Open-source compliance process: the work flow through which a request to use an open-source component goes before receiving approval, including scanning code, identifying and resolving any flagged issues, legal review and the final decision. See HP's “FOSS Management Issues” article at www.fsf.org/licensing/compliance for an example of a compliance process.
Compliance project management tool: some companies use bug-tracking tools that already were in place, and other companies rely on professional project management tools. Whatever your preference is, the tool should reflect the work flow of your compliance process, allowing you to move compliance tickets from one phase of the process to another, providing task and resource management, time tracking, e-mail notifications, project statistics and reporting.
Open-source inventory management: it is critical to know what open-source software is included for each product, including version numbers, licensing information, compliance information and so on. Basically, you need to have a good inventory of all your open-source assets—a central repository for open-source software that has been approved for deployment. This inventory is handy for use by engineering, legal and OSRB.
Open-source training: ensures that employees have a good understanding of your company's open-source policies and compliance practices, in addition to understanding some of the most-common open-source licenses. Some companies go one step further by mandating that engineers working with open-source software take open-source training and pass the evaluation.
Open-source portals: companies usually maintain two open-source portals: an internal portal that houses the open-source policies, guidelines, documents, training and hosts a forum for discussions, announcements, sharing experiences and more; and an external portal that is a window to the world and the Open Source community and a place to post all the source code for open-source packages they use, in fulfillment of their license obligations with respect to distribution.
Third-party software due diligence: you should examine software supplied to you by third parties carefully. If third-party software includes open-source software, ensure that license obligations are satisfied, because this is your responsibility as the distributor of a product that includes open-source software. You must know what goes into all of your product's software, including software provided by outside suppliers.
Several departments are involved in ensuring open-source compliance (Figure 3). Here's a generic breakdown of the different departments and their roles in achieving open-source compliance:
Figure 3. Teams Involved in Ensuring Open-Source Compliance
Legal: advises on licensing conflicts, participates in OSRB reviews, and reviews and approves content of the open-source external portal.
Engineering and product team: submits OSRB requests to use open-source software, participates in the OSRB reviews, responds promptly to questions asked by the compliance team, maintains a change log for all open-source software that will be made publicly available, prepares source code packages for distribution on the company's open-source public portal, integrates auditing and compliance as part of the software development process checkpoints, and takes available open-source training.
OSRB team: drives and coordinates all open-source activities, including driving the open-source compliance process; performs due diligence on suppliers' use of open source; performs code inspections to ensure inclusion of open-source copyright notices, change logs and the like in source code comments; performs design reviews with the engineering team; compiles a list of obligations for all open-source software used in the product and passes it to appropriate departments for fulfillment; verifies fulfillment of obligations; offers open-source training to engineers; creates content for the internal and external open-source portals; and handles compliance inquiries.
Documentation team: produces open-source license file and notices that will be placed in the product.
Supply chain: mandates third-party software providers to disclose open-source software used in what is being delivered.
IT: supports and maintains compliance infrastructure, including servers, tools, mailing lists and portals; and develops tools that help with compliance activities, such as linkage analysis.
The following compliance best practices fall under six major categories. Each of the categories represents a step in a typical compliance process (Figure 4).
Figure 4. A Generic Open-Source Compliance Process
1. Scanning Code
The first step in the compliance process is usually scanning the source code, also sometimes called auditing the source code. Some common practices in this area include:
Scanning everything—proprietary code, third-party software and even open-source software, because your team might have introduced modifications triggering the need for additional due diligence and additional obligations to fulfill.
Scan early and often—scan as early in the development process and as often as possible to identify new packages entering your build.
Scan newer versions of previously approved packages—in the event that a previously approved packaged was modified, you should rescan it to ensure that any code added to it does not have a conflicting license and that there are no additional obligations to meet.
2. Identification and Resolution of Flagged Issues
After scanning the source code, the scanning tool generates a report that includes a “Build of Material”, an inventory of all the files in the source code package and their discovered licenses, in addition to flagging any possible licensing issues found and pinpointing the offending code. Here's what should happen next:
Inspect and resolve each file or snippet flagged by the scanning tool.
Identify whether your engineers made any code modifications. Ideally, you shouldn't rely on engineers to remember if they made code changes. You should rely on your build tools to be able to identify code changes, who made them and when.
When in doubt of the scan results, discuss it with Engineering.
If a GPL (or other) violation is found, you should report to Engineering and request a correction. Rescan the code after resolving the violation to ensure compliance.
In preparation for legal review, attach to the compliance ticket all licensing information (COPYING, README, LICENSE files and so on) related to the open-source software in question.
3. Architecture Review
The architecture review is an analysis of the interaction between the open-source code and your proprietary code. Typically, the architecture review is performed by examining an architectural diagram that identifies the following:
Open-source components (used as is or modified).
Proprietary components.
Components' dependencies.
Communication protocols.
Linkages (dynamic and static).
Components that live in kernel space vs. userspace.
Shared header files.
The result of the architecture review is an analysis of the licensing obligations that may extend from the open-source components to the proprietary components.
4. Linkage Analysis
The purpose of the linkage analysis is to find potentially problematic code combinations at the dynamic link level, such as dynamically linking a GPL library to proprietary source code component (Figure 5). The common practices in this area include:
Performing dynamic linkage analysis for each package in the build.
If a linkage conflict is identified, report to it Engineering to resolve.
Redo the linkage analysis on the updated source code to verify that the code changes introduced by Engineering resolved the linkage issue.
As for static linkages, usually companies have policies that govern the use of static linkages, because it combines proprietary work with open-source libraries into one binary. These linkage cases are discussed and resolved on a case-by-case basis.
Figure 5 illustrates the difference between static and dynamic linking to highlight the importance of identifying how open-source license obligations can extend from the open-source components (libraries, in this example) to your proprietary code through the linking method.
Figure 5. Static vs. Dynamic Linking
5. Legal Review
The best practices of the legal review include:
Review the report generated by the scanning tool attached to the compliance ticket.
Review the license information provided in the compliance ticket.
Review comments left in the compliance ticket by engineers and OSRB members.
Flag any licensing conflict and reassign compliance ticket to Engineering to rework code if needed.
Contact the open-source project when licensing information is not clear, not available or the code is licensed under more than one license with unclear terms/conditions.
Decide on incoming and outgoing license(s)
6. Final Review
The final review is usually an OSRB face-to-face meeting during which open-source software packages are approved or denied usage. A good practice is to record the minutes of the meeting and the summary of the discussions leading to the decisions of approval or denial. This information can become very useful when you receive compliance inquiries. For approved open-source packages, the OSRB would then compile the list of obligations and pass it to appropriate departments for fulfillment.
This section presents guidelines to observe when dealing with compliance inquires. These guidelines aim to maintain a positive and collaborative attitude with the requester of compliance information while investigating the allegation and ensuring proper handling in case of license violation. Figure 6 illustrates the recommended steps to follow when dealing with open-source compliance inquiries.
Figure 6. Handling an Open-Source Compliance Inquiry
Several companies received negative publicity and/or got sued because they either ignored requests to provide open-source compliance information, did not know how to handle compliance inquires, lacked or had a poor compliance program, or simply refused to cooperate, thinking it was not enforceable. By now, we know that none of these approaches is fruitful or beneficial to any of the parties involved. Therefore, as a general rule, companies should not ignore open-source compliance inquiries. Instead, they should acknowledge the receipt of the inquiry, inform the inquirer that they will look into it and provide a date when to expect a follow-up.
You should understand who the reporter is, the motivation and whether the accusation is accurate or even current. Furthermore, not every reporter understands licenses fully, and sometimes there may be mistakes in the submissions. Make sure you fully understand the inquiry and that you have all the necessary information to isolate the problem and investigate it internally. If that's not the case, ask the reporter to be specific and provide you with the missing details to start your investigation.
Keep an open dialog with the reporter and show that your company maintains rigid compliance practices. Highlighting your open-source compliance program and practices shows a good-faith effort toward compliance. Send updates of your internal investigation when they are available.
After concluding the internal investigation (within an acceptable time limit) through the review of the compliance due diligence completed for the specific software component (or product) in question, inform the reporter of the results.
If indeed there is a license violation as reported, it is your responsibility to resolve the issue with the reporter, while being collaborative and showing goodwill. You need to understand the obligations under the applicable license and show how you will meet the obligations and how soon.
This article provides an overview of open-source compliance, the challenges faced when establishing a compliance program, industry practices and recommendations on how to deal with compliance inquiries.
Open-source compliance is an essential part of the development process. Start with a simple, lightweight compliance process and practice and learn and adjust as you proceed. Look at common practices for inspiration, but most likely you will make adjustments to fit your specific company's needs.
If you use open-source software in your product(s), and you don't have a solid open-source compliance program, consider this article as a call to action.
