The document discusses the importance of shifting compliance activities left in software development, emphasizing the need for organizations to manage risks effectively while maximizing value. It highlights the roles and responsibilities of various stakeholders in establishing a compliance process within an Open Source Program Office (OSPO) and encourages developers to understand their products thoroughly. Key takeaways include the necessity of proactive dependency management, clear communication, and thoughtful automation in compliance efforts.

1. Shifting Open Source Compliance
Activities Left
Josh Clements
All Things Open 2024

2. Acknowledgements
●
Inspired by my time managing compliance projects in an open
source program office (OSPO)
●
Analog Devices Inc.
– Steve Kilbane
●
University of Mary Washington

3. Context
●
You’ve probably heard a lot about shifting left in DevOps
– Shift too many activities left and you’re basically doing everything all at once
– Compliance is more of an ongoing process
●
Organizations exist to realize value for stakeholders
– Manage risk to maximize net benefits (aka profit)
– Governance established to standardize results
●
Software development managers want products to ship on time
(among other concerns)
– They need to make sure what I’m about to talk about happens
●
Developers want to solve problems
– “How” isn’t usually their primary concern…

4. Getting Started
●
Compliance is usually one of an org’s first efforts
– Establishes an inventory (i.e. consumption)
– Supports security processes (e.g. CVE response)
●
Begin with the end in mind
– An effective compliance process will support issuance of an outgoing
license (open or otherwise)

5. Enter the OSPO
●
...or maybe just folks that know about open source licensing
– Developers with open source experience
– Analysts
– Legal (licensing and/or intellectual property)
– Other management personnel (e.g. project/program)
●
Define the compliance process for the organization
– Monitor and improve
●
Ensure the process is communicated clearly to stakeholders
●
Support stakeholders throughout the process

6. Developer Responsibilities
●
The OSPO will report to “management”, but work with “dev
teams”
●
Know what’s in your product
– Legacy code
– Binaries
●
Discuss dependencies before integration
– Dependencies of dependencies of dependencies…
– Not asking permission; make risk decisions earlier in development
●
Understand the compliance process
– Ask questions until you do

7. Sustainable Open Source Program in Your Org
●
Following through with your responsibilities can be frustrating at first
– Hang in there!
●
Tools are maturing; manage your expectations
– This is why developers need to know what’s in their product(s)
●
Automate processes when possible
– Specifically software bill of material (SBOM) creation, but need to check it
●
Risk tolerance is a business decision
– Even if you’re not-for-profit, your pants can be sued right off
– Don’t forget about brand integrity or corporate goodwill as assets
●
Lots of methods… figure out what works best for you, then iterate

8. Parting Thoughts
●
Main point: Stay on top of your dependencies
– Make the business decision before you start writing code
●
Give this a good effort
– Talented people have worked hard on these products
– When you have an effective program but something slips through,
apologies and corrections help
●
Folks with sufficient experience are hard to find; treat them right
– They’re acting in support of the org’s mission
– They want to help, not hinder

9. Thank you!
josh@clements.net