owf14 - open source & software supply chain

Supply Chains with Built-In

License Compliance

Claus-Peter Wiedemann

Sr. Manager, FOSS Management, BearingPoint

Phil Odence

VP/General Manager, Black Duck

Chair, SPDX Workgroup

Open World Forum

Paris, October 31, 2014

Supply Chains with Built-In License Compliance 2

Warm up questions (head)

• Who delivers software to other suppliers or end customers?

• Who provides license information with that? In which format

• How is this license information created?

• Who just copies the license information provided by suppliers?


Warm up questions (tail)

• Who receives software from suppliers?

• Who receives license information from suppliers? In which format?

• Who is verifying the received license information? How?


• Different formats

• Unpredictable quality

• Duplicate efforts

• No trust

Inefficient, ineffective

High Risk

Today

Compliant?


The Fantec Case

• GPL violation discovered

• Source code was made available, but not the “corresponding” version

• Fantec argues

• Chinese supplier asserted that delivered source code was complete

• Effective verification of completeness only possible by copyright holder

• Source code assessments are costly but no warranty that results are complete and

correct

• The Court says

• Fantec was required to ensure the GPL obligations are fulfilled for their delivery

• Fantec acted negligently by relying on its suppliers

• Fantec was required to assess, the software by themselves or

by a competent 3rd party, even if this meant additional cost


Creating/verifying the

same information

over and over again

is not

an (efficient) option

But…


What do we need to fix this?

Standardization (Format and Process)

+

Trust (Process and Capabilities)


Good news: we already have a standard format

• File based license data

• Information about a composition (a.k.a. hierarchy)

• Information about architecture (linking, communication, etc.)

• Composition license data -> concluded licenses

• Information about how the data was created

11Copyright Linux Foundation 2014 (CC-BY-3.0)V2.13 [spec v1.2]

Software Package Data Exchange® (SPDX®)

� A standard format for communicating the components,

licenses and copyrights associated with a software

package.

� Key pillar in Linux Foundation’s Open Compliance

Program which comprises:

� Tools, Self-Assessment, SPDX, Rapid Alert System, Training, Community


The Need

software in

Our suppliers aren’t giving us complete

licensing information for open source packages.

Every customer wants a bill of materials in a

different form.

I don’t mind vetting our code, but I’m sure this imported package has been analyzed a dozen

times before.

software out


How much of a problem is it?

How important is an industry standard for exchanging software BOMs?


The SPDX License List

SPDX® license repo • List of most common licenses (300+)• Include common exceptions• Standardized license names• Exact text of licenses• Available on SPDX® website – URLs

won’t change• License Matching Guidelines

used for the purposes of matching licenses against those included on the SPDX License List

• License Templates• denote license text which is

optional or replaceable per the license matching guidelines


The SPDX Document

Package identification, copyright and licensing

Text of licenses that are not in SPDX License List

SPDX Version and Licensing

Log of 3rd party reviews

File is in RDF/XML or tag value form and can be

converted to/from spreadsheets.

Document Information

Creation Information

Package Information

File Information

Licensing Information

Review Information

How and when created

File by file identification, copyright and licensing


Support Forms: RDF & Tag ValueSpreadsheet thru translation


Status

� Version 1.1– August 2012

� Version 1.2– October 2013

� Version 2.0– RC1 next month, release Feb 2015

http://www.spdx.org


New in 2.0Referencing Other SPDX Files

� Each SPDX Document has

a unique identifier

� Elements within a

document may have an

identifier unique to the

SPDX document (e.g. File,

License, Package)

� Elements in external

documents are referenced

using the document unique

ID:Ref

SPDX Document A

….

SPDXDocumentId

XYZ…

…

File abc/def SdxRef-

201

…

SPDX Document B

….

SPDXDocumentId ABC…

…

ReferencesDoc docA I

d: XYZ…

…

SdxRef-12

File: zzz/yyy

ReferencesFile

docA:SpdxRef-201

…


Adoption

� License List

� Internal: TI, Wind River, MicroFocus, HP, Siemens

� Tools: Black Duck, FOSSology, nexB, Protecode

� Community: OSI, Debian, Composer, Bower, NPM

� Format

� TI, Wind River, Alcatel Lucent, Siemens, OpenChain?

� Tagging Files

� U-Boot, Wind River

� Tooling

� Wind River, Black Duck, Source Auditor, FOSSology/UNO, Yocto, TripleCheck, SPDX OSS


Participants

Systems

OS Distributions

Applications

Integration & Services

Device OEMs

End-Users

Semiconductor Vendors

Open Source Organizations

…and others

Participation is from a range of organizations and across various roles


Getting involved…

� See:

� http://www.spdx.org

� Mailing lists, meetings, wiki

� Contact:

� Phil Odence (Chair) - [email protected]

� Kate Stewart (Tech Team Chair) - [email protected]

� Jilayne Lovejoy (Legal Team Co-Chair) - [email protected]

� Paul Maddick, (Legal Team Co-Chair) - [email protected]

� Jack Manbeck (Business Team Co-Chair) - [email protected]

� Mikael Söderberg (Business Team Co-Chair) -

[email protected]


SPDX is (almost) perfect – but is it enough?

• No quality standards for the license data

• Defined creation process and rules

• Verification requirements

• No standardization of license obligations fulfillment

• Who does what when and how

• No/limited collaboration

• Qualified FOSS management experts rarely work together beyond company

boundaries

• License data is not developed and maintained the “Open Source way”

What works for code can also

work for license data…


No Legal Advise

Only the data


What about a Community of Trusted Suppliers

• All members maintain a sufficient FOSS management maturity

• Adequate policies, processes, tools

• FOSS supplier management

Sufficient maturity level is a prerequisite for community membership

• Members jointly create a growing pool of reliable and reusable license data

• Members share the license data they have created for their deliveries (source or

binary, components or complete works) by uploading it to the community

repository

• License data provided AS-IS, no warranty, liability

• Whenever any code delivered by a member is reused in the supply chain, the

associated license data is retrieved from the repository and is reused, too

• Duplicate efforts can be avoided


What about having license data managed independently?

• License data is created and actively managed by an independent party

• Operational license compliance tasks are available as a service, e.g.

• Upload license text � receive a permanent URI for use in file headers, etc.

• Upload source code � receive a permanent URI pointing to file based license and

copyright data (Bill of Materials) in SPDX format, and permanent URI(s) for the

uploaded source files

• Creation of FOSS disclosure documentation for source code

• Provision of corresponding source code

• Certified/trusted provider, full transparency

• Economy of scale

• Certification, indemnification options

License compliance becomes built into the supply chain


License Data

Cloud

License data travels seamlessly with the code

Compliant!


Contact

Claus-Peter Wiedemann

Senior Manager

BearingPoint

Erika-Mann-Str. 9

80636 München

Germany

[email protected]

T +49 89 54033 6367

F +49 89 54033 7940

M +49 172 2757415

www.bearingpoint.com

L. Philip Odence

Vice President and General Manager

Black Duck

8 New England Executive Park

Burlington, MA 01803

USA

[email protected]

T +1 781 810 1819

M +1 781 258 9502

www.bearingpoint.com

owf14 - open source & software supply chain

Data & Analytics