Insight Center: Publications

Open Source Software: The Value of 'Free'

Author: David A. Wormser


Free can be hard to pass up, particularly for software developers under pressure to do more with less. Developers of all stripes, including those working on proprietary and other “closed source” solutions, have discovered the wealth of free and open source software (FOSS) circulating on the Internet.1 It’s not just Linux and MySQL and the other famous examples; it’s the incredible variety of utilities and programs published at no cost for the benefit of all comers. Why would anyone spend time and money to reinvent the proverbial wheel when the FOSS community has rolled it to your doorstep and invited you to take it?

The answer, of course, is that sometimes even “royalty free” can be too expensive. FOSS almost invariably comes with legal strings attached. Even big companies – including Microsoft,2 Cisco,3 and Palm4 and, most recently Best Buy, Samsung, Westinghouse, JVC and twelve other companies5 – have been accused publicly of violating FOSS license terms. Smaller FOSS users have encountered resistance from larger customers, potential investors and would-be acquirers concerned about the impact of FOSS on the user’s intellectual property rights.

Depending on the FOSS and the developer’s plans for it, complying with the applicable license may be relatively easy and painless. But, if a developer wants to avoid potentially serious consequences, it needs to take a systematic approach to managing the FOSS opportunity.

What’s the Problem?

FOSS, by its nature, presents both practical and legal challenges.

The practical challenge arises from the very ease with which anyone can acquire FOSS. There is often little about FOSS transactions that warn developers of any danger – FOSS license agreements, as often than not, are merely posted on the download site rather than presented as a click-through condition either for downloading or installing the code, which makes them easy to overlook. Developers, even if they do not overlook the license, are no more careful than lawyers or anyone else about actually reading them. Moreover, developers can generally acquire FOSS directly, without the participation of a legal or finance department, or any other part of his or her employer’s administrative infrastructure. Since FOSS transactions generally do not involve license fees or other similar payments, they have no direct budget effect and require no purchase orders, check requests or other similar paperwork to trigger legal and/or financial scrutiny.

The legal challenges flow from the terms of the license agreements themselves. The license agreements are essential to the developer’s legal ability to use FOSS code. In the words of one commonly used FOSS license form:

[N]othing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.6

Each license imposes a specific set of requirements and limitations on developers wanting to modify and/or redistribute the FOSS in question. Unfortunately, from the developer’s point of view, complying with the license can be complicated, particularly when the developer intends to use in a single software product FOSS from a variety of sources. The complexity results from several factors:

  • FOSS authors employ a wide variety of different licenses. The Open Software Initiative7 to date has approved about 60 distinct agreement forms as meeting its Open Source Definition.8 That does not count the license forms that OSI, for whatever reason, has not approved, or the unique variations created and used by individual FOSS authors.
  • FOSS license forms can be poorly written and maddeningly ambiguous. This problem is not unique to FOSS licenses, but undoubtedly is aggravated by the “free” nature of the transaction. In the closed source world, agreement forms tend to improve because vendors have an economic incentive to address customers’ questions and objections. No such incentives operate in the world of free software.
  • FOSS licenses almost universally include broad disclaimers relieving the author from any warranties regarding the software, and from any liability should the software turn out to be defective or to infringe the intellectual property rights of some third party. On the one hand, it is hard to argue that the author, having received no compensation for his or her contribution, should do more to protect the user. On the other hand, closed source vendors charging a license fee for their products can find it difficult to convince their customers to accept similar disclaimers, even with respect to the FOSS components.
  • Many FOSS licenses create unnecessary hurdles to integrating the FOSS code with other software, even other FOSS. Those licenses, in granting third parties the right to distribute the licensed code or software derived from it, require that the distribution be accomplished under terms and conditions that are identical to the terms of the original license. The requirement is manageable if the distributor is maintaining the FOSS as a standalone product, and is understandable to the extent it serves the FOSS community’s purpose of making all improvements to the original software available to the entire user community. It becomes unwieldy when a developer creates a single derivative work from multiple FOSS products, thereby subjecting itself to an obligation to distribute the derivative work under multiple different open source license forms.
  • More important, and more dangerous to closed source vendors, mixing FOSS with other code can turn an otherwise closed source software product into open source software.

This last point bears emphasizing. About half of all FOSS is licensed under the Free Software Foundation’s GNU General Public License (GPL),9 which requires that anyone who “conveys” a modified version of the licensed code – that is, anyone who propagates the code in a manner that enables other parties to make or receive copies – must also distribute source code for the modified version or notify the user how to get it. The GPL makes clear, moreover, that incorporating the covered software into a larger program turns the entire program into a “modification,” source code for which must be distributed or disclosed with the program in the same manner as the original FOSS. While the GPL imposes the source code disclosure requirement only on those who “propagate” their modifications, a little-known variant, the Affero GPL, imposes a similar obligation on software to which users are granted access through an ASP service, Software as a Service, cloud computing application or other similar services.

The Free Software Foundation describes the GPL’s requirement as “protective” of the author’s original intent that his or her software remain free. The closed source software industry describes the GPL as “viral,” because mishandled FOSS can infect otherwise closed source software products and require the developer to publish source code for those products.

Why Does Anyone Care?

Whatever the license requirements, software vendors who fail to comply may expose themselves to legal claims for breach of contract and copyright infringement.10 One might be tempted to dismiss contract claims; what, after all, are the monetary damages caused by someone misusing a product the author distributes for free? Copyright claims, however, can result in injunctions – court orders, requiring the vendor to cease misusing the FOSS code – and/or statutory damages intended to be punitive rather than to compensate the author for some specific loss. As suggested by the cases cited at the beginning of this article, the FOSS community has taken a page from the industries of closed source software, music and movies, and have begun looking for targets for these kinds of lawsuits.

The prospect of these types of claims, moreover, has gained increasing attention from other interested parties. Customers, particularly OEMs intending to include the vendor’s code in a larger hardware or software product, worry that the vendor’s code may “infect” the customer’s closed source products. Would-be investors and acquirers are also starting to ask tough questions about the paternity of their targets’ software products. They not only have added these questions to their due diligence, they have begun hire consulting companies to scan their targets’ source code for FOSS components. Bad results can be (and have been) used as an excuse to cancel transactions or to reduce the target’s valuation, and to require that sellers represent and warrant that they comply with the applicable FOSS licenses.

So, What’s a Software Vendor to Do?

Vendors wanting to take control of their FOSS exposure, particularly those that have been in business for a while, will want to initiate two separate but related initiatives. One of these initiatives should be focused on establishing policies and procedures for managing FOSS (and, for that matter, other inbound licensing) issues going forward. The other effort focuses on identifying and resolving FOSS issues that have snuck into their products in the past.

Vendors can run the two initiatives more or less simultaneously. It is true that creating the forward-looking policy may help guide the developer’s approach to existing issues and potential problems. It takes vigilance, though, to prevent the focus on developing the policy from becoming an excuse for doing nothing about the past.

Looking to the future: Vendors every day face the decision of whether to create a particular feature, function or capability in-house or buy it from a third party. The “make/buy” decision generally focuses on a cost/benefit analysis. When the make/buy question includes a FOSS alternative, evaluating the “cost” side of the equation needs to take account of more than the trade-off between lower/nonexistent license fees and the potentially higher support costs associated with managing code supported by the world at large. Vendors also need to account for the legal challenges outlined earlier in this article.

The evaluation process need not be long or complicated, but it should have enough buy-in from the relevant parties in the organization – business managers, development managers, development staff, the legal department, etc. – to ensure that those parties will cooperate in implementing it. And the process should include a handful of key elements:

1. Someone in charge. Someone in the organization needs to have primary responsibility for ensuring that the policy is written, supplemented and amended as necessary, and implemented on a consistent and continuous basis. It has become something of a mantra among management consultants that “when everyone is responsible, no one is responsible.” The mantra applies in this case in spades. Of course, responsibility is easier to fulfill if the responsible party also has sufficient support and resources from the remainder of the team.

2. Knowledgeable review. No developer should use FOSS without approval by someone familiar with FOSS issues and the vendor’s process for identifying and dealing with them. That someone might be legal counsel, or it might be another individual who has the time and patience to read a license agreement from end to end, and the ability to apply the license requirements to the situation at hand. Centralizing the review process among one or two or three reviewers will help build expertise and maintain consistency in the process.

3. A workable process. The reviewer will need a full understanding of the context in which the developer intends to use the code. Accordingly, the developer’s approval request should include all of the relevant facts including (i) the name of the third-party product and the source from which the developer has obtained it, (ii) a copy of the applicable license (because it is not always clear from an online search which license form, and which version of the form, applies), (iii) a brief explanation of the need the code is intended to fulfill, (iv) a brief explanation of how the third-party code will be combined/integrated/distributed with the developer’s closed source code and/or other software obtained from third parties, and (v) the manner in which the resulting product will be used and distributed.

The reviewer, in turn, should provide the developer with a clear, written statement of the effect of the applicable license on the developer’s plans – that is, the obligations the developer takes on by using the third-party code. A good reviewer may also suggest changes to the developer’s approach that might reduce the risks and burdens under the license. The reviewer, particularly in cases in which the third-party code is a closed source product, might also suggest changes to the license itself. (One change the developer might consider, depending on his or her plans for the software, is to require the vendor to disclose any FOSS code and licensing requirements that might come along with the software directly under review, and to warrant that the vendor is in compliance with those requirements.)

4. Knowledgeable implementation. Developers receiving the reviewer’s recommendations need to know what to do with them. Developers, or at least development managers, likely need training to understand how to follow the reviewer’s recommendations and the pitfalls associated with failing to do so.

5. Other safeguards. Every organization is different, and has a different culture, a different tolerance for risk and a different tolerance for bureaucracy and administrivia. The organization is most likely to follow a policy over the long term if it reflects the balance best suiting the organization.

6. Document, document, document! Every software vendor should expect to get the question sooner rather than later: What FOSS does the company use, in which of the company’s products and in what manner? The question may come from the Free Software Foundation investigating allegations of abuse. Or, it may come from a potential customer, investor, acquirer or other business partner. Irrespective of who might be asking the question, there will be two categories of vendors answering it. One category, call them the “Documenters,” will be able to produce records showing the FOSS policy itself, the review and approval memos created in the course of following the FOSS policy, and documentation tracking all of the third-party code going into the vendor’s product and the steps taken to comply with the applicable licenses. The other category of vendors, call them “Dreamers,” will be dreaming about how much easier life would have been if they had been Documenters.

Addressing the past. For organizations that have been in business for any length of time, putting the policy in place is only half the challenge. The other half is recognizing that developers, being developers, may well have stepped into the FOSS quicksand in the past, and that it will take work to ensure that the past does not torpedo all the good work put into developing and implementing the policy for the future. Here are some of the key steps in that work:


1. Perform triage. Prioritize the effort. Since one generally triggers FOSS license obligations by distributing (or “conveying”) FOSS or its derivatives to third parties, focus first on software products licensed or sold to others. Software made available online (for example, in Software as a Service or Application Service Provider arrangements) is next in priority, because some FOSS licenses (the Affero GPL, for example) are triggered by granting third parties network access to the code. Last in line will be software used purely for internal purposes.

2. Audit. Determine, for each closed source software product, what FOSS code is associated with the product, and how it is used with or in the product. Quiz developers about their use of FOSS in each product. If necessary, hire a third-party consultant – and there are several who have turned this into a business – to scan closed source products for FOSS. For each item of FOSS found, collect the information that would have (or should have) been included under the FOSS policy had it been in place at the time.

3. Remedy/replace. Review the FOSS license agreements and determine the steps required to bring each product into compliance. In some cases, the effort may be limited to adding copyright notices to the product itself and/or language to the product’s click-through license agreement. In other cases, it may be necessary to segregate the FOSS from the closed software and, since open source licenses can impose conflicting requirements, other FOSS, and develop APIs or other utilities to manage the interoperation of the various pieces. Publish source code for the modified or combined product if required by the FOSS license, or recognize the risks of not doing so. If and to the extent the remedy consists of replacing FOSS with home-grown closed software or code acquired from a third party, take care that the replacement code is created in a “clean room” by personnel who do not have (and have not had) access to the FOSS they are replacing. As the remedied product is released, make sure existing customers receive and implement the new releases. Recognize that fixing the problem does not necessarily erase or cure past violations, but the passage of time will make those violations less of an issue.

4. Repeat as necessary. “As necessary” may be as often as before each major release. Until the FOSS policy is in place, the review process will remain the vendor’s first line of defense. Even with a FOSS policy in place, some amount of unauthorized code may well slip through.


1 “Free software” in this context refers not to monetary cost, but rather to the extent of the freedoms the author grants to users of the software. For a discussion of the differences between “free software” and “open source software,” and one take on the philosophical differences between their respective proponents, see “Why ‘Free Software’ is better than ‘Open Source,’ www.gnu.org/philosophy/free-software-for-freedom.html. While at least one commentator predicts that “free” and “open source” camps will renew their fight in 2010, Byfield, “Open Source in 2010: Nine Predictions,” Datamation (Dec. 30, 2009), neither the skirmishes nor the underlying philosophies of the parties have much bearing on the responsibilities of the FOSS user.

2 See G. Keizer, “Repentant Microsoft Reissues Windows 7 Tool as Open Source,” ComputerWorld (Dec. 10, 2009).

3 R. Paul, “Cisco settles FSF GPL lawsuit, appoints compliance officer,” ARS Technica (May 21, 2009).

4 “Artifex Software Files Copyright Infringement Lawsuit Against Palm, Inc,” http://www.artifex.com/pressreleases/palm.htm (Dec. 2, 2009).

5 http://www.softwarefreedom.org/news/2009/dec/14/busybox-gpl-lawsuit/. This latest lawsuit, an enforcement action brought by the Software Freedom Conservancy, is notable because the claims involve DVD players, HDTVs and other hardware devices onto which FOSS has been loaded.

6 GNU General Public License v.3 (June 29, 2007). See www.gnu.org/licenses/gpl.html.

7 The Open Source Institute describes itself as “the stewards of the Open Source Definition (OSD) and the community-recognized body for reviewing and approving licenses as OSD-conformant.” www.opensource.org/about.

8 www.opensource.org/licenses/alphabetical. The Open Source Definition requires, among other things, that the license (i) allow unrestricted sale or distribution of the code, (ii) allow distribution of source code, and (iii) permit the creation of derivative works. See www.opensource.org/docs/osd.

9 See www.marketwatch.com/story/gplv3-licenses-quadruple-in-2009-but-gpl-projects-drop-by-five-percent-from-2008-levels.

10 See Jacobsen v. Katzer, 535 F.3d 1373 (Fed Cir. 2008).

David A. Wormser

The material in this publication was created as of the date set forth above and is based on laws, court decisions, administrative rulings and congressional materials that existed at that time, and should not be construed as legal advice or legal opinions on specific facts. The information in this publication is not intended to create, and the transmission and receipt of it does not constitute, a lawyer-client relationship.

Data protection laws have changed, so we have revised our Privacy Policy.