Risks, Solutions and Prevention of Open Source and GPL Contamination in Proprietary Software 



Spring 2007 - (Intellectual Property Brief Spring 2007 )

Intellectual Property Brief Spring 2007

Despite recent shifts toward patentability of business methods in the United States, a company's software assets principally remain protected in Canada by two areas of law: copyright and trade secrets.  A company has automatic copyright protection in the original expressions of ideas embedded in the source code it develops.  However, copyright is not enough to protect the proprietary value of a source code: only the original expression of the idea, and not the idea itself, is protected.  Much like the secret recipe to a food product, it is commonly believed competitors can learn too much from source code, so companies often guard it carefully.  But not all developers take the same view: some see benefits and opportunities in making their source code available, and the intersection of these two mindsets creates unique legal challenges.

Open Source Software Generally

The Open Source Software (OSS) movement encourages the disclosure of source code and is facilitated through copyright licensing.  OSS is often referred to as "Free Software", but one should avoid the quick association with "freeware".  "Free" in the OSS community is often qualified by the expression "free (as in speech), not free (as in beer)" as a creative take on the more scholarly distinction, libre versus gratis .  Essentially, OSS developers disclose source code to recipients (and often the general public) in the view that (a) this furthers innovation in the industry, (b) collaboration leads to efficient and effective software solutions, and, most importantly, (c) software should be "free" (as in speech).  Most, but not all, OSS licenses put significant conditions on the modification or re-distribution of the source code; some

OSS licenses, such as the MIT or BSD license, are more "freeware"-like, only putting minimal conditions on developers such as copyright attribution or disclaimers of warranties.

The most frequently-used OSS license is the General Public License (the GPL, available online at http://www.gnu.org/copyleft/gpl.html . The GPL allows the use of and modification to GPL-licensed source code, and permits further distribution of the resulting product—even commercial distributions.  As such, a company can use another's GPL-licensed code in its own product.  However, the GPL requires that, among other things, the recipient of each resultant product must be given (a) access to the source code and (b) a license to the resultant product no less restrictive than the GPL.  In other words, the company that incorporates GPL-licensed code into its own software cannot distribute it more restrictively than the GPL.  Thus, the GPL-licensed code remains "free", even as embedded into future derivative works: no party can create a proprietary or "closed-source" product based on it.  For this reason, OSS licenses such as the GPL are sometimes called "viral", propagating from the original OSS to all future derivative works.

The Risk of OSS Contamination in Proprietary Software

Proprietary software developers often employ teams of programmers who collaborate to develop a product, which presents a risk that GPL-style OSS will be incorporated into its software either knowingly (by seeking out and incorporating OSS to accomplish software objectives) or inadvertently (by re-using code from external or undocumented internal sources).  Programmers often need to accomplish tasks for which code has already been developed, and may incorporate external code to avoid "re-inventing the wheel."

When OSS is incorporated into a proprietary product, it is called "OSS contamination".  While some claim that OSS contamination can legally force a developer to "open up" it source code to the world, the truth is more nuanced based on the OSS license.  For example, there is no requirement in the GPL to remit source code back to the public.  By failing to comply with the GPL, such as by using GPL-licensed code in proprietary software but not making that software's source code available to a recipient or licensing the proprietary software to a recipient more restrictively than the GPL, a developer steps outside the bounds of its permission to use that OSS.  A rights-holder in that OSS could then pursue claims for damages, infringement, or other relief.  Additionally, any representations made to recipients of the proprietary software as to the validity of title may be breached.

Solutions to OSS Contamination

Facing OSS contamination, proprietary development companies are often presented with two choices: either "cure" the proprietary software by acquiring a non-OSS alternative to the OSS code or comply with the OSS license.  In 2006, an OSS watchdog group discovered a GPL violation involving a German company, SV-Chipkarten Betriebs- und Errichtungs GmbH (SVC).  SVC had contracted with the Austrian government to set up electronic health card systems at doctors clinics in Austria.  SVC's solution used GPL-licensed software, but SVC did not provide the source code to its recipients.  In another example, Linksys (a division of Cisco Systems, Inc.) faced a similar problem when, in 2003, it was discovered that the firmware (embedded software that controls hardware) for one of its router products was derived from GPL-licensed software.  In both instances, the companies complied with the GPL and released the full source code.

The appropriate decision often depends on the nature of both the firm and the software developed.  Making source code available under the GPL may lead to the release of internally-developed know-how to competitors, customers, and perhaps even the general public, which may have an adverse effect on business opportunities.  For example, while the business effects of its decision are not fully known, the release of the Linksys firmware source code enabled the open-source community to create modified software which gave the inexpensive consumer-level router feature sets similar to its more expensive (and likely more profitable) business- and enterprise-level routers, though to some extent this may have been counterbalanced by the upsurge in sales of this particular "upgradable" product.  For other companies, however, there are other considerations: GPL compliance may lead to a breach of a agreements with clients, customers, or licensors.  Faced with OSS contamination, developers must weigh various costs (including GPL compliance, replacement product, client obligations) and find a solution appropriate to that balance.

Preventing OSS Contamination

While many companies have found success and profit by including OSS as part of their business models, OSS contamination can be harmful to a company whose business model relies on the competitive advantage of proprietary source code or who has obligations to the keep code secret.  Preventing OSS contamination is often seen as vital to such companies.  In such cases, employees and contractors should agree to not obtain source code or software libraries from third parties, open-source repositories or the Internet without company approval; in some cases, indemnities may even be appropriate.  Also, source code audit software and services are commercially available, which should be regularly employed in important products to restrict the effect of OSS contamination.

While OSS contamination is not apocalyptical, its effects are potentially substantial and its risks should be carefully considered by any development firm who has accumulated goodwill in its proprietary source code.

This article appeared in Intellectual Property Brief Spring 2007.