This Webcast Will Begin Shortly

If you have any technical problems with the Webcast or the streaming audio, please contact us via email at:

webcast@acc.com

Thank You!

Open Source Software: Practical Tips for the In-House Attorney

September 15, 2010

Presenters:

Michael S. Pavento, Esq. Kilpatrick Stockton, LLP

Ibrahim Haddad, Ph.D. Director, Technology & Alliances

The Linux Foundation

Moderator:

Doug Luftman VP & Chief Patent Counsel

CBS Interactive

What is Open Source Software? •  When software code is written, copyrights attach automatically. •  The terms and conditions under which the copyright owner

allows others to copy, modify and distribute the software code determine whether it is considered “free” and/or “open source.” –  “FOSS” = free and open source software.

•  Compliance with the applicable license terms is essential to avoiding copyright infringement.

•  Some FOSS licenses address patent issues, require attribution to prior authors, impose “copyleft” restrictions, and/ or require other kinds of actions.

3

FOSS Licensing - Copyleft •  “Copyleft”: instead of using copyright laws to withhold

permission to copy, modify or distribute software, FOSS licenses use those laws to require / perpetuate such permissions.

•  A typical “copyleft” condition is that any works derived from the licensed FOSS, if further distributed, must be subject to the same license conditions as the original FOSS.

•  FOSS licenses can have stronger, weaker or no copyleft provisions; they all generally aim to ensure that the licensed software can be modified, combined and built upon to create new works.

4

FOSS Licensing – Copyleft Examples •  GNU General Public License: a “strong copyleft” license;

requires derived works to be available under the same copyleft conditions, including release of all source code.

•  GNU Lesser General Public License, v2.1: applies to software libraries; a “weak copyleft” license; imposes copyleft requirements on modified versions of the licensed library, but not code that is compiled or linked with the licensed library.

•  Apache License, v2.0: a “non-copyleft” license; does not require modified versions of the licensed code to be distributed under the same license terms or even as FOSS.

5

FOSS Licensing – Derivative Works •  Derivative Works: FOSS licenses differ in how they define and/

or treat derivative works. –  Some licenses (e.g., GPL) do not define “derivative works”,

but licensors rely on expansive copyright law definition; other licenses (e.g., Apache) provide explicit and narrow definition.

–  Software linking: generally understood that static linking produces derivative works, but often not clear whether an executable that dynamically links to FOSS results in a derivative work. FOSS community seems to be split on this issue.

6

FOSS / Patent Interplay •  A desire for commercial leverage and for assets that can be

monetized drives many companies, including those that distribute FOSS, to seek software patents.

•  Some patent holders have issued general public pledges / covenants re: the use of FOSS.

•  A patent holder might also have granted an explicit (or implicit) patent license by contributing code to a FOSS project or distributing code under a FOSS license.

7

Examples of Problems That Lead to FOSS Compliance Issues •  Incorporating source code with unknown license and/or origin •  Incorporating source code into the build system before approval •  Mixing source code with incompatible licenses •  Linkage of source code •  Not providing appropriates notices (license, acknowledgment) •  Not providing written offer to make source code available •  Not providing complete and corresponding source code •  Ignoring compliance inquiries

8

FOSS Compliance - 3 Key Lessons •  Ensure compliance prior to product ship •  Non-compliance is expensive •  Compliance program is a must

9

Establishing a FOSS Compliance Program

Policies Processes

Teams Tools

Education

Usage

Automation

Contribution Distribution Auditing

Auditing Code Project Management

Inventory Management

Linkages Analysis

Code Inspection

Formal Training Guidelines Brown Bag Seminars

Obligations Fulfillment

Usage Contribution Distribution Auditing Obligations Fulfillment

Usage e-Form Contribution e-Form

Auditing e-Form Templates

Internal Web Portal

External Web Portal

Strategy

Core Team (OSRB)

Extended Team

Messaging Internal External

Compliance Strategy

Inquiry Response

Invited Speakers

Employee Orientation

Workflow

10

FOSS Compliance: End-to-End Process

Incoming Software

Iden

tific

atio

n

Aud

it

Res

olve

Issu

es

Rev

iew

s

App

rova

ls

Reg

istra

tion

Not

ices

Verif

icat

ions

Dis

tribu

tion

Verif

icat

ions

Proprietary  So,ware  

3rd  Party  So,ware  

FOSS  

Outgoing Software

Notices & Attributions

Written Offer

11

Incremental FOSS Compliance

Product V 1.0 Product V 1.1 Start of product development

Base  line  compliance   V  1.0  release  

V  1.1  release  

Incremental  compliance  

1.0  development  complete  

1.1  development  complete  

12

FOSS Compliance Best Practices: Scanning and Auditing Source Code •  Scan/Audit  everything  

–  Proprietary  code  –  3rd  party  code  –  Sample  code  –  Firmware    –  Open  source    

•  Scan  early  and  o>en  –  Iden@fy  BOM  deltas  (weekly)  

•  Tools  –  Scanning  tool  –  BoM  difference  tool  

•  Scan  newer  versions  of  previously  approved  packages    

•  U@lize  both  objec@ve  and  subjec@ve  informa@on    –  Objec@ve:    

•  Scanning  tool  –  Subjec@ve:    

•  OSRB  form      •  Interview  engineer    

–  Don’t  rely  solely  upon  any  one  form  of  informa@on  

–  Trust,  but  validate  

13

FOSS Compliance Best Practices: Identification and Resolution of Issues

•  Inspect each file or snippet flagged by the scanning tool

•  Identify if any code modifications were made

–  Don’t rely on engineers to remember if they made code changes

–  Use tools to identify code changes, who made them and when

•  When in doubt with scanning tool results:

–  Discuss with engineer owner of package

–  Code print original oss code and re-analyze

–  Contact scanning tool vendor to discuss

•  If you suspect a license violation: –  Report to engineer owner of

package and request correction –  Re-scan after resolving violation

to ensure compliance –  Work closely with legal

•  Document all license information –  COPYING, README, LICENSE

files, email exchanges, etc. –  Link to license information on

the project’s web site as well as relevant content from that web site

•  Rely upon strong senior executive support and escalation process

14

FOSS Compliance Best Practices: Legal Review

•  Contact OSS project when licensing information is: –  Not clear or –  Not available

•  Evaluate license compliance: –  Review Open Source

analysis report –  Review information provided

by OSRB technical member –  Review license information

(exercise additional due diligence if needed)

•  Legal Review – identification & resolution steps are iterative process –  If necessary, request

additional work from OSRB technical member to further analyze component or to rework code if needed

15

FOSS Compliance Best Practices: Linkage Analysis

•  Component-specific license analysis is NOT enough –  Need to understand the licensing inter-relationship (e.g., linking)

between the components •  Perform linkage analysis for each package in the build

–  Identify conflicts in licenses between source code and library(ies) linked

•  If conflict was found –  Report to Engineering and work closely with legal to resolve –  Re-scan after resolving linkage conflict and go through the process

again

16

FOSS Compliance Best Practices: Final Review and Analysis

•  Regular OSRB Meetings –  OSRB team meets once a

week –  Final review for requests

pending graduation –  Discuss flagged requests –  Seek continuous improvement

to the end-to-end analysis process

•  Record all discussions –  Summary of discussion and

decisions and logic behind decision making process is logged in the compliance ticket

•  Compile obligations and pass it to appropriate departments for fulfillment –  Update notices (device, sdk,

web, manual, etc.) –  Update list of obligations for

newly approved open source packages

•  Weekly report of OSRB activities and reviews

17

Responding to Compliance Inquiries

Acknowledge

Inform

Investigate

Report

Rectify

Improve

Incoming Inquiry

These steps are taken only if a violation was found

Close Inquiry

18

FOSS Litigation •  Vast majority of FOSS litigation has involved breach of contract / license or

copyright ownership / infringement claims. •  Jacobsen v. Katzer (Fed. Cir 2008): FOSS license conditions are enforceable

as copyright conditions (failure to comply constitutes copyright infringement). –  Copyright infringement claims bring statutory damages and injunctive relief into play.

•  Only in a few cases (likely less than 10) has FOSS been accused of infringing patent rights.

–  Patent infringement is unauthorized making, using or selling a patented product / process; does distribution of FOSS fit this definition?

–  Settlement of patent infringement claims is tricky b/c of need or desire to account for down-stream users.

–  Some FOSS license agreements (e.g., GPLv3) attempt to assure that patents cannot be used to render FOSS non-free.

19

The Linux Foundation Open Compliance Program: What It Will Accomplish

20

•  Increase awareness of compliance and help bridge disconnect between companies, legal community & developer community

•  Make it easier to comply with open source licenses •  Decrease legal FUD around Linux & open source •  Standardize aspects related to compliance across industries •  Increase the number of open source compliance tools and

provide a central place for them •  Provide a forum to continually improve the ease of adoption

within the software industry

Open Compliance Program Elements

21

Training

Tools

SPDXTM Self-

Assessment Checklist

Compliance Directory

FOSS Bazaar

Educational materials & classes

New and existing tools to help with compliance due diligence

Standardized reporting for licenses and BoM

A new benchmark to test against best practices

Contacts list and rapid alert system

A community to evolve compliance best practices

Open Compliance Program Elements •  Training

–  Executive Training (0.5 day) –  Compliance End-to-End

Management (1 and 2 days) •  Software Package Data

ExchangeTM Working Group –  A set of data exchange

standards to enable companies and organizations to share license and component information (metadata) for software packages

•  Compliance Directory –  Centralized compliance contact

information directory

•  Internal Self-Certification –  A checklist of best practices and

elements that must be present in compliance program to help ensure success

•  Tools All tools are released as open source projects; they provide a platform on which to innovate on open source compliance tools.

–  Bill of Material Difference Tool –  Dependency Checker Tool –  Code Janitor Tool –  Binary Analysis Tool –  FOSSology

22

Free Education & Free Tools Available

23

•  Education: http://www.linuxfoundation.org/programs/legal/compliance/training-and-education

•  Free tools: http://www.linuxfoundation.org/programs/legal/compliance/tools

Q & A

24

Thank you for attending another presentation from ACC’s Desktop Learning Webcasts

Please be sure to complete the evaluation form for this program as your comments and ideas are helpful in planning future programs.

If you have questions about this or future webcasts, please contact ACC at webcast@acc.com

This and other ACC webcasts have been recorded and are available, for one year after the presentation date, as archived webcasts at

http://webcasts.acc.com. You can also find transcripts of these programs in ACC’s Virtual

Library at http://www.acc.com/search/cfm