Managing OSS license obligations

Managing Open Source Obliga1ons

Agenda •  Introduc1on •  Iden1fy the ten most common open source license obliga1ons

•  Explain what you need to do to comply with these obliga1ons

•  Discuss the key compliance challenges today •  Outline an approach for automa1ng compliance •  Describe compliance automa1on case studies – Android and DejaCode

•  Ques1ons


Ten Most Common OSS License Obliga1ons •  Copyright no1ces •  License no1ces •  AFribu1on requirements •  “CopyleI” obliga1ons (licensing of deriva1ve works) •  Source code licensing •  Source code delivery •  Build and installa1on instruc1on delivery (GPL) •  No1ce of changes •  Indemni1es •  Non-‐use of trademarks


How to Comply – No1ces •  Copyright, license, modifica1on, and aFribu1on requirements

•  Delivery of source code may be the easiest way to comply, because no1ces are “baked in” to distribu1on package

•  Binary delivery requires crea1on of no1ce files •  No1ces must be in the product delivery, for most licenses

•  Online delivery is usually not sufficient •  Relying on third party no1ces is usually not sufficient


How to Comply – Source Code •  For GPL, LGPL, and other copyleI licenses •  Source materials must be made available, but not necessarily delivered with product

•  Not necessary to post source materials on the web, but this is a good prac1ce


How to Comply -‐ Licenses •  Need to carve copyleI licensing requirements from EULAs

•  GPL, LGPL and other licenses cannot be changed to other terms

•  “Weak copyleI” licenses like EPL, MPL allow bifurcated licensing of source and binaries


Key Compliance Challenges •  Tracking open source use •  No1ce crea1on •  No1ce delivery •  Build and installa1on instruc1on delivery •  Ensuring the source code is right for the build


Compliance Automa1on Star1ng point is a good baseline analysis •  Origin and license of open source components •  Which open source components are Deployed Then you need prac1cal ways to: •  Enable and encourage the engineering team to keep origin and license data current, and

•  Use that data to create compliance deliverables, and •  Audit a new release efficiently, and •  Repeat the process


Compliance is easier than you think Establish simple policies – “Highest common requirement” for: •  AFribu1on text documenta1on and display •  Source code Redistribu1on •  Change documenta1on •  Non-‐endorsement / trademarks ALWAYS keep original copyright and license no1ces with the codebase (in files or directories)


Compliance is easier than you think Add a simple system to track license data that: •  Can be adapted to exis1ng engineering processes

– Engineers can use and update the data during normal soIware development ac1vi1es

–  Independent of programming languages or tools •  Can produce data for:

– Delivery to customers as • AFribu1on and Redistribu1on packages •  SPDX (SoIware Package Data Exchange) files

–  Import into enterprise systems


SoIware Package Data Exchange® •  A standard format for communica1ng the components, licenses and copyrights associated with a soIware package

•  Allows easy exchange of license informa1on between companies reducing burden on both suppliers and consumers

•  A Working Group of the Linux Founda1on •  Part of Linux Founda1on’s Open Compliance Program

www.spdx.org


Component Metadata •  Add one text file per soIware component at the level

necessary to document the origin, license and obliga1ons for the component

•  Typically a text or XML file with “tag / value” format, such as:

COMPONENT: Myarchive VERSION: 1.2.3 LICENSE_NAME: MIT LICENSE_TEXT: (text goes here……) ATTRIBUTION_TEXT: (if different from license text) LICENSE_FILE: myarchive.LICENSE SOURCE_REDISTRIBUTION: yes/no USAGE: Internal only


Basic Automa1on •  Use script-‐style programs to read Component

Metadata file and •  Create an AFribu1on text file •  Create a Redistribu1on package list

•  Edit the files to remove components that are not Deployed

•  Add the AFribu1on text file to the product documenta1on and(or) product GUI (Help / About)

•  Assign an engineer to create the Redistribu1on package and installa1on/build instruc1ons


Advanced Automa1on Enhance the build system and tools to:

•  Recognize Component Metadata files •  Assemble Component Metadata files during a build for components included in an end-‐product (Deployed)

•  Collect AFribu1on data for Deployed components and create AFribu1on text file

•  Insert AFribu1on text into GUI (Help / About) •  Collect source code for the components that require Redistribu1on (including dependencies)

•  Create an archive file of the Redistribu1on package


AndroidTM Case Study •  Android project applies an advanced approach to automate OSS compliance

•  Several types of metadata files added to the project codebase

•  Build system can use these files to create AFribu1on text and Redistribu1on packages based on Deployed components


The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

Android Metadata •  MODULE_LICENSE_xxx marker files

•  MODULE_LICENSE_APACHE2 means the directory is Apache 2.0-‐licensed

•  Approx. 500 such files in Android 4.1 – Jelly Bean •  NOTICE files

•  Co-‐located with MODULE_LICENSE marker files •  Contains license and other aFribu1on text •  Created by the original OSS project or by Android team •  Plus keep all original no1ces


Android Tools •  Tools in the Android build system:

•  Create aFribu1on no1ces from and display them in the Android UI

•  Collect source code and create archives for redistributable source code

•  AFribu1on and Redistribu1on packages are based on the actual subset of code Deployed as determined by the build system


Android Compliance Deliverables •  AFribu1on text is delivered on the phone or tablet as an HTML file located at Seongs / About… / Legal Informa1on / Open Source License –  (You can check this now)

•  You can see examples of Android compliance packages for Motorola Mobility phones and tablets

•  Source code packages are provided at: –  hFp://sourceforge.net/motorola/wiki/Android/ –  (Metadata files are inside each code package)


DejaCodeTM Case Study •  nexB has developed a basic specifica1on and corresponding tools to automate compliance •  Based on ABOUT files for Component Metadata •  Applicable to any programming language and soIware development environment

•  Extensible to build system integra1on for advanced approach •  Tools licensed under Apache 2.0


ABOUT File Example hFpd-‐2.4.3.tar.gz.ABOUT name: Apache HTTP Server home_url: hFp://hFpd.apache.org download_url: hFp://apache.belnet.be//hFpd/hFpd-‐2.4.3.tar.gz version: 2.4.3 date: 2012-‐08-‐21 license: apache-‐2.0 license_file: hFpd-‐2.4.3.tar.gz/LICENSE copyright: Copyright 2012 The Apache SoIware Founda1on. no1ce_file: hFpd-‐2.4.3.tar.gz/NOTICE


DejaCode compliance tools •  Based on Component Metadata in ABOUT files •  Creates OSS inventory on demand (spreadsheet) •  Creates AFribu1on text file

•  Text file organized by copyright/license no1ce and component

•  Default text or HTML format •  Creates source code Redistribu1on package list


DejaCode.org •  nexB is sponsoring DejaCode.org as a community site to share techniques and tools for automa1ng compliance with OSS obliga1ons

•  Documenta1on of exis1ng techniques and tools from Android, Apache Maven (Java), CPAN (Perl) and others

•  Home for new projects like nexB’s ABOUT system •  Visit us at:

www.dejacode.org


“Virtuous” compliance lifecycle •  Complete baseline codebase analysis for a product •  Generate/create Component Metadata files in the codebase from baseline analysis findings

•  Update Component Metadata files during release development

•  Confirm Component Metadata changes and/or iden1fy addi1onal changes with an audit

•  Regenerate compliance deliverables using the Component Metadata files

•  Repeat…


Ques1ons Managing Open Source Obliga1ons

About Greenberg Traurig LLP •  GT is an interna1onal, mul1disciplinary law firm in 35 loca1ons in the United States, La1n America, Europe, the Middle East and Asia.


•  An Interna1onal Network of More than 1,750 AForneys & Governmental Affairs Professionals

About nexB Inc. •  nexB offers:

–  SoIware analysis/audit services for acquisi1ons and for products

–  DejaCode Enterprise – a central business system for managing soIware components

•  200+ soIware audit projects completed to-‐date –  Aggregated audited codebases > 3 billion lines of source code –  Aggregated value of the acquisi1ons transac1ons > $5B

•  See the DejaCode License Library at www.dejacode.com


Contacts •  Greenberg Traurig

Heather Meeker [email protected]

•  nexB Inc. Michael Herzog [email protected] +1 650 380 0680


Date post:	05-Dec-2014
Category:	Technology
Upload:	nexb-inc
View:	912 times
Download:	0 times

Managing OSS license obligations

Technology