Open Source Software:
What You Need to Know
Presented By: Lisa Abe, Ian Kyer and Marek Nitoslawski
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
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
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 3rd 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
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
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
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
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.
