Open Source Software: Avoiding The Risk And Gaining The Rewards

“There is no such thing as a free lunch,” at least according to economist Milton Friedman.

Yet, at first glance, open source software seems to be an exception to that rule.

Open source software is freely available, high-quality and distributed under license terms that allow others to modify, enhance, and redistribute it. What’s not to like? To the average (technically challenged) person, tweaking a word processing program to work better with a document management system might be significantly less desirable than having wisdom teeth pulled.

But for businesses with skilled IT staff, the task is not nearly as daunting, and the potential license fee savings is attractive.

From a legal perspective, though, the lunch is not free. Open source software carries two primary legal risks. First, almost all open source software comes without a warranty of title or non-infringement, and no indemnity protection. Second, some of it requires derivatives of the code to be licensed under the same open license – thereby requiring disclosure of the source code (the form of the code used to modify the software) of any derivative.

Introducing Open Source

No single agreement covers all open-source software. The GNU General Public License (GPL), the BSD License, the Mozilla Public License, and the Apache Software License are just a few of the more popular licenses. Aside from granting a broad license and disclaiming liability, each license contains its own set of terms.

For example, many open source licenses are academic licenses, written by schools wanting to make their developments generally available, and receive credit for doing so, but that avoid liability. Most of these licenses only require that a copyright legend and a disclaimer of liability accompany products into which the software has been incorporated.

Other licenses have provisions regarding patents and regarding source code disclosure. It is important therefore to consider each license in the context of how the software is being used.

Open Source And Infringement

Open source code typically is made available by its authors without charge. They contribute dozens – maybe hundreds – of hours of their time merely to make “good code” and receive an attribution buried within the inner workings of your software. It seems reasonable then that this software is almost always provided AS IS – without warranty or indemnity of any sort.

Last year’s suits by The SCO Group against IBM and several of its customers raised awareness about businesses’ use of open source. Among SCO’s many assertions is a claim that portions of Linux are code stolen from SCO’s version of Unix.

If true, then every corporation using Linux is a potential infringer of SCO’s copyrights, they said, and offered to license Linux users for a mere $700 a machine. The open source community has been very vocal about questioning the veracity of SCO’s claims and, at the moment, the lawsuits do not seem to be yielding any quick returns for SCO.

Microsoft, however, appears to be using SCO as the unofficial basis for a new marketing campaign. Extending its indemnification program slightly, Microsoft is making a great deal of noise about standing behind its software.

Microsoft has a point. The fact is that you do not know where a programmer contributing code from his basement is getting that code. If it infringes third-party rights, all who use the code are potential infringers. Is Microsoft’s limited indemnification better than none?

Open source aficionados point out that not all open source is equal. Different open source “projects” spring from different communities. Some communities are large, well-respected and likely to respond actively to any infringement threat (by rewriting the code or documenting its origin).

Depending on the size and dedication of project community standing behind a program, it also may be secure, well supported, and no more risky from an infringement perspective than commercial software from a medium sized vendor. The overwhelming community response to SCO is just one example. Red Hat, Novell, HP and IBM all now offer or contributed to indemnities and defense funds as a result of the SCO claims.

Open Source And Code Disclosure

At the other end of the spectrum from the very simple academic licenses is one of the more popular open source licenses, the General Public License (GPL), which covers many of the programs incorporated into the Linux operating system.

The innovation of a software developer frustrated by his inability to access the proprietary source code for a printer he wanted to fix, the GPL licenses distribution of modified versions of the covered program only if the source code for the modifications is distributed and licensed under the terms of the GPL.

This concept, called “copyleft,” was designed to be at odds with most commercial licenses and to use copyright protection against itself to force the disclosure of source code.

For software companies using open source in their development, open source thus presents a sticky issue – copyleft licenses may require a company to release source code it might wish to keep proprietary. Although a court never has required a company to do so, and the Free Software Foundation – which administers the GPL – has said that they would not ask a court do so, someone else (e.g., another open-source licensor, or a competitor) might ask a court to do just that.

Because of this, sophisticated buyers and investors now run code scans before they purchase or invest in software companies. If your company is seeking purchase or investment, you should understand what open source you are using. Most acquirers will buy a company that can identify and explain its open source. However, finding open source of which management is unaware can delay, and may occasionally kill, a transaction.

In Sum

Open Source presents too compelling a business case to just ignore – the trick is to manage the procurement and use of open source just as carefully as you manage the procurement and use of commercial software. In-house counsel should review the license terms before the software is brought in, and appropriately weigh the potential risks against the practical benefits. Handled responsibly, open source can be a beneficial tool for any enterprise. It isn’t a free lunch, but it need not be a wedding reception at the Ritz.