This Webcast Will Begin Shortly
If you have any technical problems with the Webcast or the streaming audio, please contact us via email at:
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 [email protected]
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