May 4, 2015 - Ibrahim Haddad

7 Steps to Strengthen Your Open Source Compliance

Introduction

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
Three fundamental steps comprise the core of an open source compliance process

Figure 1: The three fundamental steps that comprise the core of an open source compliance process

In this blog post, I’ll discuss a 7-step system you can use to improve and strengthen your open source compliance program:

  1. Assign an open source compliance officer
  2. Set up an Open Source Review Board (OSRB)
  3. Set up an automated system to identify open source software in your code base
  4. Get your software suppliers to comply with open source licenses
  5. Scale open source legal support to your development teams
  6. Include open source compliance checkpoints as part of business and development processes
  7. 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.

OSRB Members Primary Responsibilities
Legal representative
  • Review and approve usage, modification, distribution of FOSS
  • Provide legal guidance
  • Contribute to the creation of the open source compliance training
  • Contribute to the creation and improvement of the compliance program
  • Review and approve content of web portals in relation to compliance
  • Review and approve the list of obligations to fulfill for each software component included in a product
  • Sign off on product release from a compliance perspective
Engineering and product team representative
  • Follow compliance policies and processes
  • Integrate compliance practices in the software development process
  • Contribute to improving the compliance program
  • Follow technical compliance guidelines
  • Respond quickly to all compliance related questions
  • Conduct design, architecture and code reviews
  • Prepare FOSS packages for distribution
  • Sign off product release from a compliance perspective
Compliance Officer
  • Drive compliance activities
  • Coordinate source code scans and audits
  • Participate in engineering reviews, code inspections, distribution readiness assessment
  • Coordinate distribution of open source software
  • Contribute to the creation of compliance training
  • Help improve the compliance program
  • Contribute to the creation of new tools to facilitate the automation and discovery of open source in the development environment

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.

Figure 2: Individuals and teams responsible for achieving open source compliance

Figure 2: Individuals and teams responsible for achieving open source 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.

Figure 3: Sample open source compliance process

Figure 3: Sample open source compliance process

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:

License Playbooks

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.

License classification

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
Ibrahim Haddad

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

Business / Compliance how to / Legal / Policy / Processes / Software Supply Chain /

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments Protected by WP-SpamShield Anti-Spam