On May 3, 2001, Microsoft publicly described its “Shared Source” approach to source code licensing. Shared Source covers Microsoft’s spectrum of source access and licensing programs for its customers and partners. Microsoft has contrasted Shared Source with various open source software approaches, highlighting both similarities and differences. We encourage companies and individuals to consider carefully to what degree open source solutions make sense for them. While Microsoft does not oppose the concept of open source development, we do question the advisability of organizations’ dependence on the products of a non-commercial community rather than commercially developed products that have a sustainable business model behind them.

The general use of the term “open source” describes both the different community development processes and the vastly differing licenses under which these products are developed, modified and distributed. In particular, we are concerned about the GNU General Public License (GPL) which covers some of the most popular open source software such as Linux. The GPL was developed specifically to discourage the development of commercial software and eliminate the creation of any long-term economic value in intellectual property that emerges from a community development process. This license diminishes, or even eliminates, the symbiotic relationship between academic and government research and the entire business community. There are benefits to having both an “intellectual commons” and businesses built on the premise of owning and profiting from intellectual property assets.

Microsoft encourages companies to read and evaluate the GPL. Based upon feedback we have received to date, it appears that many businesses do not understand the GPL or its potential implications for important business issues. To highlight those issues, we drafted this document to give businesses interested in GPL software a list of questions to ask themselves and their lawyers, as well as some background that may be useful.

Although many businesses may not be acquainted with the GPL, most (if not all) of the following questions will be familiar to people who have studied the GPL. In fact, many of these questions have been the subject of considerable discussion within the open source community. The Free Software Foundation (www.fsf.org) publishes the GPL and hosts a corresponding FAQ (http://www.gnu.org/copyleft/gpl-faq.html). The comments in this document are based upon the Version 2 GPL, Version 2.1 Lesser General Public License (LGPL) and the GPL FAQ posted as of 5/30/01.

One last introductory note: the GPL is a complicated agreement. To understand your potential rights and obligations, you need to interpret the many provisions of the agreement and apply them to your particular facts. We recommend that you obtain counsel from your lawyer as appropriate. This document does not, and cannot, offer any legal advice.

1. Have your lawyers read the GPL (and the LGPL)? Because the GPL is so frequently misunderstood and because it attempts, under certain circumstances, to impose significant obligations on licensees and their intellectual property rights, no responsible business should use GPL software without ensuring that its lawyers have read the license and explained the business’ rights and obligations. They should also review and explain the Lesser General Public License, or LGPL, a related license that is sometimes used with open source libraries.
2. How are you using GPL software and what obligations does it impose? The obligations associated with the GPL vary substantially depending upon the way in which GPL code is used. Even limited or relatively obscure uses (e.g., including a few lines of GPL code in a commercial product or linking directly or indirectly to a GPL library) may have a dramatic effect on your legal rights and obligations. To understand the potential implications of the GPL, you need to have a detailed understanding of your use of GPL code. Basing any analysis upon a superficial understanding may present serious risks.
3. How does your use of GPL software affect your intellectual property rights? One of the most significant impacts of the GPL is its potential effect on your intellectual property rights. The GPL is widely referred to as “viral” because it attempts to subject independently-created code (and associated intellectual property) to the terms of the GPL if it is used in certain ways together with GPL code (see Sections 2 and 3 of the GPL). For example, a business that combines and distributes GPL code with its own proprietary code may be obligated to share with the rest of the world valuable intellectual property (including patent) rights in both code bases on a royalty free basis. Other uses of GPL code may also create obligations for the user. It is important to perform a careful legal and technical review of this issue before using GPL software.
4. What if you are simply a “customer,” acquiring GPL software from other businesses? Does the GPL have any effect on your rights and obligations? Section 0 of the GPL says “[a]ctivities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted.” So, a customer who only runs the Program should have no obligations to the author of the code under the GPL. As discussed below, however, such a customer also has no rights from the author (e.g., no assurance that the code is even free from “known” copyright infringement problems) and may have liabilities to third parties. If, on the other hand, the customer’s use of GPL code involves even limited modification, copying or distribution of the code, the GPL arguably does impose obligations to the author, discussed above and below. In assessing this possibility, customers should carefully consider what the GPL means by “copying, modifying and distribution.”
5. Can you develop applications for a GPL program, like Linux, without subjecting those applications to the GPL? This is a particularly important question. The answer will almost certainly depend upon a detailed analysis of the way in which the application was developed and distributed and will be subject to caveats regarding the interpretation and enforceability of the GPL. For example, the analysis will presumably involve a careful review of your development team’s exposure to and use of GPL code during the development process, especially whether the application incorporated any such code or was otherwise derived from it. The analysis would also likely consider what libraries are used; how are they used (e.g., statically linked or dynamically linked); whether they, in turn, link to other libraries; and which licenses (GPL or LGPL) govern all of these various libraries. Similarly, the analysis would probably consider what header files are used; whether they, in turn, include other headers; and which licenses govern these various headers. In addition, the analysis would presumably consider whether the application is distributed with GPL code and, if so, how it is distributed and by whom.
6. Can distribution of your code with GPL code require you to license your code under the GPL? Have you combined your own code with code licensed under the GPL? The GPL attempts to address these questions directly. Section 2 of the GPL says that identifiable sections of a work that are not derived from a GPL program and that “can be reasonably considered independent and separate” are not subject to the GPL when distributed as separate works. But if these separate sections are distributed “as part of a whole which is a work based on” a GPL program, then this distribution of the “work as a whole” is subject to the GPL. Section 2 also says that a “mere aggregation of another work not based on the [GPL] Program on a volume of a storage or distribution medium does not bring the other work under the scope of this License.” A licensee is left with the difficult task of deciding whether a particular combination is a “work as a whole” (GPL infection apparently intended) or a “mere aggregation” (GPL infection disclaimed).
7. If your software becomes “infected” by the GPL, do you have to give it away for free? Section 3 of the GPL says that you can copy and distribute a GPL program (or a work based on such a program) in object code or executable form, subject to several restrictions. You are supposed to make the corresponding source code available, for example, by including the source code with the object code or offering to distribute it to any third party (Section 3). Section 1 says that you “may charge a fee for the physical act of transferring a copy,” but Section 2 says that you “must cause any work that you distribute or publish, that in whole or in part contains or is derived from [a GPL] Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.” The net effect is, apparently, that you are able to charge a fee for your software, but that right is significantly undercut by your obligation to give others (including your competitors) the right to distribute your software for free.
8. Are your obligations under the GPL “flexible” or “proportional” to your use of GPL code? Suppose Business A uses a few hundred lines of GPL code in its existing 500,000-line proprietary program and makes copies for its own employees or distributes ten copies of the modified program as a collective work. Suppose Business B combines 500,000 lines of GPL code with an existing 1000-line proprietary program and distributes 500,000 copies of the modified program as a collective work. The GPL may be read as to require both businesses to share the source code for their modified programs (including their existing commercial programs) and allow royalty-free redistribution of those programs. This is true despite the potentially dramatic differences in the volume, value and copies of the GPL code used.
9. Do you have all of the rights required to use GPL code? Could your use of GPL code cause you to infringe on the intellectual property rights associated with code you have licensed from others? The seemingly obvious answer to the first question is “yes” because those rights are provided under the GPL. The correct answer, however, may require more careful analysis. If, for example, you plan to combine and distribute GPL code with pre-existing code, the “viral” nature of the GPL may require you to provide source code for the pre-existing code to all third parties and license others to use it on a royalty-free basis (see Section 2). Unfortunately, if you licensed some of the pre-existing code from a third party, you may not even have access to the source code, much less the right to license it to the rest of the world on a royalty-free basis under the terms of the GPL.
10. Do you have any existing obligations that might preclude your use of GPL software? Could your use of GPL code put you in breach of existing contractual obligations? As noted above, the use of GPL code with code licensed from another party could, under certain circumstances, arguably obligate you to sublicense the other party’s code under the GPL. If you expressly agreed not to attempt to sublicense the other party’s code, you should consider whether your use of the GPL code presents a risk that breaches your earlier contract. Even if no breach occurs, the GPL includes provisions that may make it impossible for licensees to retain both their GPL rights and rights under other agreements. For example, Section 7 of the GPL says that if “conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this license, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all.” Suppose Business A has developed a program using trade secret rights that were licensed from Business B under an agreement that prohibited their disclosure. Now assume that A uses GPL code in a way that “infects” its program. Section 7 apparently says that use of GPL code in such a program is impermissible. This places A in an untenable situation: unless it persuades B to divulge its trade secrets to the world, A must cease distribution of its program. This may be true even if A’s use of GPL code is minimal.
11. Have you considered the risk that GPL code might infringe on third party intellectual property rights? Although it is always difficult for a business to ensure that acquired products do not infringe on third-party intellectual property rights, the risks associated with the use of GPL software may be substantially higher than those associated with commercial software. For example, given the distributed nature of open source development, you should understand what controls, if any, you have in place to screen unlicensed code or trade secret information from inclusion in the GPL program. This view is perhaps reinforced by the fact that Section 11 of the GPL expressly disclaims any warranties, including presumably a warranty that the program is free from infringements of third-party copyrights or trade secrets known to the contributor. You should also ask yourself if GPL developers may conclude that this disclaimer makes it okay to distribute code under the GPL when they know they don’t have the rights required to do so. Developers of commercial software, in contrast, typically have procedures, contractual obligations, and a substantial financial stake in minimizing potential infringements.
12. What happens if an intellectual property owner, who claims that your use of GPL code infringes its intellectual property rights, sues you? As noted above, Section 11 suggests that you are “on your own” with respect to defense of the suit and payment for damages.
13. What is the extent of your liability for GPL-related infringements? Several provisions of the GPL may be read as requiring a GPL licensee to effectively sublicense its rights to the rest of the world (e.g., Section 2, relating to the modification and distribution of GPL works). GPL licensees should ask themselves whether, and to what extent, they might be responsible for the actions of their sub-licensees. For example, suppose Business A distributes a modified copy of GPL code to Businesses B, C, and D, and each of them further distributes 1000 copies. If Business A is sued for patent infringement relating to its use of GPL software, the patent owner might claim that the business is liable for direct infringement based upon the three copies distributed to Businesses B, C, and D and is further liable for direct, contributory, or induced infringement by the 3000 additional copies distributed by these businesses (and, of course, any and all later distributions by such businesses and their downstream sub-licensees). While actual liability would depend upon a host of factual issues, if Business A has deeper pockets than the other businesses, it should not be surprised to find plaintiff’s counsel pursuing such an approach and claiming theoretically unlimited damages caused by Business A’s limited initial distribution.
14. Can the author of a GPL program “unilaterally” withdraw your right to distribute the program? Section 8 of the GPL gives “the original copyright holder who places the Program under this License” the right to preclude distribution in certain countries based on patents or interface copyrights. It is not clear that a licensee has any right to object to this restriction, which may be solely within the discretion of the original copyright holder. It is also not clear whether this restriction can be imposed retroactively, although Section 8 does say, “this License incorporates the limitation as if written in the body of this License.” Companies relying on GPL code should carefully consider the potential impact such a geographical restriction could have on their business.
15. Can you use GPL tools in the development of your own software without subjecting your software to the GPL? As noted above, the GPL is sometimes referred to as being “viral” because it attempts to subject related third-party code and intellectual property to the GPL. People concerned about this aspect of the GPL are probably careful about modifying GPL programs or combining their code with GPL code, but they may assume that their use of GPL tools cannot “infect” the software they are developing. While this is probably true in many cases, it is not necessarily a safe assumption. For example, the “Bison” parser developed by Richard Stallman, Robert Corbett and Wilfred Hansen was licensed under the GPL for some time before users realized that the software they were developing with the tool was arguably subject to the GPL. The potential exposure resulted from the parser’s inclusion of incidental GPL material in the tool’s output. In response to this problem, Bison version 1.24 and later was distributed with a “special exception” regarding output files. The implication is that businesses concerned about the possible infection of their software by the GPL should make sure they consider: what, if any, GPL tools are being used by their developers; how those tools are used; and the possibility that such uses might subject their own code to the GPL.
16. If the GPL requires you to “contribute” your modifications to GPL code to “the community,” are you sure that your competitors are doing the same? Assuming that two competitors are making similar use of GPL code, their obligations under the GPL should be the same. There are, however, a number of scenarios to consider. Some competitors may not understand their obligations under the GPL and, for that reason, might not share their improvements with competitors. Other competitors’ interpretation of the GPL might lead them to conclude that they have no obligation because they might believe the GPL is unenforceable in its entirety. Some competitors may intentionally ignore their obligations under the GPL to obtain a competitive advantage, relying on a variety of factors to avoid compliance. These factors might include obscuring object code to hide use of GPL code and the strength and enforcement of intellectual property laws in the country where they are doing business.
17. Does the GPL present any special challenges for businesses developing or distributing products with embedded software? The GPL does not expressly impose any “special” obligations on embedded software businesses, but embedded businesses should consider whether the GPL presents any unique risks based upon scenarios common to the embedded product space. For example, the manufacturer of a hardware system that includes some embedded GPL software and some of the manufacturer’s own proprietary software may find it particularly important to carefully assess whether the GPL and proprietary software form a “mere aggregation” (GPL infection disclaimed under Section 2); a “collective work” (GPL infection apparently intended); or something else altogether. Some embedded software developers, such as Caldera and Wind River, have publicly expressed concerns about the risks associated with the GPL.
18. Are your software developers aware of the many development-related issues that may affect GPL risks and obligations? Are you asking (or allowing) them to act as your legal counsel and are you willing to accept that risk? Are you “betting your business” on informal or anonymous interpretations of the GPL posted on the Internet? As noted by the Free Software Foundation (FSF), the potential implications of the GPL on software development ultimately depend on the way in which judges will interpret provisions of the GPL. A host of relatively detailed, development-related questions are also likely to be critical. You should probably make sure your developers are asking themselves a number of questions, including:

• What is the provenance of the code and tools being used?
• What licenses govern that code and tools
• What do we do if we can’t determine which license governs code included in an open source distribution
• What happens if those licensing terms have been clarified or purportedly amended
• Does our code use GPL code at runtime, whether through kernel calls, dynamic linkage, static linkage, or other mechanisms; if we are using libraries, do those libraries, in turn, link to other libraries (and, if so, which licenses govern those libraries)?
• If we are using headers, do they reference other headers (and, if so, which licenses govern those headers)?
• Will our code be distributed, combined or otherwise used with GPL code?
• Are we sure about our answers to these questions?

1. Who can you go to if you have a question regarding the GPL’s interpretation, want to clarify your risks under the GPL, or amend your obligations? The GPL was developed under the auspices of the FSF. The FSF is not, however, necessarily the owner of any and all intellectual property rights embodied in particular programs licensed under the GPL. Section 10 recognizes this by suggesting that a GPL licensee could write to a program’s author (or authors) for permission to distribute the program under different terms. In some cases, no single person or entity may own all of these property rights. As a result, a prospective (or existing) GPL licensee may find it impractical, if not impossible, to negotiate a desired change in its rights and obligations or even obtain a clarification of those rights and obligations. Even if a licensee were somehow able to identify key contributors and reach agreement with all of them regarding a desired change or clarification, presumably those contributors would be unwilling or unable to represent and warrant that they had the entire right and title required to do so.
2. Are you using any software governed by the Lesser General Public License (LGPL) and, if so, how does that license affect your rights and obligations? The LGPL was developed by the FSF to give library developers an alternative to the GPL. Specifically, although the FSF generally discourages use of the LGPL, it notes that “using the Library GPL permits use of the library in commercial programs.” The LGPL retains the “viral” provisions of the GPL in the context of modifications to an LGPL library (Section 2). But a different set of obligations are imposed when code is linked to an LGPL library (Sections 5 and 6). If you are developing programs that link to LGPL libraries you should review and understand these obligations. You should also check whether the LGPL libraries used, in turn, link to other libraries and especially consider the implications if the LGPL library links to a GPL library.
3. Does the use of GPL software reduce the acquisition value of your company (as a start-up) or a particular business unit (as a spin-off)? As noted above, the GPL attempts, under certain circumstances, to subject licensees’ code and related intellectual property to the terms of the GPL (see, e.g., Section 3). Once your software is “infected” by the GPL, it is not clear whether and how this process can be reversed. So, while GPL code may seem like an inexpensive, convenient and useful way for a start-up to develop a new product quickly, it may also have costly and long-term consequences for the start-up. Parties interested in acquiring the business are likely to conclude, as a part of any acquisition due diligence, that the business has already effectively given away most of the commercial value in its code.
4. Does your use of GPL code present any issues re shareholder value and exposure to suit? In the context of initial public offerings, at least some businesses based upon GPL software have concluded that such software introduces risks that should be disclosed as part of the offering. These risks include: the companies “inability” to offer warranties and indemnities because the code is developed by independent parties over whom the offering business has no control or supervision; the uncertain future of the code base (will further development occur and, if so, in what direction); the availability of the same code from other sources for free; and concerns about negative reactions from the open source community. (These issues are discussed in the “10Ks” of several of the publicly traded companies that distribute GPL programs). If you are beginning to use GPL code, you should ask whether this presents similar risks to your business.
5. Do you have a process for reviewing and approving prospective uses of GPL software? Are you willing to use precious developer resources required to assess the impact of prospective uses of GPL code that you will depend on? Most businesses that are engaged in software development establish procedures to avoid tainting their development process with software that is subject to other people’s intellectual property rights. Although GPL code is often described as “free,” as noted above it may impose severe obligations on users and is perhaps even more deserving of a company-wide process regarding review and approval before use.
6. Do you have or need any special procedures regarding potential GPL issues created by your licensing of third-party software and or acquisitions of software? Given the potential effect that the GPL may have on code and intellectual property acquired by (or licensed into) a company, it may make sense for businesses to develop procedures to ensure that such acquisitions and licenses are reviewed for GPL issues. For example, many companies have established “due diligence” procedures to help them identify and evaluate potential issues associated with the acquisition of businesses, product lines, and intellectual property rights. Companies pursuing software-related acquisitions or investments should probably consider whether their due diligence procedures should be updated to specifically address GPL-related issues.