VIEWS: 2 PAGES: 18 POSTED ON: 8/13/2012
A “Nuts & Bolts” Session to Help Companies Manage Key Risks Associated with Open Source Software Gary Morris, Kenyon & Kenyon, Washington, DC Jeffrey Osterman, Weil, Gotshal & Manges, New York, NY McCoy Smith, Intel Corporation, Hillsboro, OR Topics 1. Understanding & Identifying Open Source (Osterman, Smith, Morris) 2. Strategies for Managing Open Source Risks Associated With Development (Smith) 3. Open Source in Corporate Transactions (Morris) 4. Summary & Questions (All) What is Open Source? • Available under licenses providing certain characteristic rights: – Free rights to copy, modify, distribute – Source code made available with any binary code – (Sometimes) software must relicensed under same license as that under which software was received. – Other conditions (attribution, etc.) may apply • Licenses “approved” by the Open Source Initiative (www.opensource.org) OSI Approved Licenses (August 2005) • Academic Free License • Historical Permission Notice and • Python license (CNRI Python • Adaptive Public License Disclaimer License) • Apache Software License • IBM Public License • Python Software Foundation • Apache License, 2.0 • Intel Open Source License License • Apple Public Source License • Jabber Open Source License • Qt Public License (QPL) • Artistic license • Lucent Public License (Plan9) • RealNetworks Public Source • Attribution Assurance Licenses • Lucent Public License Version License V1.0 • New BSD license 1.02 • Reciprocal Public License • Computer Associates Trusted • MIT license • MITRE Collaborative Virtual • Ricoh Source Code Public Open Source License 1.1 License • Common Development and Workspace License (CVW Distribution License License) • Sleepycat License • Common Public License 1.0 • Motosoto License • Sun Industry Standards Source • CUA Office Public License • Mozilla Public License 1.0 (MPL) License (SISSL) Version 1.0 • Mozilla Public License 1.1 (MPL) • Sun Public License • EU DataGrid Software License • NASA Open Source Agreement • Sybase Open Watcom Public • Eclipse Public License 1.3 License 1.0 • Educational Community License • Naumen Public License • University of Illinois/NCSA Open • Eiffel Forum License • Nethack General Public License Source License • Eiffel Forum License V2.0 • Nokia Open Source License • Vovida Software License v. 1.0 • • OCLC Research Public License Entessa Public License 2.0 • W3C License • Fair License • wxWindows Library License • Open Group Test Suite License • Frameworx License • X.Net License • Open Software License • GNU General Public License • (GPL) • PHP License Zope Public License • GNU Library or "Lesser" General • zlib/libpng license Public License (LGPL) Open Source Characteristics of Concern • It is ubiquitous • It is easy for your employees to access and obtain, via the Internet • Your employees probably don’t understand many of the legal issues – Because of use of the terminology “free software” – Voluminous (but often questionable) interpretations flood the Internet Why Should You Be Concerned? • The “copyleft” (“viral”) nature of some open source – Any, or most, or some derivatives (“works based on the program”) must be relicensed under same license as software from which derivative/work based on the program was created – “Strong copyleft” (“viral”) vs. “weak copyleft” (“semi- viral”) vs. “non-copyleft” (“non-viral”) • All vs. some vs. no derivatives/works based on the program must be licensed under same license • Widely used open source licenses are confusing and vague IP Issues • The loss of trade secret in all open source – Binary-only distribution (closed source) preserves trade secret status of source code – Binary-only distribution is not allowed under certain commonly used open source licenses • The potential patent ambiguity in some open source licenses – To what extent does the lack of the express patent license result in an implied license? – To what extent do unclear statements about patent rights (e.g., GPL) create express or implied patent licenses? • Lack of any warranties or indemnity with almost all open source software – When licensing in open source, no one to back it up if there is a problem – When licensing out, what if a jurisdiction does not allow for waiver of all warranties? Developing Corporate Policies & Practices on Open Source • Developing and implementing corporate policies regarding the use of open source software. • Why it is important to know if you have open source • How to tell if and where you have open source – Auditing – Source checker tools – Keep records of all packages, even those under “innocuous” licenses • Employee education Corporate Policies - Tips • Open source software is like any other software - treat it that way – Involve sourcing personnel in evaluating use of open source software • Need management buy-in to expend resources on open source compliance – May need to explain the risks of non- compliance Corporate Policies - Indemnification • Increasing numbers of vendors are now offering some form of indemnification for open source packages, such as Linux. – E.g., HP, Novell, Red Hat • When evaluating vendors, consider value of open source indemnification. Development Management • Managing the front end of software development – Ensuring employees know, or have access to information about, the basic issues with open source – Consider the cost of alternatives, including proprietary software, and be sure to consider the indirect (legal, etc.) costs associated with using open source software. Development Management • Managing the middle and back end of software development – Processes to “catch” instances where open source code is put into code not intended to be open source – Processes for appropriate review and approval when code is to be released under an open source license – Processes for appropriate review and approval when licensed-in open source code is to be used in or with company products Legal Management • Managing the legal issues – Monitoring legal and community developments around the open source legal and extra-legal rules Development Strategies • Commercial use of open source – Using open source in a development tool – Using open source in a product for sale or non-sale distribution • Non-commercial use of open source to further commercial ends – Open source contributions as a mechanism to sell hardware, services, or closed-source software Development Strategies • Internal use of open source – Most open source licenses only triggered upon “distribution” – There are signs that for some uses (such as use to power a web site), GPL 3.0 may trigger disclosure obligations even where such use would not trigger obligations under GPL 2.0. • Creation of non-open source software in an open source environment or to work with open source software – The continuing question about what derivatives or “works based on the program” aren’t required to be open source – The issue of “community practice” Development Strategies • Dual Licensing – It is possible for the exact same code to be available under multiple licenses. Some software is offered under both an open source license and a commercial license. Users who do not want to abide by the usage conditions in the open source license may opt for the commercial license. – Establishing a dual-licensing program requires careful consideration to ensure that all required rights have been obtained from all authors whose contributions are included in the software. Open Source in Corporate Transactions • Purchasing software or an asset that includes software – Important warranties and indemnifications, and possibly set-asides, concerning open source – Pre-purchase audits • Selling software or an asset that includes software – Warranties and indemnification liabilities can be limited by: • Conducting an open source audit before a one-time sale • Conducting an audit and putting into place an ongoing open source monitoring program in situations with ongoing sales Summary • Questions?
Pages to are hidden for
"Group Presentation"Please download to view full document