This article was originally published in the Spring 2004 edition (Vol. 4, No. 1) of Thelen Reid's Intellectual Property and Trade Regulation Journal.

Open source software, exemplified by the Linux operating system, is a revolutionary approach to software that is being adopted by many companies. Its advantages are well known: lower software and hardware costs and more stability, flexibility and security. However, the filing of a lawsuit by SCO Group against IBM in March 2003, asserting ownership of key parts of Linux, and SCO's increasing threats against corporate users of Linux, have revealed risks previously overlooked. In fact, open source does come with some legal risks that, while manageable, should be understood by business users.

"Open source" describes a belief that software is best written in an open collaborative process in which the resulting product is freely available to others to use, improve and distribute. Early proponents of open source based it on moral principles of free access, while later supporters have promoted it as a viable business model for commercial developers and users. In a nutshell, it is software whose source code is freely available to all to use and modify, and that is distinguished from proprietary software such as Microsoft Windows. Many server-based systems in wide use today are predominantly open source.

However, open source raises two unique risks: the risk of infringement and the risk of license restriction.

The Infringement Risk

There is a somewhat higher risk, compared to proprietary software, that open source violates third-party intellectual property rights, and open source users receive no contract protection for this higher risk. In theory, any programmer can add infringing code to open source because it is developed without the usual commercial controls. Moreover, most providers of open source do not offer the warranty protections customarily given for commercial products. (Hewlett-Packard has announced it will offer legal protections for its version of Linux on certain rather strict conditions, and others may also do this. However, most providers have not followed suit, nor are they expected to.) As a result, a higher risk of infringement, and the consequent exposure to injunctions and damages, rest entirely on the user.

The infringement risk is highlighted by the SCO case. SCO is claiming $3 billion in damages from IBM for breach of confidentiality and wrongful disclosure of Unix code it claims it owns. That confidential code, SCO asserts, ultimately found its way into Linux versions after release 2.4. IBM has denied these claims and filed counterclaims against SCO alleging breach of contract, patent infringement and unfair competition. The suit is only between SCO and IBM; other Linux contributors, users and distributors are not parties. Presently, outcomes and impacts on users cannot be meaningfully predicted, and the IT community is watching the case closely. Recent developments have cast doubt on the strength of SCO's case, but it is much too early to speculate. It will likely be a protracted dispute that will take years to conclude.

SCO has notified about 1,500 large companies of its intent to enforce its rights against unauthorized Linux users and has offered a licensing program to all users. Responses from the user community to this offer have been soft. Perhaps as a result, SCO recently threatened to sue at least one large Linux user within the next three months. If SCO were to pursue claims against end users, it would most likely be based on copyright infringement. Intent is not an element of a copyright infringement claim (although it is relevant to damages), so all SCO would have to establish is that it owns copyrights in the subject code and that a user's copying and modification were unauthorized. A trade secret claim appears unlikely because it requires the existence of a protectable trade secret and misappropriation, both of which might be difficult to establish against an end user.

It is important to recognize that the infringement risk is inherent in all open source, not just Linux 2.4.x versions. The SCO suit is merely exemplary of the risk. Any strategy to control this risk depends on a particular user's open source implementation and future plans. At worst, even if SCO were to prevail, these options might be available depending on the circumstances:

• Migrate from a risky open source product to a less risky one. For example, from Linux 2.4.x to a taint-free Unix version.
• 
  
• Cleanse the infringing code.
• 
  
• Buy a license. As for the current SCO license offer, we do not recommend that users purchase a license, at least not now.
• 
  
• In any event, at the moment, keep a low profile on the adoption of Linux and other open source.
• 
  
• For new open source investments, implement due diligence procedures and/or minimize investment until vendor protections and legal implications are more clear.

The License Restriction Risk

Open source comes with unusual license restrictions that may impact a company's strategies, particularly the risk that its own proprietary software may be "tainted" by a duty to open its source code to others. This risk is different from the infringement risk. Open source is not in the public domain but instead is available for use only under one of a variety of licenses that impose restrictions on users. These licenses differ, and it is important to know and observe their terms.

Linux has been distributed under the General Public License (GPL). One risk under the GPL stands out: the possibility that a user's proprietary code will be "tainted" by a duty to make its source code open. If a user of GPL code decides to distribute or publish a work that "in whole or in part contains or is derived from the [open source] or any part thereof," it must make the source code available and license the work as a whole at no charge to third parties under the terms of the GPL (thereby allowing further modification and redistribution). In other words, this can be a trap for the unwary: a company can unwittingly lose valuable rights to its proprietary code.

Much uncertainty surrounds the application of the GPL to proprietary code that is used with open source. The subject matter is by its nature complex; the GPL terms themselves are not clear and no court has interpreted them. Any strategy must take this uncertainty into account. There is, however, one GPL rule that may be particularly helpful, depending on a user's strategy: these mandates apply only to modified open source that is made public to third parties, not to modified open source that is used internally, even if used to provide services to customers, as long as the actual modified software is not distributed. A user has no affirmative duty to publish any modified open source under the GPL.

On the other hand, if a company does choose to distribute or publish GPL code that it has somehow modified, these general rules will apply to that published software:

• If the company modifies GPL software, or if a part of GPL software is added to some proprietary code, then the modified work must be made freely available.
• 
  
• If the company combines proprietary code with GPL software, and the resulting product is published as a whole work, then the same result follows. What is considered a "whole work" will likely turn on a number of technical issues, such as how closely the programs interact, how they are linked, and how the proprietary program loads with the Linux kernel.
• 
  
• On the other hand, if the company's proprietary code combined with GPL software is identifiable and reasonably considered independent and separate, then it may remain free of the GPL taint when distributed as a separate work. In addition, merely placing a proprietary program on the same storage medium with GPL software does not taint the proprietary code.

Interestingly, the enforceability of the GPL has become an issue in the SCO suit. IBM has asserted that SCO violated the GPL by distributing its own versions of Linux under a claim of ownership. SCO has responded by asserting that the GPL contravenes the Copyright Act and, accordingly, is unenforceable. Based on what we know of SCO's assertions, we think they will likely not succeed.

Developing a strategy to avoid the "GPL taint" is not simple. The rules and their application in a particular case are difficult and the consequences of being wrong are potentially severe. A company could lose rights to its proprietary code, could be forced to disclose its trade secrets, and might even lose the right to use the underlying open source. The right strategy depends on a company's plans to modify and distribute open source and its development practices. As a general matter, users should know the license restrictions applicable to all of the open source they are using and modifying, and ensure that no open source code gets into any proprietary development project for software that may some day be commercialized.

For more information, please contact:

Rauer L. Meyer
415.369.7370
rlmeyer@thelenreid.com

Heather Stewart
415.369.7237
hstewart@thelenreid.com

©2004 By Thelen Reid & Priest LLP. This article has been published as an information service to clients and friends. Please recognize that the information is general in nature and must not be relied upon as legal advice. The authors, listed above, or your Thelen Reid attorney contact, would be happy to discuss the information in this article in greater detail and its application to your specific situation. We welcome your comments and suggestions.