Intellectual Property Group Presentation Using Open Source Software Issues to Consider Peter J. Guffin, Esq. Pierce Atwood LLP January 22, 2009 I. Agenda Select key terms in various open source licenses Best practices for managing the use of open source software Recent Jacobsen v. Katzer case upholding enforceability of open source license II. Terminology/Baseline Understanding A. Open source software is software that is made available with its source code and offers certain freedoms to software developers and users e.g., the right to modify the software and the right to distribute the modified software. B. It is not software in the public domain. C. Open source software is copyrighted and licensed intellectual property. D. There are number of different open source licenses, each with its own unique terms. III. Select Key Terms in Various Open Source Licenses A. Berkeley Software Distribution (BSD) License Use: You may freely use the software with or without modifications. Modifications: You may freely modify the software and use such modifications. Distribution: You may redistribute the software, provided you meet the following requirements: o retain the copyright notice o retain list of BSD Conditions; and o retain warranty/liability disclaimer Use of author s name to promote or endorse products derived from this software is not permitted
Patent issues: No restriction on your ability to enforce patent rights. Also no requirement that you convey any patent licenses. B. Apache License Version 2.0 Use: You may freely use the software or any derivative works based on the software. Modifications: You may freely modify the software and use such modifications. Distribution: You may reproduce and distribute copies of the software and any derivative works based on the software, in Source or Object form, provided the following conditions are met. o recipients must receive a copy of the Apache License o you must include prominent notice of modified files o you must retain, in Source form of any distributed derivative works, all copyright, trademark, patent and attribution notices from the software o you must retain any Notice text file from the software (if applicable) in any distribution of a derivative work o you may add your own copyright statement to your modifications and may provide additional or different license terms for use, reproduction, or redistribution of your modifications, or for any such derivative works as a whole, provided your use, reproduction, and distribution of the software otherwise complies with the Apache license. Works that remain separable from, or merely link (or bind by name) to the interfaces of the Apache software are not derivative works and are not subject to the foregoing requirements. Such works may be freely distributed on terms of you choice. Patent Issues: If you are a Contributor, there is requirement that you convey a patent license to downstream users with respect to your Contribution. You are granted an express patent license to make, have made, use, offer to sell, sell, import and otherwise transfer the software. If you institute patent litigation against any entity alleging that Apache-licensed software or a contribution incorporated within the software constitutes direct or contributory patent infringement, then the patent license terminates. C. Mozilla Public License (MPL) Version 1.1 Use: You may freely use the software and any modified versions of the software. Modifications: You may modify the software and use the modified version, provided that you include a file documenting the changes you made and the date of any changes. Distribution: You may distribute the original software and any modifications only under the terms of the MPL. You may create a Larger Work by combining the MPL software (and any modifications) with other software not governed by the MPL and distribute it as a single product as long as the MPL software and any modifications are licensed under the terms of the MPL. Distribution of the MPL software and modifications requires the following: {W1272648.1} 2
o must include a copy of the MPL with every copy you distribute o Must cause all Covered Code to which You contribute to contain a file documenting the changes you made to create that Covered Code and the date of any changes o You must duplicate the notices in Exhibit A in each file of the Source Code o You may distribute in Executable form only if all distribution requirements are met and you include a notice stating that the Source Code version is available under terms of the MPL. Patent Issues: If you are a Contributor, there is requirement that you convey a patent license to downstream users with respect to your Contributor Version. You are granted an express patent license to make, have made, use, offer to sell, sell and otherwise dispose of the software. If you initiate a patent infringement action with respect to the MPL licensed code against the Initial Developer of or any Contributor to the MPL software, your license to use the software terminates. The license does not terminate if you initiate an infringement action against someone other than the Initial Developer or a Contributor. D. GNU Lesser General Public License (LGPL) Version 2.1 Use: You may freely use the unmodified library. Modifications: You may modify the Library, but modified work must itself be a software library. You must include prominent notice stating you changed the file and the date of any change. You may freely use a modified Library. Distribution: The key issue is distinction between a work based on the Library and a work that uses the library o A work based on the Library means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. o A work that uses the library is a program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it. Distribution of verbatim copies of the Library and copies of any work based on the Library require that such copies include appropriate copyright notice, disclaimer of warranty, and LGPL license terms. Such copies must be licensed to all third parties at no charge under the terms of the LGPL. Distribution of a work that uses the library is permitted without restriction, unless it is linked with the Library in a manner that creates an executable that includes source code from the Library. If such an executable is created, the LGPL imposes certain obligations to reveal the source code of the Library and the work that uses the Library so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. {W1272648.1} 3
Patent Issues: There is no restriction on your ability to (1) seek patent protection or (2) enforce patent rights. Nor does the LGPL require you to convey any patent licenses. E. GNU Lesser General Public License (LGPL) Version 3 The LGPL V. 3 incorporates by reference the General Public License (GPL) Version 3. The LGPL simply includes additional permissions that the GPL V.3 does not include. Although the vocabulary of LGPL V. 3 is different from version 2.1, the intent is the same. This summary includes relevant provisions of the GPL V. 3 and LGPL V. 3 o Use: You may freely use the Library with or without modifications. o Modifications: You may modify the Library and use the modified Library without conditions. You may also link the Library to an Application to create a Combined Work o Distribution: The GPL V.3 uses the term convey, rather than distribute. You may convey verbatim copies of the Library and any modified versions of the Library under the terms of the LGPL V. 3. If you link an Application to the Library to create a Combined Work, you may convey the Combined Work on terms of your choice, provided that you don t restrict the ability of the user to (1) modify the Library contained therein or (2) reverse engineer the Combined Work for debugging such modifications. You must also do the following: give prominent notice with the Combined Work that the Library is used in it and the Library is covered by the LGPL accompany the Combined Work with a copy of the GPL V.3 and LGPL V.3 include necessary copyright notices make the source code for the Library and source code and/or object code for the Application available for down-stream users to allow them to modify the Library and to be able to re-link the Library with the Application to create modified versions of the Combined Work. o What does convey mean? The GPL V.3 makes clear that convey does not include delivery of Software as a Service (SaaS). o Note however that GPL V.3 provides that you may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. o Patent non-assertion provision: The GPL V.3 prohibits you from asserting a patent infringement action against another party to stop them from exercising their rights to use any software that you are licensing under the GPL V.3 (or LGPL V.3). The consequence of asserting such an action is termination of your license to use the GPL V.3 program. {W1272648.1} 4
o Patent license: The GPL V.3 provides that if you modify GPL V.3 licensed software and then convey that modified software to any third party, you automatically provide every recipient with a royalty-free patent license to patent claims that you control and that read on the modified software being distributed. No patent licenses are granted by you by virtue of mere use by you of the LGPL V.3 libraries. o Other patent provisions: The GPL V.3 also includes provisions intended to extend any patent license granted to you with respect to a particular GPL V.3 work to all recipients of that work (even if the patent is not controlled by you). IV. Best Practices for Managing the Use of Open Source Software A. Open source software requires special management for several reasons: It has become nearly ubiquitous and easily seeps into many projects. It typically does not come with characteristics we have come to expect with closed source licensed software. It is licensed with specific rights and obligations that need to be tracked and managed over time. Just as it is not sensible to sign a closed source software license agreement without reading it, it is not sensible to incorporate open source without review of its license. B. If open source software is used indiscriminately and not properly managed, there are a number of potential problems that can arise. Examples of issues that have arisen are costly injunctions, unanticipated requirements to publish source code, and unexpected development costs for remediation where license violations in redistributed code are discovered too late ; unexpected development expense and delay if low quality open source code has been incorporated; and in the context of corporate acquisitions, reduction in acquisition price when unreported open source software is discovered in target s code base during due diligence. C. The fundamentals of open source software use and management are as follows: Know what open source software you are using and its essential attributes Know where and how you are using each open source component and that its use is appropriate Know who is responsible for the maintenance of each component Know that you are complying with your open source license obligations {W1272648.1} 5
D. Best practices for using and managing open source: Diligence. Understand where you are using open source software and why and what negative implications of such use exist or could arise. Understand the terms of the applicable open source license. Strategy. Obtain consensus as where to use open source in the future to achieve certain specific goals and where you do not want to use open source and for what reasons. Open Source Policy. Establish the criteria and decision points for use of open source, the information that must be collected and tracked, and the roles and responsibilities for using and managing it. Management Process. Establish a process by which (i) developers can obtain timely response from management to their requests to incorporate open source and (ii) management can efficiently consider its use in light of the established Open Source Policy. Tracking Repository. Keep track of open source components, their attributes (including their licenses and where the code was obtained from), their owners in the company, where they are used, and incorporate decision, modification and maintenance histories. V. Recent Jacobsen v. Katzer Case Upholding Enforceability of Open Source License A. Citation: 535 F.3d 1373; 208 U.S.App. LEXIS 17161, August 13, 2008 B. Facts of the case: Computer program for model trains made available for free download J had copyright in the program Use of program governed by Artistic license (similar to BSD license) K failed to comply with terms of license, and J sued K for copyright infringement, seeking injunctive relief K asserted license as shield and argued that J is limited to seeking recovery of damages under a breach of contract claim {W1272648.1} 6
C. Holding in case: K s failure to comply with terms of license constitutes copyright infringement and J therefore is entitled to enjoin K from using and distributing the program. D. Copyright infringement or breach of contract remedies? What remedies are available? Why does it matter? Copyright infringement remedies: injunctive relief, statutory damages and attorneys fees Breach of contract remedy: compensatory damages Difficulty of proving damages when program is made available for free E. Covenant vs. condition Conditions are not favored by courts State (contract) law determines whether license term is covenant or condition Court recognizes economic interest of J even if no money is exchanged License term is a condition if it is a limitation on the scope of the license Use terms such as provided that and subject to to show that obligation is a condition F. Significance of court decision First U.S. court to uphold enforceability of an open source license Applies to all software license agreements, not just open source licenses {W1272648.1} 7
The Software as a Service (SaaS) Solution Peter Guffin & Matt Stein
What is SaaS? Alternative software deployment model Network-based access One-to-many architecture (single instance, multi-tenant) Centralized maintenance (updates and upgrades) Per-user/per-seat subscription pricing model
The Road to SaaS Traditional On-Premise Deployment Application Service Provider (ASP) SaaS
Traditional On-Premise Deployment Software Vendor Customer Data Center Application Database
ASP Deployment ASP Data Center Software Vendor App App App Database Database Database Customer 1 Customer 2 Customer 3
SaaS Deployment Software Vendor App Database Customer 1 Customer 2 Customer 3
Adoption of SaaS is Increasing By 2012, at least one-third of business application software spending will be as service subscription instead of as product license. Gartner Industry Survey by Cutter Consortium:
Factors Driving Increased Adoption? Cost Eliminate additional infrastructure and staff costs Predictable, pay-as-you-use subscription pricing Streamlined implementation Reduced maintenance concerns Continuous upgrades/updates made by Provider Allow IT to focus on strategic projects Commoditization of applications
Adoption by Application Type CRM HR Procurement Internet Banking
Potential Pitfalls Performance/Availability/Support Security Data Compatibility/Integration Costs Termination and Migration
Potential Pitfalls: Performance; Availability; Support On January 6, 2009, Salesforce s CRM service was down for nearly 40 minutes. In 2008, Google Apps and Gmail suffered several outages. Can you risk the application being unavailable?
Contracting to Mitigate Risk: Service Level Agreements Include performance and availability SLA in the contract. Be specific: For whom? What function? From what component? What performance metric? What availability? What time frame? How do you measure service levels? What are the remedies?
Example: Authorized Users will have access to the Service from Customer s branches in the United States and Canada with a host latency of less than three (3) seconds. Service Availability for any month during the term will meet or exceed 99.95% during Customer s normal business hours.
Contracting to Mitigate Risk: Service Level Agreements Include Helpdesk response times, escalation paths and target resolution times appropriate for the problem severity level. Consider identifying Provider contacts by name.
Potential Pitfalls: Security What data does Provider have access to? What information security practices and policies does the Provider have? Third party audits? SAS-70? Is your data commingled with other customers data?
Contracting to Mitigate Risk: Information Security Requirements If the Provider s information security program meets your expectations, make certain it is memorialized in the contract. Providers need to be careful not to overcommit to standards they cannot meet. Also, make certain you are not liable for events/actions outside of your control.
Example: Provider has and shall maintain during the Term an information security program that conforms with reasonable industry standards, including the standards set forth in Provider s Information Security Policy attached hereto as Exhibit X. Provider s information security program shall be designed to adequately: (i) ensure the security and integrity of Customer s Confidential Information; (ii) protect against threats or hazards to the security or integrity of Customer s Confidential Information; and (iii) prevent unauthorized access to Customer s Confidential Information.
Contracting to Mitigate Risk: Audit Rights Consider appropriate audit provisions General Audit/Operational Audit by Customer or its agent Annual SAS 70 Audit Cooperation with Regulatory Audits Providers must be careful to limit the scope of audits and make subject to Provider s reasonable security policies. Also, any information made available during an audit must be treated as confidential information.
Potential Pitfalls: Data By using SaaS, you give the Provider access to and control of your data? If you don t have access to your data, migration to a new Provider may be very difficult and you lose leverage when bargaining with the incumbent Provider.
Contracting to Mitigate Risk: Data Ownership and Use Rights Include provision making clear that Customer retains all right, title and interest in Customer Data. Make clear what usage rights Provider has to the Customer Data. Provider may want rights to aggregate Customer Data.
Example: Unless otherwise authorized by Customer in writing, Provider will access and use the Customer Data solely to provide the Services to Customer hereunder. Notwithstanding the foregoing, Provider may access, compile, aggregate and use Customer Data for research, analysis and other business purposes, provided that such Customer Data is compiled in aggregate form only, without identifying (i) the source of the Customer Data; (ii) any individual name, telephone number, social security number, driver s license number, financial account number, or other identifying characteristic or element of the Customer Data; or (iii) any customer or client of Customer (the Aggregate Data ). As between Customer and Provider, Provider owns all right, title and interest in the Aggregate Data and may use such Aggregate data for any lawful purpose.
Potential Pitfalls: Compatibility/Integration If an application integrates with other enterprise applications and/or data sources, think carefully about whether SaaS is the right solution. When the Provider upgrades, you are generally dragged along to the new version. Will an upgrade by the Provider break your interfaces?
Contracting to Mitigate Risk: Upgrades If possible, include provision permitting Customer to use older version for a period of time after Provider upgrades. At a minimum, require reasonable advance notice before upgrades are implemented. Confirm whether Provider tests against supported interfaces before upgrade.
Potential Pitfalls: Costs One advantage of SaaS is a predictable monthly or annual service fee, however, watch out for unexpected costs. Additional fees for extra bandwidth or storage space Increases in monthly or annual service charges
Contracting to Mitigate Risk: Price Protection Consider provisions limiting the Provider s ability to increase monthly or annual fees. Negotiate for discounts on additional storage/bandwidth in advance. From Provider s perspective, it is important to maintain flexibility to adjust prices to changing conditions. Price protection may require longer Initial Term.
Potential Pitfalls: Termination and Migration It is important for Customer to maintain flexibility to move to new solution if SaaS Provider is not meeting expectations. Consider a trial period or a one year Initial Term. Does contract permit early termination for convenience without penalty? Can you obtain your data in a standardized format for migration to the new solution?
Questions to ask the SaaS Provider before negotiating the contract (and questions the Provider should be ready to answer) 1. Can I obtain my data from you upon request and upon termination? 2. Is the code I write to configure the solution portable to new versions? 3. Where will my servers be located? Do you provide advance notice before moving? 4. What kind of SLAs do you provide? What reports do you make available?
Questions Continued 5. What privacy/security controls, policies and procedures do you have in place? 6. Do you have an annual SAS-70 or other independent audit? 7. What kind of APIs do you offer? How are they supported? Can you send me the documentation? 8. How often do you upgrade? How much advance notice do you provide? Can I stay on an older version while we train on the new one? 9. What price protection do you offer? 10. How much bandwidth/storage do I get? How much will extra bandwidth/storage cost?
THANK YOU.