How to Create an Enterprise Open Source License Compliance Program

How to Create an Enterprise Open Source License Compliance Program Webinar on June 23, 2010 Presented by Greg Bell, Marketing Manager with OpenLogic and Heather Meeker, Managing Shareholder with Greenberg Traurig LLP

About OpenLogic OpenLogic is an open source provider and aggregator. We enable enterprises to successfully and safely acquire, deploy, support and control all of the free and open source software they use. Provisioning Governance Support Services © Copyright OpenLogic 2009

OpenLogic’s Scanning & Compliance Products Services Largest fingerprint Application Audit repository Bill of Materials, Bill of 330K+ unique packages Licenses, Obligations & 6 Billion lines of code Conflicts Warranty/Indemnification on OLEX results OSS Discovery – binary scanning M&A Audit OSS Deep Discovery – deep Application Audit source scanning Certification of Compliance License obligations and Steps conflicts OSS Fulfillment Center Managed Compliance Web Site © Copyright OpenLogic 2009

[ June 23, 2010 ] Best Practices for Open Source Compliance Sponsored by Open Logic Presented by Heather J. Meeker GREENBERG TRAURIG, LLP ▪ ATTORNEYS AT LAW ▪ WWW.GTLAW.COM ©2008, Greenberg Traurig, LLP. Attorneys at Law. All rights reserved.

Best Practices for Open Source Compliance What is open source? ■ Software licensed under the Open Source Definition ■ http://www.opensource.org/osd.html ■ Main points: » Provided in source code form » Royalty-free right to modify and re-distribute » No discrimination against persons or fields of endeavor ■ Not the same as “proprietary” (i.e. closed source) ■ The “viral” and the “non-viral” » Viral a.k.a. reciprocal, free software, copyleft, hereditary » Non-viral a.k.a. permissive [Date] [ Presentation to [Client] ▪ 2 ]

Best Practices for Open Source Compliance What is copyleft? ■ If you distribute, you must provide source code ■ If you distribute you must use the same license ■ NOT a requirement to contribute back to the original code base ■ Use and modification is not restricted ■ Beware what constitutes distribution [Date] [ Presentation to [Client] ▪ 3 ]

Enforcement and Risk

Best Practices for Open Source Compliance Risk Assessment ■ Compliance is not about perfection; it is about risk reduction ■ Two kinds of risk: Infringement and compliance » Open source licensing vs. open source development model ■ Major risks include: » Copyright Infringement damages (probably statutory) » Injunction (orders halting product distribution) » Reduction in value of patent portfolios » Bad PR » Engineer relations problems » Shareholder derivative suits ■ They probably do not include: » Court orders to disclose source code [Date] [ Presentation to [Client] ▪ 5 ]

Best Practices for Open Source Compliance Enforcement Landscape: The Dawning of a New Age ■ Artifex v. Palm et al (2009, ongoing) ■ Artifex v. Premier Election Solutions (Diebold) 2008 ■ FSF v. Linksys claims (2003), FSF v. Linksys (2008-9) ■ Jacobsen v. Katzer (Fed. Cir. Opinion 2008, District Court order 2009, settled 2010) ■ Busybox cases. ■ Progress/NuSphere v. MySQL. ■ gpl-violations.org v. Fortinet and others (2005) ■ Jin v. IChessU (settled Israeli case) Bring on the copyright trolls! [Date] [ Presentation to [Client] ▪ 6 ]

Best Practices

Best Practices for Open Source Compliance Open Source Policies ■ Written policies are most useful for: » Large organizations with siloed development » Organizations using outsourced or overseas development » Organizations seeking to manage open source “spin” ■ What should your policy cover? » Use of open source that is approved or requires approval » Approved licenses, if applicable » Open source requirements for vendors (e.g. warranties) » “Reversioning” or contributions – by employees or company » Scanning, if you decide to scan [Date] [ Presentation to [Client] ▪ 8 ]

Best Practices for Open Source Compliance Code Scanning ■ What does scanning do? » Objective identification of open source in a code base » Compare package-level record-keeping » Surveys vs. title searches » Produces information ■ What does scanning not do? » Analyze the information » Make legal/risk management decisions » Analyze integration issues (e.g. for GPL) » This requires human intervention [Date] [ Presentation to [Client] ▪ 9 ]

What do I tell the Engineers?

Best Practices for Open Source Compliance Basic Housekeeping ■ Print out and retain the license information at the time you download the software » Backtracking doesn’t always work because: » Open source projects change their licenses » You may wish to take the code under an earlier version than the current one ■ Double check that the license terms in the source distribution match the ones described on the project web site ■ If you cannot identify a license, ask legal to identify it for you ■ Document all changes to open source modules [Date] [ Presentation to [Client] ▪ 11 ]

Best Practices for Open Source Compliance How to help your company stay compliant ■ Don’t change or eliminate existing comments in headers ■ Document compliance information in your build instructions ■ Do not check copyleft code into any source tree without authorization ■ Avoid re-naming open source modules ■ Talk to your legal department if a module you want to use has a license that is too restrictive – they may be able to re-license it for you. [Date] [ Presentation to [Client] ▪ 12 ]

Best Practices for Open Source Compliance Reversioning ■ Do not send modifications to any public source tree without notifying your legal department and getting permission first ■ Making even small contributions without your company’s permission can compromise your company’s IP (due to implicit or explicit patent licenses) ■ Do not discuss kernel coding with persons outside the company (legal analysis of this topic is very sensitive) [Date] [ Presentation to [Client] ▪ 13 ]

Best Practices for Open Source Compliance How to help your company stay compliant ■ Good programming practices are also legal best practices: clean integration, modularity, minimization of data sharing, transparent APIs ■ Carefully document the interfaces between any code you are writing in kernel space and the Linux kernel or other GPL code. Use schematics and structure diagrams. ■ Be your company’s eyes and ears: what are competitors and other industry players doing? [Date] [ Presentation to [Client] ▪ 14 ]

Compliance for Distribution

Best Practices for Open Source Compliance Notices ■ Most open source agreements require the placement of copyright or other notices on your product ■ The site for the notices differs among agreements: » Source files » Documentation » On the product itself (meaning may change in context) ■ Your company will need your help aggregating notices ■ You will need a policy as to how notices will be placed [Date] [ Presentation to [Client] ▪ 16 ]

Best Practices for Open Source Compliance Compliance with permissive licenses ■ Permissive licenses » Apache 1.0, 1.1, and 2.0 » BSD » MIT ■ Few compliance issues except notice ■ Beware of “advertising requirements” ■ Some “viral” licenses looks like permissive licenses, so be careful [Date] [ Presentation to [Client] ▪ 17 ]

Best Practices for Open Source Compliance Basic GPL Compliance ■ Use GPL code only as separate programs or processes ■ Do not link to GPL code ■ Notices ■ Offer for source code or source code distribution [Date] [ Presentation to [Client] ▪ 18 ]

Best Practices for Open Source Compliance LGPL Compliance ■ Use LGPL code only as a dynamic link library ■ Do not use macros or in-line functions of over 10 lines from LGPL library in non-LGPL code » “If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work.” ■ Be careful about smart compilers that make linking and in-line decisions for you ■ Notices ■ Offer for source code or source code distribution [Date] [ Presentation to [Client] ▪ 19 ]

Best Practices for Open Source Compliance Compliance with “corporate-style” licenses ■ “Corporate-style” hereditary licenses » Mozilla Public License (MPL) » CPL » Eclipse » CDDL ■ Segregate code in separate files ■ Document all changes ■ Particular licenses may have additional compliance concerns ■ Scope of patent licenses and patent termination provisions varies [Date] [ Presentation to [Client] ▪ 20 ]

Best Practices for Open Source Compliance Compliance with “Affero-type” licenses ■ “Affero-Type” licenses » Affero GPL » CPAL (has branding requirements) » Academic Free License » Open Software License ■ Many companies will not use code under these licenses ■ Applies copyleft to network usage (ASP/SAAS/Cloud Computing) [Date] [ Presentation to [Client] ▪ 21 ]

Best Practices for Open Source Compliance Major Issues Addressed in GPL3 ■ GPL3 became effective June 29, 2007 ■ For a copy of the license, go to http://gplv3.fsf.org/ ■ The “ASP Problem” ■ The Derivative Works Problem ■ The Patent Problem ■ The “Tivoization Problem” [Date] [ Presentation to [Client] ▪ 22 ]

Fixing Problems

Best Practices for Open Source Compliance I’ve found a problem − now what? ■ Remove » Lots of code bases contain code that is not used (like “junk DNA”) ■ Replace » More permissive or proprietary alternatives can be easy to find ■ Reengineer » Only applicable for hereditary licenses » “Shimming” usually does not work ■ Re-license » Dual licensing » Private re-licensing » Version backtracking (most applicable to GPL/LGPL 3 issues) [Date] [ Presentation to [Client] ▪ 24 ]

Best Practices for Open Source Compliance Fixing Problems Case Study 1: Commercial dual licensing ■ Target was using RED5 (open source flash server licensed under LGPL2) and wanted to replace it with Adobe Blaze DS (licensed under LGPL3) for technical reasons on the eve of the acquisition » Acquiror would not accept GPL3 » Resolution: □ We found a commercial version of Blaze licensed under commercial terms □ We deducted the license fees (based on current use) from the purchase price □ Acquiror approved additional fees necessary for ramp- up after acquisition [Date] [ Presentation to [Client] ▪ 25 ]

Best Practices for Open Source Compliance Fixing Problems (continued) Case Study 2: Commercial Substitute ■ Target was using Octave (math library licensed under GPL) statically linked » Resolution: □ We found a commercial product (MATLAB) with similar functionality and minimal license fees □ We required re-licensing as a closing condition [Date] [ Presentation to [Client] ▪ 26 ]

Best Practices for Open Source Compliance Fixing Problems (continued) Case Study 3: Private Re-licensing ■ Target was using FRIBIDI (an implementation of the Unicode Bidirectional Algorithm (bidi) licensed under GPL) and linking to proprietary code. » Resolution: □ We found the author and entered into a one-off binary license for about $10,000 □ In this case, acquiror absorbed the fee □ This works best for individual authors □ Will not work for most large projects or projects with “faith-based” licensing. Note that FRIBIDI has since become a GNU project. [Date] [ Presentation to [Client] ▪ 27 ]

Best Practices for Open Source Compliance CV on Open Source ■ Author of The Open Source Alternative, John Wiley & Sons, 2008 ■ Advised Mozilla on redraft of MPL ■ Advised Autodesk on OSGEO Foundation formation and CSMAP code release ■ Advised Mozilla on marketing agreement for Firefox search defaults ■ Drafted Firefox EULA for Mozilla Foundation ■ Advisor for open source issues to Yahoo, Autodesk, Avaya, Amazon.com, Ebay, Vuze, Serena, TIBCO, LSI Logic, Pace Micro, Insightful, Sony, Nintendo, Hulu [Date] [ Presentation to [Client] ▪ 28 ]

Best Practices for Open Source Compliance CV on Open Source (continued) ■ Advised Yahoo! on Associated Content, Maktoob, Zimbra, Right Media, Inquisitor, and other acquisitions ■ Advised on open source and intellectual property matters in Network Associates' acquisitions of Intruvert Networks, Entercept Security Technologies, Deersoft, and Traxess, 2002-2003 ■ Prepared trademark and patent policies, contribution policies, and licensing strategies for Active Endpoints, Alfresco Software, Cobia (StillSecure), Jahshaka, Boingo, Centeris, Digium, Second Life [Date] [ Presentation to [Client] ▪ 29 ]

Best Practices for Open Source Compliance CV on Open Source (continued) ■ Counseled Mozilla Foundation, Open Source Applications Foundation, GNOME Foundation, Python Software Foundation ■ Advised Lucas Arts on initiating OpenEXR open source code release ■ Member of Open Bar Advisory Board ■ Former Chair of Open Source committee for ABA ■ Advisory Member for ALI project on the Law of Software Contracts [Date] [ Presentation to [Client] ▪ 30 ]

How to Create an Enterprise Open Source License Compliance Program

by OpenLogic on Oct 22, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

How to Create an Enterprise Open Source License Compliance Program — Presentation Transcript