The hazards of unmanaged open source software usage can emerge in inopportune moments, like when a startup is raising funds or contemplating an M&A transaction. A potential investor or buyer, in reviewing core software assets and license terms, identifies a license incompatibility or so-called "tainting" issue and a flurry of crisis response measures follow, potentially derailing the deal and engendering the kind of freak-out frustration best reserved for a scene in an Adam Sandler movie.
Open source software (OSS) can primarily be understood by distinction from proprietary software (or “closed source” software) which is software that is copyrighted, and most software companies monetize their business by granting third parties licenses (or rights to use) that software in exchange for payment. Those use rights will ordinarily be governed by contract (via the licensor company’s standard terms of use or a negotiated master software license agreement) describing how the software may be used, modified or distributed by the licensee (usually just for the internal business purposes of receiving the software services). In the event the licensee exceeds the restrictions imposed, the licensor has legal rights to bring an action for breach or infringement.
OSS by contrast describes software source code distributed on an open basis that allows anyone can use, modify, and enhance it (at least generally). The self-evident benefit is that companies can build around and customize the best available OSS rather than allocating in-house resources to natively develop functionally equivalent software systems. While OSS license management is technically within the legal purview by default it's generally implemented by and delegated to developers within an organization. Engineers are often the only stakeholders in a startup with significant knowledge on the subject.
While there are operational side risks associated with open source (of the kind inherent in relying on any asset someone else built (reliability, security, etc.)) the main business-side catch is that OSS just like proprietary software is governed by licensing mechanisms (among the most well-known are GPL, LGPL, BSD, MIT, and Apache) which affect the scope of allowable use and downstream commercial licensing. While the terms of these licenses are vastly less restrictive than those of proprietary licenses, generally the licenses to do not give licensees unlimited freedom to modify or redistribute the source code.
The restraints of OSS licenses vary but the three main categories are (i) “permissive” licenses (e.g., MIT) which in effect allow a developer to modify, adapt and combine the OSS code with proprietary code to create derivative works and then license the resulting code to downstream licensees in its complete discretion, (ii) “pass through” or “inherited” licenses which require developers to give downstream licensees the same rights to use and redistribute that OSS (as modified) as afforded to them and (iii) “viral” licenses (e.g., GPL) that not only require developers to allow downstream licensees to use and distribute the OSS itself but also any independent code such as proprietary code that is combined or in some cases simply linked to the original OSS code by the developer.
“Inherited” licenses often include certain notice requirements at the code level such as preserving the exact wording of the OSS license and disclosing any code modifications. In short, whatever rights inherent in the original OSS license are there for perpetuity. As a necessary corollary to or function of the inherited license, all source code (of the OSS) must be made accessible to future users for modification and read only programs are insufficient. This doesn’t mean that OSS subject to inherited licenses can’t be commercialized since ordinarily such OSS software is not licensed independently and but rather embedded in proprietary products or services that a developer is free to price in its discretion.
“Viral licenses” are the main watch out for startups as they implicate the inadvertent surrendering of ownership rights to proprietary intellectual property (such as software or patents). Under these more restrictive licensing mechanisms, any changes to the open source including “derivative works” must be licensed as open source if the OSS is distributed. Using OSS components subject to a viral license together with proprietary code in a manner that allows the code to be considered as a “derivative work” may well jeopardize or “taint” a business’s intellectual property. Hence, where open source software subject to a viral license is bundled with proprietary software and distributed to third parties, it is possible that the proprietary software will be deemed to be a derivative of the OSS and therefore lose proprietary protection.
The legal ramifications of using OSS like everything else in law depends on the situation (to wit, the license at issue and the circumstances of use). Typically, use of OSS (even those subject to viral licenses) for internal business purposes without third party access or distribution poses little risk. However, for OSS that is packaged and distributed by license or via network access (like SAAS product) an organization should implement at a bare minimum a process or guideline for tracking and approving use of OSS that is mindful of license terms that affect the ability to protect or enforce intellectual property or disrupt intellectual property strategies (e.g. patent licenses).
This alert was prepared by Jake Molland, a Principal at Bound Legal Strategy P.C. The content of this alert is informational only and does not constitute legal or professional advice. Please note that the law changes frequently and further that the generalized information reflected in this alert may not address the specifics of a given factual situation. Please contact Jake at jake.molland@boundlegal.com if you have specific questions or concerns relating to any of the topics covered in here.
Comments