Open Source Software: What You Need to Know Presented By: Lisa Abe, Ian Kyer and Marek Nitoslawski September 15, 2005
Open source software ( OSS ): What you need to know Understanding the business and licensing models The risks and rewards Using open source in proprietary software New terms for acquisitions and licenses Tips for corporate policies
Understanding the business and licensing models Currently, over 50 different forms of open source licenses which have been certified by the Open Source Initiative (OSI), a non-profit corporation which manages and promotes OSS through a certification program and certification mark, e.g.: GNU General Public License (GPL), Version 2, June 1991 (new version 3 expected for 2005) Mozilla Public License, Version 1.1, (MPL 1.1) Sun Industry Standards Source License (SISSL) Sun Public License (SPL), Version 1.0 Apache License, Version 2.0 - January 2004 Apple Public Source License, Version 2.0 August 6, 2003 IBM Public License, Version 1.0 Eclipse Public License Version 1.0
Understanding the business and licensing models Common misconceptions; what OSS is not: Public domain Not subject to IP rights Free like a free puppy Unrestricted use Subject to the same terms as all other OSS; standard terms Turns proprietary software into OSS it depends No liability
Understanding the business and licensing models Common OSS criteria: Can t have restrictions or fees on redistribution Must include source code and compiled object code Modifications and distribution subject to the same license terms No discrimination Can t be restricted in a confidentiality agreement Must be severable, e.g. not linked to specific product Technology neutral
Using open source in proprietary software The risks The rewards Practical tips
The risks Business: Unsure origin; evolution via multiple authors; derived works can carry a different name or version number from the original OSS Quality assurance, bad code Protecting your company s reputation Unapproved changes could be made to your product downstream Dilution, lack of quality control Who is responsible for the whole software product? What will be supported, from supplier (upstream) and by your company (downstream)?
The risks Legal: Dynamic linking or shared code (in particular modified OSS code) could contaminate proprietary code lose licensing/commercial freedom viral license affects external distribution Ambiguity around license terms, e.g.: software that contains any part of the OSS must be licensed under the same license terms as the OSS Lack of warranties and indemnities Open source software licenses disclaim some representations and warranties, but not all; not sufficient protection downstream E.g. GNU, MPL, SISSL, SPL, Apache, do not disclaim implied conditions nor the provisions of the United Nations Convention on Contracts for the International Sale of Goods Certain limitation clauses may not be enforceable in certain jurisdictions
The risks Legal (cont.): OSS licenses that do not deal with all IP rights of all jurisdictions, e.g. patent rights, or waivers of moral rights in Canada Risk of having to stop using or selling Risk of patent infringement; someone could have independently created and with priority obtained a patent on an invention in the OSS Not subject to confidentiality; not protectable by trade secret law Breach of OSS license terms (assuming enforceable) Conflict with other legal compliance, e.g. export restrictions, SOX Uncertainty of governing law
The rewards Rapid evolution of software Independent peer review Improvement, bug fixes, free help Encourages interoperability, standards Can be used commercially Can bundle with proprietary software Depending on OSS license, should be able to sell proprietary software on separate license terms and under a different TM Perceived lower cost, growing acceptance, goodwill
Using open source in proprietary software Practical Tips Business/Technical: Keep OSS source code separate kernels, extract GPL code from external source Try to avoid dynamic linking Don t bundle with software protected by trade secrets Distribute as pristine base source plus patches, thus can be distinguished Track and manage the OSS, any modifications and your obligations Know whether OSS or proprietary software being modified focus development efforts where more profitable Internal use less risky than external/resale use Set up and enforce corporate policies (discussed below) governing software development and procurement, being sensitive to OSS issues
Using open source in proprietary software Practical Tips Legal: Review the OSS license: Not all OSS licenses are the same there is no standard Ensure it contains sufficient rights (e.g. patents, waivers of moral rights), rights of redistribution, sale, have made, etc. to be within scope of intended use Watch out for 3 rd party rights (e.g. upstream bundled code) Watch out for differences between internal vs. external/resale use Watch out for differences between unmodified vs. modified use Ensure no grant-backs or contamination of your proprietary code Know what warranties and indemnities are missing Know the scope of limits on liability and disclaimers
Using open source in proprietary software Practical Tips Legal (cont.): Weigh the risks, e.g. lack of quality, ownership, warranties, indemnities, IP infringement Ensure your downstream license to customer: does not violate the OSS license, e.g. by restricting modification, transfer, etc. does not contain warranties and indemnities that cover the OSS, which terms are greater than the terms obtained from upstream contains adequate and enforceable limits on liability and disclaimers (don t just rely on those flow-through terms in the OSS license) is enforceable (e.g. method of acceptance) OSS licenses often embedded in product or may contain unenforceable terms Associate your product with different trade-mark
New terms for acquisitions and licenses For the Vendor/Licensor: List all OSS components in a schedule (importance of tracking), and whether being used internally or in distribution; and whether or not modified by vendor To avoid violating OSS licenses, carve-out OSS from your downstream licenses containing common restrictions on copying, modification, distribution, sublicensing, transferability, etc. Carve-out OSS from your warranties and indemnities Other alternatives, limitations on indemnities, e.g.: HP requires HP version of software to be run on HP hardware and an HP support subscription; Novell requires minimum $ spend, a support subscription and cap on indemnity of lesser of $1.5M or 125% of value; Red Hat sole remedy for breach of IP infringement warranty is to replace, no indemnity.
New terms for acquisitions and licenses For the Vendor/Licensor (cont.): You should be relieved of liability, support obligations, etc., if purchaser modifies any OSS in your product Limit your liability to cover any gaps in OSS licenses, e.g. where no warranties, indemnities or enforceability of LOL clauses is in doubt
New terms for acquisitions and licenses For the Purchaser/Licensee: Due diligence as to vendor s/subcontractors use of OSS, OSS license terms and implications of downstream licenses Warranties from vendor/subcontractor/licensor as to: no OSS or extent of OSS, e.g. all listed/disclosed type of OSS license and restrictions scope of vendor s use of OSS, e.g. internal vs. external distribution; unmodified vs. modified ability to further distribute, market, transfer and license the product origin, ownership and functionality of OSS may be difficult to obtain Corresponding indemnities if proprietary software becomes contaminated
Tips for corporate policies For in-house development policies: Differences for use internally vs. externally (resale requires distribution of source and may be viral) Differences for modified OSS code vs. unmodified code Guidelines for modifications, will they be allowed? Process for review and permissions to use/implement/modify OSS Only certain pre-approved OSS (e.g. the ones which legal has approved licenses of) Separate OSS from proprietary code Ensure company has copy of all OSS source code Establish and ensure compliance with tracking and management procedures
Tips for corporate policies For procurement: Establish review process for procuring software and IT assets, e.g.: due diligence process; patent searches quality control standards pre-approved third-party vendors contractual terms to be negotiated and reviewed carefully legal review of each OSS component license Don t underestimate the risk/probability of IP infringement claims, e.g. RIM in InPro II Licensing v. T-Mobile USA, Inc., SCO v. IBM As with all policies, ensure they are enforceable via employee training, review, agreement and consistent treatment
In Closing, on Open Source Not all OSS licenses are the same Don t rely on flow-through licenses to protect you IP infringement becoming more of a reality (formerly a low probability, technical practice area issue) Blanket general IP warranties and indemnities are no longer sufficient Trade secret protection doesn t work with OSS Don t rely on your employees/developers to be vigilant and aware of/address all the issues OSS touches on many commercial contracts, e.g. M&A, IT purchases, service/outsourcing contracts Get early involvement of experienced IT counsel
Technology and Intellectual Property Practice Group This presentation contains statements of general principles and not legal opinions and should not be acted upon without first consulting a lawyer who will provide analysis and advice on a specific matter. Fasken Martineau DuMoulin LLP is a limited liability partnership under the laws of Ontario and includes law corporations.