Open Source or Open Sores?
The open source software (OSS) movement has been getting a lot of press lately as a result of the lawsuit filed by the SCO Group against IBM. Ever since the inception of the OSS movement, there has been speculation about the enforceability of OSS licenses, and, at some level, a recognition of the risks inherent in the use of OSS. All of which begs the question, what the heck is OSS. In this article, I will attempt to scratch the surface of the open source movement, the SCO v. IBM case, and provide some basic practice pointers for clients using OSS.
The history of the open source movement, and the Linux operating system which is at the heart of the SCO v. IBM lawsuit, reads a bit like Grisham on Geeks. Richard Stallman was a Massachusetts Institute of Technology researcher, who in the 1980’s started a project to write from scratch a Unix clone software program. He dubbed his version GNU, which is said to be a recursive acronym for “GNU’s not Unix.” Stallman’s idea, which he publicly and fervently advocated, was that software (and more importantly, the source code to the software) should be freely available to all. Accordingly, he intended to make his GNU software freely available for all to run, copy, distribute, study, change and improve. In order to promote his view of free range software, Stallman came up with a legally innovative approach to attempt to ensure that his code would remain free and open by authoring the GNU General Public License, which Stallman first penned in 1989. Although the GPL is somewhat convoluted and confusing, it essentially says “take this code and use it, tinker with it, and distribute it. But, if you tinker with it and then distribute it, you must distribute it under the GPL and thereby allow others to see, copy, distribute, change, improve and further distribute, the software.” This is a somewhat novel use of copyright law in that Stallman and the other authors of open source code retain copyright ownership in the code, and basically agree to refrain from enforcing their copyright rights only so long as the other users/licensees of the software follow the GPL (or other applicable OSS license). If someone modifies the open source code, and tries to market it for a fee under a typical proprietary software license, where the licensee would not get the source code and the right to modify, enhance, create derivative works, etc., that would constitute a violation of the GPL, and thereby expose the perpetrator to copyright infringement liability. In other words, if you breach the GPL, then you can consider the permission granted by the copyright holder under the GPL “revoked” and liability for copyright infringement will follow. In this manner, the open source community attempts to foster an open environment for the development and improvement of the OSS.
Shortly after Stallman’s creation of the GNU/GPL, Dennis Torvalds in Finland began another effort to create a Unix like operating system to run on Intel processors. Torvalds’ work, to which many others contributed, became widely known as Linux. Linux is OSS offered under the GNU/GPL, and has been widely adopted. It is currently the fastest growing computer operating system, second only to Microsoft on total installations. The Linux operating system runs on web servers, desktop computers, and well as in electronic gadgets such as television recording devices, cell phones, and remote controls. It has been championed by companies like Cisco Systems, Motorola, Inc. and Phillips. An entire industry has sprung up around the installation, deployment and support of Linux operating systems. Red Hat, for example, is a publicly traded company that does nothing but provide support services for the Linux operating system. Additionally, traditional technology companies such as IBM, Hewlett Packard, and Sun Micro Systems have very substantial Linux consulting businesses.
The point is that Linux and the GNU/GPL are here to stay, and many of the legal questions surrounding the GPL and open source legal risks may be addressed or clarified for the first time in the SCO v. IBM case. It should be noted that Linux is not the only open source program that has gained wide acceptance, nor is the GPL the only open source license that is being widely used. For example, the open source program Sendmail currently sends 80% of all Internet email messages. Similarly, Apache, the open source web server software, is used on more than one-half of all the world’s web sites. These programs each have their own OSS license. In any event, almost any organization of substantial size will be using one or more OSS products within the organization. The Open Source Initiative maintains a list of “OSI certified open source software” and the associated license agreements at www.opensource.org.
So now the wildly successful open source deployment Linux has come under attack by a tiny Utah company known as the SCO Group. The SCO v. IBM case is complicated in terms of factual background and commercial history, with multiple license and transfer agreements, corporate mergers and acquisitions, and factual issues pertaining to who wrote and owned what when. The main issue, however, is whether Linux infringes on the copyrights of SCO, and whether the GPL is invalid under current copyright law. Accordingly, it is clear that any business using OSS should be aware of the legal issues unfolding in the SCO v. IBM case.
Essentially, SCO maintains that IBM, which had access to the proprietary version of Unix that SCO acquired from AT&T, copied large portions of that proprietary code into the publicly available open source Linux software, and thereby violated SCO’s copyright in that software. SCO has also sent letters to 1,500 of the world's largest companies advising them of its claims to a copyright in portions of Linux, and offering license deals. Not surprisingly, Microsoft, the largest competitor and staunch opponent of Linux and the open source movement, was SCO’s first licensee, for an undisclosed sum, a fact which has sparked speculation that the sum may be an amount that would pad SCO’s war chest significantly.
On a general level, the SCO case highlights two of the primary legal risks associated with the use of OSS. The first is that OSS is generally provided without any warranties or indemnities of any kind. The software is comprised of a compilation of contributions from a large decentralized and essentially unknown group of programmers. As a result, there is a risk (if not a likelihood) that proprietary code could have been contributed by one or more of those contributors, either knowingly or unknowingly. With the presence of proprietary code comes the risk of third party infringement claims.
The second main risk is sometimes described as the “viral effect” of licenses such as the GNU/GPL. If OSS is intermingled with proprietary code, under the GNU/GPL, that intermingled code, if distributed, must be distributed under the GNU/GPL, and the source code made available for all to see, improve, modify and further distribute, etc. So if OSS "infects" proprietary code, there is a concern that the owner of that proprietary code could be compelled to make their proprietary code open to all. Note, however, that the “viral effect” risk only arises when an organization intends to further distribute the software. If the software is only going to be used internally, there is no requirement that the modifications or improvements, or intermingled proprietary code be published or otherwise made available.
From this background, the following practice pointers are suggested:
- Make sure your clients understand the risks associated with the use of OSS.
- A related point is to know precisely what open source license applies to the particular software, as the terms can vary significantly from license to license.
- Consider asking for a representation in license agreements whereby the licensor warrants that there is no OSS in the licensed product. If the OSS is provided by a third party vendor, attempt to negotiate appropriate warranty and indemnity provisions from the vendor. (Although the open source licenses themselves do not offer any warranty or indemnity, they do not prohibit a distributor or service provider from offering them.)
- Educate your client’s internal development staff regarding these open source issues. This is particularly important if the client intends to distribute and commercially exploit the software under a traditional proprietary software license arrangement. There are oodles of open source programs and routines available on the Internet, and there is always the temptation on the part of a programmer to obtain an existing, proven routine, rather than to code one from scratch, and those are often made available under open source licenses. Moreover, many programmers are under the mistaken impression that OSS is synonymous with free ware or public domain software. As a result, OSS can easily seep into proprietary software development projects.
- Users of Linux should carefully watch the SCO v. IBM case. Additionally, if the Linux software was obtained through a third party vendor, the license agreement with that vendor should be carefully reviewed, particularly to determine whether it may be appropriate to provide a notice of a potential claim in light of the SCO lawsuit. Many license agreements, if any warranty or indemnity provisions are provided, require the licensee to provide the licensor with a notice of claim within a prescribed time period, or promptly upon notice of facts that a claim may be forthcoming.



Reader Comments