As open source becomes more and more part of the software development lifecycle, enterprise development factories need reliable policies driving repeatable practices to ensure open source is being managed appropriately. This talk reviews the practices needed for an Open Source Programme Office (OSPO) and proposes automation within the developer workflow as the most effective approach to policy compliance.

1. Continuous
Open Source
Compliance
A framework for a policy-driven
Open Source Programme Office
Simon Phipps, @webmink
simon@meshedinsights.com
SFSCon 2020

2. Overview
● Software usage is now underpinned by open source
○ Best practice for a medium-large enterprise will manage use of open source
○
○ A centralised Programme Office handles these issues optimally
● Starting point is a set of policies
○ Much to consider beyond merely licensing, much licensing beyond mere GPL
○ Clearly stated
○ Measurable compliance
○ Executive backed
● Integrate compliance into workflow
○ Crucial not to introduce approval steps unless essential. The fundamental benefit of open
source is innovation and collaboration without constant intervention
○ Use CI/CD and objective compliance rules to ensure all open source and inner source
usage respects licenses and upstream communities and protects business success.
○ Break the build to ensure compliance, rather than using management reporting or
meetings

3. Open Source Supply Chain
From “Continuous Open Source License Compliance”, Phipps & Zacchiroli, IEEE Computer, December 2020

4. Open Source Supply Chain
● Includes “Inner Source” approaches, which have all the
same management needs apart from those associated
with outbound software
● Even in those cases it is hygenic to ensure license terms
are respected
● Management needs relate especially to the maintainers
of inbound software and internal
developers/maintainers

5. Beyond Licensing
Compliance ≠ License Compliance
● GPL compliance is just another matter of supplier hygiene
● Licenses have more requirements than just CCS
● There is far more to effective open source than licensing
We will thus use the concepts of
● Open Source Policy
● Policy Compliance

6. Policy Framework
To manage use of open source software, an OSPO needs policies
including:
● The right of the organisation to use the software
○ License responsibilities
○ Responsibility to software users
○ Software Bill of Materials (SBOM) requirements
● How the software is sustained
○ Relationship with upstream communities
○ Support contracts
○ Internal staffing allocations
● Key metrics for ensuring policy compliance
(There will be other policies too!)

7. Sample Machine-Enforceable CI Policies
● Is a valid SBOM present?
○ This will also be a CD requirement
● Is each license in the project on the OSPO-approved list?
○ Forces licensing policy compliance and avoids prohibited licenses
○ Licenses with manual approval requirements should have signed exceptions in the
tree
● Are the licenses used in the project mutually compatible according to
OSPO policy?
○ Again, ensures policy compliance. Use a signed exception if “it’s complicated”
● Is a maintainer identified in file header?
○ Could be in-house, a service provider or a signed exception for an upstream
community
○ Ensures code is sustainable

8. Sample Machine-Enforceable CD Policies
● Is a signed OSPO review report in the project folder?
○ Ensures OSPO review is always sought by developers
● Are all changes connected with an upstream pull-request?
○ Makes sure a responsible upstream contribution policy is followed
● Is the person taking responsibility for the deployment
identified?
○ So if there are any hacks to circumvent COSC you know who did it!
● Is a valid OpenChain SBOM available?
○ Or other supply chain documentation requirements
● Do any dependencies have active CVEs?

9. Continuous Open Source Compliance
From “Continuous Open Source License Compliance”, Phipps & Zacchiroli, IEEE Computer, December 2020

10. Continuous Open Source Compliance
● Policy-driven OSPO work brings demonstrable value to the enterprise.
● Metrics and proofs matter!
○ Those which are an artefact of the development workflow will be up-to-date.
○ Those which require additional work that does not result in earlier delivery will not!
● Compliance which operates within the development workflow follows
the same rules!
● So to ensure open source policy compliance, build it in to the
CI/CD/workflow
● Policy-based overall governance that is automatically enforced within
the workflow is “Continuous Open Source Compliance”
○ There is no greater motivation to compliance than breaking the build or the
deployment on non-compliance!

11. Much, much more can be said!
simon@meshedinsights.com
Many thanks to my co-author Stefano Zacchiroli
Our supporting paper due December in IEEE Computer journal.
https://dirkriehle.com/open-books/open-source-expanded-column/
Thanks for watching!
© 2020 Simon Phipps & Meshed Insights Ltd. Licensed CC-BY-SA 4.0 (Unported)