In the not-so-distant licensing past, most technology vendors stringently denied using any open-source software in their proprietary software programs. Almost every standard software licence agreement was completely silent on this point.
To the extent it came up at all, the use of OSS might make it into an asset purchase or financing deal and at the 11th hour, the target vendor’s executive would steadfastly sign a very stringent representation/warranty drafted by opposing counsel stating the target company did not use any open-source software in their own proprietary technology at all without any further follow-up discussion with target company’s engineers or developers to verify the accuracy of this statement.
Everyone was happy because officially there was no OSS to worry about.
No more. The use of OSS today is ubiquitous.
OSS is downloadable for free, is supported by robust collaborative communities that peer review and improve the code, and is often the preferred code of many software developers.
The Gartner Group has noted “the top tech companies are still spending tens of billions of dollars on software research and development, the smart ones are leveraging open source for 80 percent of the code and spending their money on the remaining 20 percent, which represents their program’s ‘special sauce.’”
This means more tech companies are incorporating OSS into their standard proprietary products, often without fully understanding how these licences actually work and their very real (legal) obligations, which can prove to be commercially disastrous when these practices are caught out in connection with an acquisition or when a more sophisticated licensing partner demands the performance of a detailed and invasive OSS code audit prior to entering into any reseller/distribution or other licensing arrangement.
OSS is software that can be freely used, changed, and shared by anyone. Most OSS is distributed under OSS licences that comply with the Open Source Definition, a document describes what conditions a licence must fulfill in order to be termed an open source licence by the Open Source Initiative. To date, the OSI has approved approximately 60 OSS licences (although other, less official ones exist).
Unfortunately, many companies that develop or integrate proprietary software do not have any kind of policy or strategy that establishes practices and limitations on the kinds of OSS used by their businesses. Consequently, many of their developers don’t understand this software comes with specific licence terms and conditions.
For example, the so-called “permissive” licences like BSD, MIT, and Apache do not require licensing on particular terms but still require users to reproduce certain attribution notices (i.e. copyright notices/disclaimers) in the software. Other OSS licences, like Mozilla or the GPL v. 3 allow the OSS to be used on a limited basis in modified or unmodified form internally or for the delivery of a hosted service without triggering an obligation to release modified source code.
However, various “copyleft” licences such as the GPL v. 2 and GPL v. 3 require companies that modify the OSS to release the modified source code or make a written offer for three years to give any third party the corresponding source code at a nominal or no fee. Not all companies want to do so if they are trying to maintain their code as proprietary.
Given the lack of attention to the actual OSS licence terms, companies sometimes use an alphabet soup of licences that are legally incompatible with one another. For example, while one can combine the OSS code under a permissive licence (BSD) with other kinds of permissive OSS licences (Apache), the situation gets complex when one tries to combine different and usually irreconcilable licences.
Philosophically the GPL licences maintain that all code in the same executable program would be covered by GPL making proprietary usage by a technology vendor that doesn’t want to distribute source code very difficult. Worse, the GPL v. 3 is not compatible with the v. 2 so code cannot be linked and licensed under both licences in a single vendor program.
Even friendlier GPL licences, such as the LGPL, still have certain technical restrictions and a term that restricts the prohibition of reverse engineering. Under the LGPL, customers must be able to modify their work for their own use and reverse engineer the software for debugging modifications, which is not consistent with the terms of most end-user licences used by non-OSS vendors today. Keep in mind users of OSS licences have no ability to pick and choose elements of these licence terms — if they use OSS, they are automatically bound to all terms in the licence and failure to comply usually causes the licence to automatically terminate.
In fairness to OSS users, it is sometimes hard to find the actual licence that applies to a particular kind of software (besides having to hunt for the applicable licence, sometimes OSS is ‘mislabeled’ as vendors will say that a particular piece of software is licenced under one kind of OSS licence but following investigation one discovers that it is really being made available under licence entirely).
It does not help that many of these licences are difficult to understand and a great deal of technical analysis is needed in order to understand how users must comply. This is why many technology licensors make their software available through dual-use licences, offering both paid commercial versions of their software for vendors seeking to keep its program proprietary as well as free versions with various OSS licences (often the more problematic GPL variety). Black Duck Software estimates 16 billion lines of code are licenced under the GPL v.2.
While it is tempting to ignore OSS licensing issues, smart vendors can’t any longer. The stakes for using OSS are growing and there are at least five cases in the U.S. right now touching on OSS licensing issues involving software developed by XimpleWare Corp.
Summarizing briefly, Versata Software had signed a master software licence agreement with Ameriprise Financial that gave it rights to use certain distribution channel management (DCM) software, contingent upon Ameriprise limiting access of the software to its own employees and permitted contractors. Versata later terminated the MLA for breach alleging Ameriprise had allowed non-permitted contractors to access and work on the DCM software (including decompiling the code). Versata required Ameriprise to stop using and return the DCM software.
However, Versata’s code included certain VTD-XML software from XimpleWare Corp. made available under the GPL v. 2 open-source licence. Versata incorporated VTD-XML into its DCM software and Ameriprise counter-claimed saying Versata was required by the GPL v. 2 to make the DCM source code freely available to all users, including Ameriprise and its contractors, in breach of the U.S. Copyright Act.
XimpleWare ultimately sued Ameriprise and Versata (and initially all Versata’s DCM customers) for breach of the GPL v. 2 and patent infringement because while XimpleWare did offer VTD-XML under a dual-use licence, Versata had not obtained a commercial licence for software, and thus the component was governed by GPL v. 2, the open-source licence.
XimpleWare alleged Versata had made distributions of the code but had failed, for example, to include standard GPL warranty disclaimers, nor include any notices it was licensed under the GPL. XimpleWare’s copyright notice also was not included in the code and the source code was neither provided nor offered upon the object distribution.
This dispute is being carefully watched as it is hoped it will provide additional clarity regarding GPL and OSS licensing issues, especially since XimpleWare is seeking monetary damages rather than compliance.
These pending cases remind us that technology companies that routinely use OSS in their developments and distribute them externally should implement an OSS policy to ensure their OSS operations are disciplined, efficient, and timely.
For example, if a company wants to ensure it has no source code distribution obligations, it should only use OSS governed by OSS licences that do not contain these requirements. Moreover, any company that uses OSS should ensure its own licences contain carve-outs clarifying that the terms of its own proprietary licence that would conflict with the OSS will be governed by the OSS licence rather than its own licence to avoid any unintended consequences.
Open-source licensing has clearly “grown up” from the days when the parties could just ignore its existence entirely and the best way to approach these issues is to face them square on and deal with the relevant OSS licences on their own terms.
