Managing Open Source in Your Supply Chain
O’Reilly Open Source ConferenceAndy WilsonChief open source compliance officer, [email protected]
agenda
intro“the big picture”things that make a differencelots of time for discussion
IANAL, TINLA, personal intro
the SW world is not flat…
… the SW world is systolic
in a systolic economy, vendors provide direct, immediate value-add
and pass through to the next stage
the product cycle is continuous
pipelines are deep
development is highly parallel
Each processing node runs on its own pulse
as “wavefronts” of code flow through
lub dub
The beat goes on.
The enemy of a systolic world is friction.
proprietary standards, undocumented HW, restricted software cause friction
Open standards, documented HW, open source reduce friction
open source is not zero friction
it is not public domain
open source has rules
not following the rules is a mistake
mistakes can clog your pipeline
mistakes can even land you in court
don’t make mistakes
to avoid mistakes
it is in your interest to pass good information downstream
information loss is friction
friction is bad
getting good information from upstream can be hard
be clear with your downstream you need all their information
(and a “no open source at all” policy from your vendors is so 1995)
You need confidence in your vendor’s information
you need to know where SW came from and how it is licensed
you need downstream info in an understandable format
and you need to document what you add in an understandable format
pass on all your vendors’ information plus your information
you will be asked for the info at some point
if you can’t find the info, it’s a fire drill.fire drills are bad
recap
think systolically
know exactly what you take in
know exactly what you add
always pass your information through; destroying information causes friction
things that can help (1): have a GPL policy
GPL is a high friction open source license
not a criticism
just a fact
GPL is long
it has never been litigated in the US
there are two incompatible versions
smart people disagree about what GPL means
(But a “no-GPL” policy is so 1995)
so you need a GPL policy
define what is acceptable, what is not
for example, LKMs: will you accept binary kernel modules?
another example: how do you want source code packages?
give it your best shot
there is no “perfect”
there is only “good enough”
a GPL policy is good enough if
you can articulate it crisply
you can defend it
and you can deliver on it
documented and communicated upstream; downstream; and to your developers.
things that can help (2): tools
source code scanning
binary code scanning
standardized SW bill of materials (SPDX or other)
things that can help (3): always use boilerplate
standard clauses in your contracts saying what you expect
example: “we need rights to publish a GPL Linux driver” for HW
example: “we must have a complete software Bill of Materials in this format”
example: “we must have the complete GPL sources as tarballs and instructions to compile them”
rewind
Think systolicLow frictionPreserve informationHave a GPL policyUse toolsUse boilerplate
discussion
Thank you!
links to systolic systems, natural and artificial:
en.wikipedia.org/wiki/Systolic_arraywww.mayoclinic.com/health/circulatory-system/MM00636
links for tools:
www.binaryanalysis.org/en/homewww.blackducksoftware.com/www.fossology.org/www.palamida.com/http://www.spdx.org/
legal disclaimers
Linux is a registered trademark of Linus TorvaldsIntel is a registered trademark of Intel Corp.Other trademarks are property of their holders.Nothing in this presentation is intended as legal advice.
