Open Compliance Summit 2022 – State of the Union from Mike Dolan, SVP and GM of Projects at The Linux Foundation
1. State of the Union
Open Compliance Summit 2022
Mike Dolan, SVP and GM of Projects
1
2. 15+ years ago, we starting collaborating to reduce
issues with open source license compliance
What license is
this code?
What license(s)
are in my code?
What license(s) are
in this code you
gave me?
2007
2007 2010
Legal and
developer
education
Scan and
document
SBOMs
2
3. 15+ years ago, we starting collaborating to reduce
issues with open source license compliance
What license is
this code?
What license(s)
are in my code?
What license(s) are
in this code you
gave me?
2007
2007 2010
Scan and
document
SBOMs
I know what’s in
this code!
Success
Legal and
developer
education
3
4. These efforts used transparency to solve our
challenges with open source compliance
Greater transparency enables
decision makers to make
better decisions
With open source software, we
weren’t concerned about
confidential or proprietary
information in the open
source software
4
5. The business reason for open compliance was
cost effective legal risk management
● We were concerned about legal loss
events that could impact our
companies
● License non-compliance could
present various loss events:
○ Lawsuits
○ Damage to reputation
○ Business interruption due to injunctions
● “Compliance” became a quasi-legal
concern (but it’s not just that
anymore)
5
6. New! WebAssembly for legal professionals
https://www.linuxfoundation.org/research/webassembly-for-legal-professionals
English, Japanese (日本), Chinese (中国人) available
6
8. As our challenges evolved, we
worked on new solutions… by
adding more transparency.
8
9. We then openly collaborated to reduce issues
with open source management
What license is
this code?
What license(s)
are in my code?
What license(s) are
in this code you
gave me?
How do I manage
my license
information?
2007
2007 2010
Educate others Scan and
document
SBOMs SBOM
management
2015
How do I
manage my
supply chain?
Process
Standards
2015
9
10. We built open source management groups
(OSPOs) to help scale risk management
● OSPOs started as “the open
source group” in many companies
● Ultimately OSPOs were designed
to manage risk for the company
○ Risk of licensing issues in products
○ Risk of licensing issues in supplier
artifacts
○ Risk of inappropriate product
dependencies
○ Community engagement risks
https://todogroup.org/guides/
10
11. The legal risks have continued to evolve …
requiring evolution in risk management
● Losses from trolls
○ Copyright trolls
○ Patent trolls
● We worked on new solutions
○ Developer Certificate of Origin (2004)
○ Linux Kernel Enforcement Statement
(2020)
○ Collaborations with Unified Patents and
Open Invention Network
https://www.kernel.org/doc/html/latest/process/kernel-enforcement-statement.html 11
12. We can work together even on complex issues
12
https://lore.kernel.org/netdev/Ye6jCQm7z0Yr3bqA@salvia/T/
13. With the legal risks managed, open source was
able to grow … massively
https://www.sonatype.com/state-of-the-software-supply-chain/open-source-supply-demand-security
13
14. And now we face cybersecurity risk, and a need
for open source security risk management
https://www.sonatype.com/state-of-the-software-supply-chain/open-source-supply-demand-security
14
15. And now we are openly collaborating to extend license
risk management tools, processes, and standards to
address security risks
What are we
building into
our product?
How do I share
what packages
are in this?
How do I verify this
is the package you
said it is?
CI/CD Build
Systems
SBOMs Attestation
service
How do I
manage my
supply chain?
Process
Standards
SLSA
Is that OSS
community
security
focused?
Scorecard
What is the
integrity?
Levels of
assurance
S2C2F
15
16. Our existing risk management standards are evolving
to address security risk mitigation requirements
16
https://www.linuxfoundation.org/blog/the-openchain-security-assurance-
specification-1.1-now-available
https://www.chainguard.dev/unchained/whats-new-in-spdx-2-3
Major Changes in SPDX 2.3
Security: One of the main uses of SBOMs today
is dependency and vulnerability management.
This version introduces advisory, fix, URL and
SWID as categories in the security identifiers to
link the package to additional security context.
GitBOM: Joining the list of persistent identifiers
comes gitoid, the identifier used by the GitBOM
project to cryptographically track where a
package fits in the dependency tree.
17. New investments in OSPOs are needed to help
CISO teams address open source cybersecurity
risks.
Licensing
Risks
Security
Risks
OSPOs that partner with product security teams help define policies,
processes, build system requirements, and supply chain transparency
for managing security risk in open source and commercial product
systems
17