At the last Open Source Leadership Summit in February, I had the chance to develop some of my thoughts around OpenChain™ and its applicability for the free and open source software community at large. To recap, OpenChain is a Linux Foundation project currently headed up by Shane Coughlan (who used to work with the FSFE and is still part of our legal team). It's vision is a software supply chain for free and open source software which is trusted and with consistent license information. The OpenChain Conformance Specification1 is a "set of requirements and best practice for open source organizations to follow in an attempt to encourage an ecosystem of open source software compliance."
One way to look at this is as a checklist of things organisations must do or make available in order to have a reasonable chance of living up to its compliance commitments in free software. This includes educating software staff about free software, having a process to track free software used so the corresponding source code can be made available, and that offers to do so are included with software (where required). All in all, these are some reasonable expectations of what an organisation is expected to do. It doesn't guarantee compliance, but it encourages it.
However, as the saying goes, no chain is stronger than its weakest link. The vision of OpenChain speaks of the software supply chain, and the supply chain starts with a free and open source software project. Like the Linux kernel, or the GNU C Library. If we expect that those using free and open source software projects comply with the license terms, we must consider the project as part of the supply chain, and find ways in which we can make it as a trusted part of the chain.
When I was young, I worked summers at Ericsson Telecom AB as a tester for passive components. The way it worked is Ericsson would buy components for its products, and when the components arrived, a few of each batch would be sent for testing where the components were meticulously tested to make sure they conformed with the specification.
After my second year there, we started getting less components to test. During my third year, most of the tests had been replaced and the components went straight into storage. What replaced the tests? Trust. By working with their suppliers, Ericsson set up systems to encourage the suppliers to take a larger responsibility for the components it shipped. As the trust increased between Ericsson and its suppliers, and as suppliers took more responsibility for what they shipped, the need for Ericsson to do the testing on their side reduced drastically.
The free and open source sector right now is in a state where validation and due diligence of software licenses must be done at almost every link in the chain. OpenChain is one of the ways in which the trust can be increased, but we need to move this back to the project level and encourage reasonable compliance practices for every major free and open source software project.
We can actually look at OpenChain as providing some of the answers to what those practices would be. We need to think more broadly, but a lot of the practices mandated by OpenChain for organisations make a lot of sense for projects as well.
Have a documented FOSS policy
Every project should to have the license choice of the project documented, both as it relates to the actual source code and any ancillary parts (where the license choice may be different). The rationale for a certain license may be included, as well as information about how future license changes would be considered by the project.
This policy should also consider dependencies against external projects and their licenses.
Make FOSS training available
Developers, even in volunteer projects, need to have some basic knowledge about free software compliance in order to make informed decisions. This should be included as part of any request to sign copyright assignments and developers should be encouraged to occasionally review the project's recommended training materials about compliance.
Identify a FOSS liaison
There should be a publicly communicated e-mail address or similar contact point to which people can submit questions or concerns regarding compliance. In its simplest form, this can easily be an email address which creates ticket in a ticket system available for core developers (or another identified group). As legal information may be submitted through this, it should generally not be immediately publicly accessible though.
Arrange an external source of legal expertise
If we have a FOSS liaison function for the project which is composed of the core developers or another identified group, we need to resolve the question of escalation: if a compliance question can not be responded to, where does it escalate?
Every project should have identified an external source of legal expertise which function both as a source of expertise as needed and also as an escalation path to ensure matters reported are dealt with accurately.
Take care when distributing
To the extent the license used require it (as is usually the case when distributing binaries, which some projects may optionally do in addition to its source code), the project also need to consider the obligations placed on it when making releases.
The policy earlier described should ideally cover these cases too, but the actual work and what needs to be done can include:
- Maintain archival copies of dependencies' source code to be able to satisfy requests for the complete corresponding source code,
- Information about the build process,
- Preparing and including SPDX metadata,
- Including relevant credits and license information,
- Including an offer for source code.
If you look at the current OpenChain Conformance Specification, some of the practices above are reflected in that specification. This makes sense: if free and open source software projects follow similar practices and processes as the organisations using the software, we increase the likelihood of a consistent, compliant, supply chain.