May 4, 2015 - Ibrahim Haddad
7 Steps to Strengthen Your Open Source Compliance
Proper Open Source compliance gives you the ability to honor the obligations of open source licenses while protecting your own Intellectual Property (IP), as well as that of 3rd party software providers, from unintended disclosure. Companies that use open source software in their products should establish such a program to ensure compliance with all open source licenses. Basic elements of a compliance program include: policies, processes, guidelines, training, and automated source code audits. Compliance activities must be carefully planned and monitored to assure that objectives are met in a timely manner.
There are three fundamental steps that comprise the core of a Free & Open Source Software (FOSS) compliance process:
- Identifying any open source software contained in an externally distributed product
- Reviewing and approving the intended use of FOSS
- Satisfying FOSS license obligations
In this blog post, I’ll discuss a 7-step system you can use to improve and strengthen your open source compliance program:
- Assign an open source compliance officer
- Set up an Open Source Review Board (OSRB)
- Set up an automated system to identify open source software in your code base
- Get your software suppliers to comply with open source licenses
- Scale open source legal support to your development teams
- Include open source compliance checkpoints as part of business and development processes
- Provide checklists for the various open source compliance tasks
Step 1: Assign a Dedicated Open Source Compliance Manager
The compliance officer manages the overall compliance program. This person drives compliance due diligence, end-to-end process, and acts as the compliance program manager to ensure all compliance-related tasks are resolved and there are no compliance issues blocking product shipment.
The open source compliance officer must have the following expertise:
- Solid understanding of open source licenses and obligations to discuss with legal counsels
- Knowledge of open source development and compliance industry best practices
- Knowledge and experience in establishing corporate wide programs, policies, and processes
- Technical knowledge in order to be capable of conversing with engineers
- Contacts in the open source organizations and communities that could be called upon for clarification and support when needed
Step 2: Set up an Open Source Review Board
The open source review board consists of representatives from legal and product teams, in addition to the compliance officer. The primary duty of the OSRB is to review and approve the planned use of open source software in products.
Table 1 provides a detailed view of the responsibilities of each participant in the OSRB.
Table 1: Primary responsibilities of the core compliance team
Outside of the OSRB members, there are several individuals that contribute to the open source compliance effort. Figure 2 presents the individuals and teams responsible for achieving FOSS compliance.
Step 3: Identify Open Source Software in Your Code
The core of any open source compliance effort is to identify open source code and its respective licenses so you meet all license obligations. This core activity is guided by an open source policy and a process. Compliance policies and processes govern the various aspects of using, contributing, auditing, and distributing open source software. The policy is a set of rules for the use and management of open source software in the organization. The process describes how the organization will implement these rules on a daily basis.
Here is a short example of an open source compliance policy:
We must ensure that all of <COMPANY NAME>’s incoming software (in house, 3rd party commercial, open source, etc.) is compliant with the license it is provided under by following the open source compliance process defined in <URL>.
Figure 3 is an example of an end-to-end compliance process that includes the various steps a software component goes through before the OSRB approves its acceptance in the build system and integration with the software product.
Step 4: Get Software Providers Involved
It is crucial to get your software providers involved in the open source compliance process. Software providers must disclose any open source code included in the products they deliver to you, and they must offer everything you’ll need to meet license obligations once these deliverables are included in your own product.
It is common to require software providers to disclose the following information related to open source software:
- Package name
- Version number
- Original download URL
- License and License URL
- Last Modified Date
- Dependency List
- Development team’s point of contact
- Availability of source code
Different organizations require various disclosures, but the list above is a good starting point. In addition to this list, it is very desirable for software providers to report license information for FOSS using the Software Package Data Exchange (SPDX) format, especially if their clients have already adopted SPDX.
Step 5: Offer Easily Accessible Legal Support
It is often the case that open source legal support is a bottleneck in a company, as you might have hundreds, or even thousands of developers writing open source code, but very few legal staff responsible for providing the needed legal support. Scaling open source legal support requires some out-of-the-box thinking and it can be achieved via four practical methods:
An easy-to-read and digest summary of FOSS licenses intended for software developers. This provide easy-to-understand information about FOSS licenses, such as license grants, restrictions, obligations, patent implications, and more. The availability of such playbooks for the most-used FOSS licenses minimizes the number of basic questions sent to legal counsels and provides developers with immediate legal information.
License compatibility matrix
License compatibility is determining if a certain license has compatible terms with another license. When something is said to have “GPL compatibility,” it states that a certain license has compatible terms with the GPL. The license compatibility problem is often encountered when combining source code originating from different software components licensed under incompatible licenses, which makes it impossible to combine the source code to create a new component.
When the development team combines incoming code under different licenses, they can refer to the license compatibility matrix to verify if there is a licensing conflict created by combining the source code into a single software component. If a license is used and it is not covered in the matrix, it can be added by the legal counsel that advises on open source licensing.
An easy way to understand the difference between licenses and the course of action needed when using source code provided under these licenses.
Software interaction methods
A guide to understanding how software components available under different licenses interact and if the method of interaction is allowed according to company compliance policies.
Step 6: Inject Compliance Activities into Everyday Development Processes
To ensure the success of your open source compliance effort, incorporating compliance practices into business and development processes is a must. To achieve this, you can:
- Modify existing business processes to incorporate open source compliance activities and considerations
- Tailor software supplier selection procedures to assure that open source compliance requirements are considered when performing due diligence on suppliers
- Update process management to ensure that compliance activities are included early enough in the product development cycle to enable the organization to meet its release time-lines
- Use late-cycle verification steps to assure that all compliance requirements have been met before external distribution occurs
- Provide open source compliance training to individuals charged with managing business processes
- Provide license information in SDPX format that includes reporting license names using the SPDX common naming system
Step 7: Develop and Use Checklists
Checklists are extremely useful tools to ensure consistency and completeness in carrying out compliance tasks. It is highly recommended to establish a checklist for most compliance milestones as well as targeted checklists based on staff responsibilities. Examples of checklist include:
- To approve the integration of incoming code into the product’s source code repository
- To ensure the fulfillment of obligations from developers, engineer managers, compliance staff, and open source legal staff
The following is an example of a checklist that can be used before posting source code packages on a web site as part of fulfilling open source license obligations:
- All source code components have a corresponding compliance ticket
- All compliance tickets have been approved by engineering and legal
- All compliance tickets are clear from any sub-tasks attached to them
- Notices for all of the software components have been sent to Documentation team and included in product documentation (including written offer)
- Legal has approved the written offer notice and overall compliance documentation
- Source code packages have been prepared and tested to compile on a standard development machine
- Source code provided is complete and corresponds to the binaries in the product
Open Source Compliance and the Software Supply Chain
The first time I was introduced to open source compliance was over a decade ago while I was a system engineer at Ericsson Research. Since then, compliance practices have improved dramatically and I’ve learned a lot. Open source compliance today is a far different problem than what it was 15 years ago, and today it is more about scaling, automation, and building trust within the software supply chain. Stay tuned to this site to learn more about open source compliance in future posts.Image Credits: Samsung Open Source Group
About Ibrahim Haddad
Ibrahim Haddad (Ph.D.) is Vice President of R&D and the Head of the Open Source Lab at Samsung Research America, a wholly owned R&D subsidiary of Samsung Electronics. He is responsible for overseeing Samsung's Open Source strategy and execution, internal and external collaborative R&D projects, and representing Samsung in open source foundations and open standards.
Image Credits: Samsung Open Source Group