SPDX® SOFTWARE PACKAGE DATA EXCHANGE® SPDX Overview for American Bar Association Brad Edmondson, SPDX Legal Team Volunteer March 2nd, 2017

Software Package Data Exchange® (SPDX®) Open-Source Software (OSS) vs. Proprietary Various open-source licenses out in the wild Permissive, “copy-left” (share-alike), “open-source-like” (in-between) Friction in open-source licensing just like friction in all IP licensing SPDX as a Linux Foundation project Run like an open-source project (transparent and consensus-based) Project itself is open-source (both content and tools/software) Just accepted to Google Summer of Code 2

What is SPDX? SPDX Specification: SPDX License List: SPDX Group: SPDX is a standard format for communicating the components, licenses and copyrights associated with a software package. Key pillar in Linux Foundation’s Open Compliance Program: https://www.linuxfoundation.org/offerings/open-source-compliance SPDX License List: Known, recognizable open-source (and open-source-like) licenses SPDX Group: With the Linux Foundation, participation from over 20 organizations including software, systems and tool vendors, consultants and foundations SPDX is a standard format for communicating the components, licenses, and copyrights associated with a software package SPDX is about identifying licenses that exist in software packages, not recommending licenses or making legal conclusions about licenses 3

What is SPDX? SPDX mission statement: https://spdx.org/about Develop and promote adoption of a specification to enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance. SPDX is about identifying licenses that exist in software packages, not recommending licenses or making legal conclusions about licenses 4

What is SPDX? Guiding principles: Goals: History: Human and machine readable Focus on capturing facts; avoid interpretations Common vocabulary Goals: Reduce redundant work in determining software license information and facilitate compliance throughout the software supply chain Reduce friction in the open-source software supply chain History: Started before 2010 as grass-roots effort by corporate counsels, business leads, and FOSS release managers responsible for compliance Now a Linux Foundation project 5

The Need Software Products Include Source Code from Many Different Sources Outsourced Code Development Internally Developed Code Commercial 3rd-Party Code Code Software projects are often made up of a rainbow of code licenses, with complex interactions among them Open Source Software Your Application Obligations YOUR COMPANY – TOOLS, PROCESSES 6 Diagram Source: Black Duck Software 6

The Need Scope of the Problem Software distributors need to provide license information for millions of lines of code to customers in the software supply chain, who often require detailed software copyright and licensing information for their own risk management. Software distributors (and users) need to be able to review the contents of each included package to ensure compliance with all of the licenses contained within it. A package’s declared license may not always match the license of every individual file inside the package. Similarly, a package with no top-level license assertion may consist of many files, each with a different license. Need a standard way to refer to the legal compliance “bill-of-materials” of a software package so we can efficiently exchange that information with others and accurately evaluate it for ourselves. In order to comply with licenses and otherwise assess your product's outbound license compatibility with any licenses of third party (eg. OSS) code included with it, you need to know what it contains. Software “bill of materials” == “packing slip” for software contents 7

The Need Software Supplier’s Point of View I don’t mind vetting our code, but I’m sure this imported package has been analyzed a dozen times before. Our suppliers aren’t giving us complete licensing information for open source packages. Every customer wants a bill of materials in a different form. software in software out 8

The Need The Challenge of Open Source Compliance New code OSS Package OSS Package OSS Package License B License C License A One OSS Package = Many Licenses License D License E License info for OSS is not provided in a consistent, easy-to-use format OSS Package License A License B License C License D License E 9

The Need The Challenge of Open Source Compliance Your code Software Bill of Materials (BOM) OSS Package ? OSS Package Companies combine OSS with other software Outsourced SW Creating an accurate bill of materials requires effort & research 3rd party SW 10

The Need The Challenge of Open Source Compliance Supplier 1 Customers Compliance effort is repeated at each step in the supply chain Open Source Organizations End-Users Integration & Services Device OEMs Applications OS Distributions Systems Semiconductor Vendors Supplier 3 Supplier 2 11

SPDX is (Part of the) Solution SPDX Specification: A file format for license information to accompany open-source software packages Benefits Easy exchange of license information between organizations, reducing burden on both suppliers and consumers Reduce due diligence work when the same license or the same source code (software package) is analyzed again and again Support a common vocabulary for software developers, compliance managers, open-source counsel, and extend that vocabulary to the tools they use to manage compliance, ultimately yielding better compliance with less effort At time of product delivery, SDPX document shows that developer has done due diligence on the code they’ve used and know what licenses are included. Aim to establish a trusted document that can be communicated up and down the software supply chain so that compliance staff within that supply chain don’t have to re-read and re-evaluate each license. “De-duplicate due diligence drudgery” with SPDX! 12

SPDX Specification Instructions for collecting, storing and communicating data Goal to be human and machine readable Focus on facts (not interpretations) Version 2.1 in Sept 2016 Associated tooling/software Document Creation Information Package Information Package Information Other Licensing Information File Information Other Licensing Information Other Licensing Information Other Licensing Information Specification has different sections that describe the fields for that section For license, copyright, provenance information at package, and file level Can reflect package hierarchy through relationships Information about creation of SPDX document There are 2 standard document formats: Tag value and RDF there are tools available for producing, translating between these two supported formats, spreadsheet and other human-readable format (.txt, HTML); comparison tool, verification tool With 2.1 we are starting to get Python tooling up and going Focus now on documentation, best practices, and real world examples Relationships Other Licensing Information Annotations

SPDX reflects package relationships SPDX Document MQ Apache Apache MQ package contains cont’d by Jetty Web Container package Jetty Web Container contains cont’d by javax.servlet javax.servlet package 14

SPDX License List https://spdx.org/licenses/ Current version: 2.6 (Q1 2017) Over 300 Licenses Short IDs for easy reference Exact text of licenses Includes commonly used exceptions Continuously Maintained: Always available in human- and machine-readable formats Actively updated by SPDX Legal Team with new licenses https://spdx.org/licenses/ 15

Example License: BSD 2-Clause License Matching Guidelines For matching licenses against those included on the SPDX License List License Templates Exact text of licenses Markup denotes optional and replaceable text per the matching guidelines Formats Available in numerous human- and machine-readable formats Recently moved to GitHub to make contribution easier 16

SPDX Short License Identifiers Simple File-level License Identification Incorporate a specific license by reference with a single line (rather than writing out the full license text in every source file Easy to use, concise format and easy to read Reliable & Machine Readable Use SPDX license identifier to precisely match identifiers to license text Easy to produce an SPDX document for a given software package Flexible license expression syntax AND, OR, WITH, + Represent licenses with exceptions, multiple applicable licenses, choice of license, license version X and later SPDX license identifiers (which match specific license texts) SPDX license expressions (which show how the licenses combine for a given file/package/work) are also thought of as part of the “license list” SPDX helps organizations in the software supply chain represent complex license collections, building from the bottom up Note: “short identifier” in code can actually be an expression - it's just historical accident that they're called "License-Identifier" Valid SPDX expressions: (LGPL-2.1 OR MIT OR BSD-3-Clause) (LGPL-2.1 AND MIT) (GPL-2.0+ WITH Bison-exception-2.2) 17

Using Short Identifiers in Source Code 18

SPDX in action Generating or consuming SPDX documents “Bill of materials” for any given software package Using authoritative license text from SPDX License List Using of SPDX license identifiers (and expressions) in source code Using other SPDX specification fields in internal systems

What SPDX Means to You Embedded & SW Supply Chains Save Time/Money Better Compliance Open Source Developers Help Users Comply With Your Licenses Consumers of SW & OSS Understand Licensing of the Code You Use 20

SPDX Adoption License List: Format/Specification: Tagging Files: Internal: ARM, TI, Wind River, MicroFocus, HP, Siemens, Qualcomm, Valeo Community: OSI, Debian, Composer, Bower, npm, RubyGems Format/Specification: Internal/Partners: TI, Wind River, Alcatel Lucent, Siemens, Qualcomm Tagging Files: ARM, Linux kernel, U-Boot, Wind River, Node.js (coming soon) Tools: Open-source: FOSSology/UNO, Yocto, ScanCode, SPDX OSS, SPDX npm tools Proprietary: Wind River, Black Duck, nexB, Source Auditor, Protecode, TripleCheck 21

SPDX Resources Main SPDX project: https://spdx.org/ SPDX General Meeting: http://wiki.spdx.org/view/General_Meeting SPDX Tech Team: https://spdx.org/WorkgroupTechnical SPDX Outreach Team: https://spdx.org/WorkgroupOutreach SPDX Legal Team: https://spdx.org/legal-team Wiki for minutes, project tracking, and decision-making: http://wiki.spdx.org/ Using SPDX: Generated files in various formats (for tools): https://github.com/spdx/license-list-data https://spdx.org/tools SPDX Legal Team’s “master files” for generating supported formats: https://github.com/spdx/license-list 22

Get Involved in SPDX SPDX Legal Team SPDX License List: Members include Linux Foundation project staff, attorneys working in-house with open source, as well as attorneys whose firms regularly advise clients on open-source. A handful of software engineers also support the legal team. Overview: https://spdx.org/participate/legal-team Legal Team projects page: http://wiki.spdx.org/view/Legal_Team Legal Team mailing list: https://lists.spdx.org/mailman/listinfo/spdx-legal SPDX License List: Updating and maintaining the SPDX License List is the primary charge of the SPDX Legal Team: https://github.com/spdx/license-list Those willing to “do” can influence direction Just accepted to Google “Summer of Code” intern- mentoring program Face to face meetings at Linux Foundation and other events Don’t need a legal or a technical background, just have to want to help Opportunities: review proposals to add licenses to the list; review or add markup to existing licenses; assist with developing the spec further to e.g. handle translations Opportunities: Encourage your Developers, Testers and Writers to help with the Open Source based tools working with SPDX. Low-lift: when you help clients purchase software, ask for an SPDX document (or other BOM) to get assurance that the vendor has done its compliance due diligence 23

Thank you! Questions? Contact: brad.edmondson@gmail.com Twitter: @brad_edmondson GitHub: https://github.com/bradleeedmondson Questions? Note: This information was adapted from publicly available documents and represents my personal views. I am a volunteer contributor to the SPDX Legal Team and do not officially represent the Linux Foundation, OSI, or any other organization mentioned herein. SPDX® is a registered trademark of the Linux Foundation. 24