SCA Tool

Open source, safe and easy

The License-Compliant Distribution Workflow

Shipping a product that includes open source code to customers requires compliance with the licenses of the included code. For most products and in most companies, distributing a binary with open source code is a complex workflow that is best managed by or with the help of an open source program office (OSPO) or by whoever is filling out the OSPO’s function. To recap: An OSPO is an organizational unit inside a company tasked with bringing order, best practices, and efficiency to using open-source software as well as contributing to and leading open source projects.

The license-compliant distribution workflow of projects or products that contain open source code starts long before the creation and provision of legal notices or corresponding source code to customers. It also doesn’t end there. The base workflow contains at least these activities:

  1. Review and approval of incoming open source components (see “inbound licensing”);
  2. Building of the project or product binaries including fully tracked and archived source code;
  3. Review and approval of outgoing software with open source code (see “outbound licensing”);
  4. Creation of legal notices or corresponding source code (as needed);
  5. License-compliant distribution of the project or product.

Base activity 2, building the project or product, includes the provision and usage of build tools and corresponding configurations of these tools. Pre-commit hooks may want to test that a commit has not been copied from Stackoverflow, component repositories may be used to provide vetted versions of approved components, and/or scripts and version control systems may be used to set aside correct corresponding source code for the binary build being created.

Base activity 1, the review process, includes the software composition analysis of the incoming open source component to determine the component’s software bill of materials (SBOM). The approval of the component includes reviewing the licenses of the materials in the component’s SBOM.

Base activity 3, review and approval of outgoing projects or products, includes the review of the to-be-distributed code beyond the original approval. Outbound licensing knows more than inbound licensing: The software architecture may have changed, creating an unwanted copyleft effect where previously there was none, an unwanted patent grant may follow from compliance with an open source license, and/or the recipient of the distribution may reside in a embargoed country so export control rules need to be observed.

Base activity 4 then proceeds as outlined in a previous section, ideally by relying on a properly compiled SBOM to create the legal notices. Ideally, this activity can be merged into base activity 2, building the binary in the first place. However, tools often aren’t that well integrated, making the creation of legal notices a separate activity.

Base activity 5 then ensures that the legal notices will be incorporated into the distributed binary in an appropriate way, also as discussed in a previous section.

The operations of this base workflow are typically performed by the engineering organizational units. In parallel, the OSPO needs to operate a meta workflow that accompanies and guides the base workflow. The meta workflow contains at least these activities:

  1. Provision and operation of compliance tools to support the engineering organizational units;
  2. Provision of configurations of compliance tools to establish and maintain corporate standards;
  3. Provision of a central public point of contact for open source related questions.

Meta activity 1, the provision of compliance tools, includes the licensing and operations of SBOM management, open source governance, and license compliance tools. Engineering organizational units will typically run their own build processes, but will benefit from pulling in compliance tooling from a centrally managed place.

Meta activity 2, the provision of configurations, includes the configuration of said compliance tools. Such configuration can be non-trivial, including custom development work. The OSPO may have to set up a standardized license interpretation for the company’s products and encode it in the tools. This way, the OSPO makes sure that different organizational units still treat open source licenses the same way. OSPOs that rely on a tool vendor’s off-the-shelf configuration do so at their own risk.

Meta activity 3, the provision of a public point of contact for open source related questions is a best practice in which all projects and products of the company that contain open source code provide an address of who to talk to with questions about open source code in a binary. Usually, it is just an email inbox, but it needs to be monitored and inquiries need to be answered.

There are more activities you may have to consider. Typically, the larger the company and its product portfolio, the more activities there are.

© 2024 Dirk Riehle, used with permission.

Next up: Legal threats and resolutions