Managing Open Source in Your Supply Chain

O’Reilly Open Source ConferenceAndy WilsonChief open source compliance officer, Intelandrew.wilson@intel.com22-July-2010

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.