THE FOLLOWING PAPER ON A SUBJECT OF INTEREST IS POSTED FOR INFORMATIONAL
PURPOSES ONLY. THE VIEWS EXPRESSED IN IT HAVE NOT BEEN APPROVED BY, AND
SHOULD NOT BE CONSTRUED AS REPRESENTING THE POSITION OF, THE AMERICAN BAR
ASSOCIATION ("ABA") OR THE ABA SECTION OF INTELLECTUAL PROPERTY LAW.
OPEN SOURCE IN GOVERNMENT OUTSIDE THE USA:
A SNAPSHOT OF TODAY AND A FORECAST FOR TOMORROW
Montreal, Quebec, Canada
Don McGowan is an attorney with the Montreal office of Osler, Hoskin & Harcourt LLP. This paper would
not have been possible without the invaluable assistance of Dave Stoltenberg of the Montana Business
Incubator, Toni Tease, a solo practitioner and patent attorney and Chair of the Open Source Code
Subcommittee of the Committee #701 - Computer Programs of the ABA Section of Intellectual Property
Law, Craig Delger from InfoGears, Inc. in Bozeman, Montana, John Burns of Hunton & Williams in
Raleigh NC, and Benjamin Hayes of Kirkpatrick & Lockhart in Washington DC. Errors and omissions in
this article are attributable solely to Mr. McGowan and not to Osler, Hoskin & Harcourt LLP or any of its
attorneys, or any reviewer or other person named herein. Please note that these views have not been
approved by the House of Delegates or the Board of Governors of the American Bar Association and should
not be construed as representing the position of the American Bar Association nor the Section of Intellectual
The information in this paper is current to September 17, 2003. Note that all Internet links referenced in this
paper were live as of September 1, 2003 unless otherwise noted.
1. INTRODUCTION 3
2. OPEN SOURCE: DEFINITIONS AND CONCEPTS 4
2.1 “OPEN SOURCE” DEFINED 4
2.2 WHAT IS AN “OPEN SOURCE” LICENSE? 7
2.3 THE GPL: AN EXTREME (?) EXAMPLE OF AN OPEN SOURCE LICENSE 9
2.4 “SHARED SOURCE” AND THE “GOVERNMENT SECURITY PROGRAM” – ARE THESE
PROPRIETARY FORMS OF “OPEN SOURCE”? 11
3. OVERVIEW OF OPEN-SOURCE SOFTWARE USE BY GOVERNMENTS 13
3.1 AFRICA 14
3.2 THE AMERICAS 15
3.3 ASIA 16
3.4 AUSTRALIA AND NEW ZEALAND 18
3.5 EUROPE 18
4. IMPLICATIONS OF OPEN SOURCE FOR GOVERNMENTS 20
4.1 LICENSING AND ITS LIMITS: THE HIDDEN HAND OF US LAW 21
4.1.1 SCO LITIGATION 23
4.2 CREATING AND SUPPORTING LOCAL DEVELOPERS (BY LEGISLATION OR OTHERWISE) 26
4.2.1 LEGISLATING A SOLUTION: LAWS MANDATING OPEN SOURCE 28
4.2.2 RESOURCE ALLOCATION: IF GOVERNMENT WILL DEVELOP SOFTWARE, THEN WHAT KIND? 29
4.3 “SPYHOLES” AND PREVENTING OUTSIDE ACCESS TO GOVERNMENT INFORMATION 31
4.4 OPENNESS AND ITS ALTERNATIVES: CONSEQUENCES OF OPEN SOURCE FOR SOCIETY 36
5. CONCLUSION 40
“The future of software lies somewhere in a yet to be explored synergy between the clashing
cultures of the freeware and commercial worlds...”1
It is by now trite to say that intellectual property rights have become some of the most valuable
assets in the world economy. Their purchase, sale, and other commercialization has led to some
of the world’s greatest fortunes, to say nothing of the massively increased quality of life for those
people able to benefit from the products that have been developed and marketed in reliance upon
the protection that these rights have given.
The protection granted to intellectual property rights in Western legal systems is substantial.
Under most if not all systems of intellectual property right, a creator of an item to which
intellectual property rights apply is an owner, and has similar rights over the item created as the
owner of a physical product. As practitioners of intellectual property law know well, these rights
are limited in ways that may seem artificial or even counterintuitive to non-attorneys, and these
limitations on intellectual property rights are themselves able to be limited. If a customer wants a
particular piece of intellectual property badly enough, they are free to waive many if not all of
the rights that they would be provided under the law. In the world of software, many basic
intellectual property rights are buttressed, often significantly so, with license agreements.
One standard element of a software license is a restriction upon the user’s right to access and
work with the source code.2 But some software producers have declined to insist upon restrictive
terms in their licenses. When they provide software, they either do not prohibit the purchaser’s
accessing the source code, or in some cases they actually provide the source code along with the
software. In the industry, such software is often called “open source”. An acquirer of open-
source software3 is therefore able to have its own representatives examine the software and
determine whether it will fulfill the claims made for it by its producer; for some software, the
acquirer is even permitted to change the source code to produce better or even different effects.
While no one has claimed that the use of open source code software will usher in a thousand
years of peace and harmony, the missionary zeal shown by open source proponents is different
from the attitudes of the proponents of many other business practices. Advocates of the use of
open-source software describe themselves as members of the open source “movement,” a
descriptor not used for advocates of six-sigma management or double-entry bookkeeping. But
Keith Porterfield, Information Wants to be Valuable: A Report From the First O’Reilly PERL Conference,
While it is far beyond the scope of this paper to provide an in-depth description of the process of software
development, “source code” is the actual code written by the programmer, and is distinguished from “object
code” which is the set of instructions followed by the machine. A programmer will write source code in a
language such as C++, C#, or Visual Basic; that source code is not usable by the computer in that form, but
must be “compiled” into object code in order to be understood by the computer.
The term “open source” is a compound noun; in conformity with standard English and the recommendation of
the Open Source Institute, when used as an adjective in conjunction with a noun it will be hyphenated (e.g.
“open-source software”). See Open Source Institute, “FAQ” (www.opensource.org/advocacy/faq.php).
this is more than mere language; although “open source” is not equivalent to “without cost,”4
many open-source software producers have made their software cost-free and some open-source
software requires that any incorporation of that software will have to be distributed without cost
as well. It is perhaps that last “viral” aspect of open-source software that has caused a somewhat
visceral reaction from the producers of non-open-source software -- that and the sheer vitriol that
some members of the open-source movement heap upon them in public fora throughout the
However much open- and non-open-source software producers may disagree, open-source
software is certainly gaining in use around the world. While developments in the United States
have been circumscribed both by cultural preferences for private property rights and by the fact
that some of the most significant developers of non-open-source software are themselves based
in the United States, the use of open-source software outside the United States has gained some
level of acceptance. Especially in developing countries, some of the largest consumers of
information technology are governments, and around the world many governments are for
various reasons considering the use of open source as a viable if not preferred alternative to other
types of software. But the adoption of open-source software by government has implications
beyond computers and operating systems that both governments and open-source programmers
may not have considered and that may not be desired by one, the other, or both.
The first section of this paper is a discussion of what “open source” is and what it is not. Next,
the paper investigates current use of open-source software in government outside the USA.
Finally, this paper will analyze certain trends and predictions that can be discerned from the state
of open source today, and what its adoption in governments outside the USA would mean for the
direction those governments and the open source movement might take tomorrow.
2. Open Source: Definitions and Concepts
2.1 “Open Source” defined
Much confusion exists around the use of the term “open source”, and in particular by the
confusion arising from the use of the term “free” in conjunction with open-source software.
“Open source” software does not mean cost-free software, nor does it mean software in the
public domain.5 All the term “open source” would seem to mean in the strictest interpretation of
the term is that the source code for the software is made available to users of software. That is,
the product sold is in fact two distinct but intimately related elements: an executable program
file, and the source code that was compiled to make the executable program file. The source code
could be written in any language, such as Visual Basic6 or Java, and the programmer would
neither be required to provide either a compiler to render the source code into object code nor to
provide any explanation of the thought or technique behind the source code. Just by making the
About which, see more in section 2.1 of this paper.
See David Wheeler, Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!, 2003,
section 1 (www.dwheeler.com/oss_fs_why.html).
Id., section 9.11. Visual Basic is a Microsoft-created restricted-source programming language for Microsoft
Windows, but that does not mean it cannot itself be used to create open source. As of June 21, 2002, there were
at least 831 open-source programs written in Visual Basic and 8,867 total for the Microsoft Windows
source code available to users of the software, the programmer has left it “open”. In contrast,
where the source code is not made available to users of the software, that program is not “open
source” but rather something else.
Contrary to some perceptions, providing source code with compiled software is not particularly
unusual. Much customized software developed for a specific customer is delivered with the
source code having been either provided to the customer as well or placed in escrow. As IP and
licensing attorneys well know, software escrow agreements are commonplace and are
incorporated into commercial software development agreements for such reasons as protecting
the customer in the event of bankruptcy on the part of the developer or allowing verification of
the source code in the event of dispute as to the proper functioning of the software.7 Such source
code is “open” in the sense that it is there to be read and reviewed, but not in the sense that the
customer has any right to change it; in fact, another use of software escrow agreements is to
allow the producer to demonstrate that the code as delivered was different from the code as
compiled in a customer’s computer in order to avoid liability for such changes.
While organizations involved in the open source movement have noted the potential for a
baseline definition of “open source” as reflecting simply access to the source code, 8 the term as
commonly used in the open source movement does not reflect this baseline definition. As
Lawrence Lessig put it,
Proprietary software is like Kentucky Fried Chicken. Open source... is like
Kentucky Fried Chicken sold with the “original secret recipe” printed in bold on
As Lessig’s pithy description notes, “open source” software is commonly understood to reflect
additional elements and not just access to the source code.10 This essay will reserve the term
“open-source software” for software whose license fulfills additional criteria above and beyond
providing the source code along with the object code as described in section 2.2 of this paper.
“Open-source software” can then be distinguished from “provided-source software”, being
software whose source code is distributed along with the compiled program but without the right
to change or otherwise vary that source code, and “restricted-source software”, being software
whose source code is not distributed even for those limited reasons.
Id., section 9.3. As these same attorneys also know from experience, while governments today will pay for
custom-developed software, they tend to be the most insistent upon the full protection of software escrow
agreements; they also tend to require that software developed for them not be incorporated into any other
product or offering to the public. One open-source advocate has noted that “all [open-source] programs are
automatically in escrow” because their source code is open to the public, although this does not allow
governments the exclusivity that some would desire even today.
For example, the Open Source Initiative (“OSI”), an organization dedicated to the commercialization of open-
source software, notes that “Unfortunately, the term “open source” itself is subject to misuse, and because it’s
descriptive, it can’t be protected as a trademark (which would have been our first choice).” Open Source
Institute, OSI Certification Mark and Program (www.opensource.org/docs/certification_mark.php).
Lawrence Lessig, Open Source Baselines: Compared to What? ROBERT W. HAHN, ED., GOVERNMENT POLICY
TOWARD OPEN SOURCE SOFTWARE (2002) 50, 50.
For example, the OSI notes that the term “open source” has both a descriptive and a normative component, but
does not distinguish clearly between them. Open Source Institute, Frequently Asked Questions
“Open source” definitely does not mean “free”, or at least not in the sense that the term is often
understood.11 Some members of the open-source movement have adopted the word “free” to
describe their products and their ideology, then immediately redefine the word to exclude
“without cost” and limit it to “without restriction”.12 Other open-source advocates do not draw
this distinction, or at least do not do so clearly.13 The expression “information wants to be free”,
commonly used in discussions of open source, may be meant in the sense that “sharing
information should be unrestricted”, but all too often it is understood by recipients as meaning
“information should be shared without cost”.14 While some members of the open-source
movement go to great lengths to explain that “information wants to be free” does not mean that
information should have no cost,15 many companies and individuals have often found it hard to
understand or follow the shifting meanings of the word “free” used in the open-source
community. Some open-source advocates have recommended that the word “free” be avoided
precisely because of this ambiguity: they do not want open-source software to be confused with
software that is distributed without cost but also without the source code.16 Others have noted
that the word “free” tends to be used by those advocates who focus on issues of freedom from
control or other ethical issues, while “open source” is used more by people who promote the
perceived technological advantages of open-source software.17 Therefore, notwithstanding many
in-depth and well-explained rationales for referring to open-source software as “free” software18
The ambiguity derives from the fact that English uses the same word for both “without cost” and “without
restriction”, but many non-English languages do not. The French “gratuit” and the German “kostenlös” both
mean “without cost” and not “without restriction”, which are referred to as “libre” and “frei” respectively.
For example, both the GNU Public License (“GPL”) and the Lesser GNU Public License (“LGPL”) developed
by the Free Software Foundation (“FSF”) speak of “free” software and contain the following explanation of that
term: “When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are
designed to make sure that you have the freedom to distribute copies of free software (and charge for this
service if you wish), that you receive source code or can get it if you want it, that you can change the software
or use pieces of it in new free programs; and that you know you can do these things.” See Preamble, GPL,
version 2 (June 1999) (www.opensource.org/licenses/gpl-license.php);and Preamble, LGPL, version 2.1
(February 1999) (www.opensource.org/licenses/lgpl-license.php)
For example, the first of the OSI’s 10 Principles is of “Free Redistribution”, which uses the word “free” in the
traditional sense of “without cost”. See Open Source Institute, Definition
(www.opensource.org/docs/definition.php), where the requirement to keep distribution “free” is justified
because it will “eliminate the temptation to throw away many long-term gains in order to make a few short-term
For an interesting analysis of this expression and the implications in the ambiguity that it creates, see Richard T.
Kaser, If Information Wants to be Free... Then Who’s Going to Pay for It?, 6 D-LIB MAGAZINE
(www.dlib.org/dlib/may00/kaser/05kaser.html). Kaser notes a third usage of “free”, namely “free from
conventional structure”, but this usage is not common in discussions of open source.
See e.g. Eric Steven Raymond, The ‘Information Wants to be Free’ Myth, THE MAGIC CAULDRON
See e.g. the OSI’s position that it would be undesirable for Microsoft Internet Explorer to be called “free”
simply because it is distributed at no cost. Open Source Institute, Why “Free” Software is too Ambiguous
Wheeler, supra note 5.
See e.g. RAJANI, NIRANJAN. FREE AS IN EDUCATION: SIGNIFICANCE OF THE FREE/LIBRE AND OPEN SOURCE
SOFTWARE FOR DEVELOPING COUNTRIES (2003) (www.maailma.kaapeli.fi/FLOSSReport1.0.html). Note that
and also notwithstanding that many open source advocates use the word in this context,19 it
should be avoided. While intellectual property law is replete with specialized terminology having
a technical meaning or even common words used in a technical manner,20 the ambiguity in the
word “free” militates in favor of adopting a different term at least for the purposes of legal
2.2 What is an “open source” license?
It may seem somewhat ironic that open software is distributed under the terms of some rather
strict licenses. Certainly, the complexity of open source licenses is no less than that of
commercial software, and some governments that have allowed the use of GPL-licensed
software have noted this complexity and advised agencies using such software to consult their
legal counsel for interpretation of open source licenses.22 In fact, the use of licenses reflects a
conscious decision by open-source software developers to preserve and protect not just software
but the political decisions inherent in the development of “open-source” software, and to do so in
the context of traditional legal vehicles. Under both the civil and the common law, licenses are
used to effect a grant of rights from a rightsholder to another person. They are contracts like any
other, and they are intended to have the effects of contracts.23 In particular, open source licenses
purport to control not just the use to which users can put open-source software, but also the use
that such people may make of the source code provided along with the software.
The OSI sets forth a series of 10 criteria for it to consider a license to be “open source”:24
Rajani’s article is very long and does not have section numbers, making it difficult to cite to sections with any
Although many do not: see e.g. the OSI’s decision to adopt the term “open source” to avoid the “confrontational
attitude” that many proponents of the term “free” have had. Open Source Institute, History of the OSI
Such as fair use, which has a specific technical meaning to lawyers as a defence to copyright infringement
claims but which to the average member of the public means something more broad, such as “I’m being
reasonable in how I’m using this copyrighted information”. See Kaser, supra note 14.
At least, different terms should be used unless and until the word “free” is commonly-used and understood in
the sense of “without restriction” when discussing software. At present, using the word “free” in the context of
software carries a rehabilitative implication not dissimilar to the attempt to rehabilitate the word “hacker” by
dissociating it from criminal activity; for more on this other attempt, see RAJANI, supra note 18. While words in
English can and do change their primary meanings and lose their political overtones (one obvious example is
the word “gay”, which no longer carries its prior primary meaning of “happy” although it can still be used in
that sense), the term “free” in conjunction with software has not reached that point.
For example, the US Department of Defense has taken the position that “[as open source] licensing provisions
may be complex, the DoD Components are strongly encouraged to consult their legal counsel to ensure that the
legal implications of the particular license are fully understood.” See memo from John P. Stenbit, Chief
Information Officer, Department of Defense, May 28, 2003 (www.egovos.org/pdf/OSSinDoD.pdf).
See e.g. LAWRENCE LESSIG, CODE AND OTHER LAWS OF CYBERSPACE 105 (1999) where he describes the GPL
as “a contract that sets the terms that control the future use of much open source software”.
These criteria (referred to in this essay as the “OSI’s 10 Principles”) are set forth in more detail and with an
explanation of the principles and rationales behind thereby the OSI on its website. See OSI supra note 13. The
OSI’s 10 Principles are derived from the Debian Free Software Guidelines. See OSI supra note 19.
1. Free Redistribution: The license must not restrict any person from selling or giving away
2. Source Code: The program must be distributed with source code or with a well-publicized
means for obtaining the source code, and must allow distribution in source code and
3. Derived Works: The license must allow for users to modify and derive their own works
from the original work, and to distribute their works under the same terms as the original
4. Integrity of the Author’s Source Code: The license may permit authors to prohibit
downstream works so long as the license allows for downstream users to create “patch files”
that will integrate into the upstream work to create the new work,27 and may permit upstream
programmers to require that downstream versions will carry a new name or version number.
5. Non-discrimination (personal criteria): The license must not prohibit distribution of the
software to a person or group based upon discriminatory criteria, even where the jurisdiction
in which the software is created may have laws prohibiting such distribution (e.g. U.S. export
control laws that prohibit distribution of certain products to countries such as North Korea,
Iran, and Cuba).
6. Non-discrimination (usage criteria): The license must not prohibit use of the software for a
particular purpose (e.g. the license may not prohibit use of the software by a company).
7. Self-contained licenses: The license must contain all the conditions of use of the software
(e.g. no non-disclosure agreements may be required for use or obtaining the software).
8. Product-neutral licenses: The license may not require the software to be distributed with
other products or software.
9. Non-restrictive licenses: The license may not set restrictions on the other software that is
distributed with the software (e.g. by requiring that all other software distributed on the same
medium be open source).
10. Technology-neutral licenses: The license may not be predicated upon the use of any
particular technology or style of interface.
Contrary to popular opinion, an open source license, even one that meets the OSI’s 10 Principles, does not
require that the software be distributed free of charge. Many companies have developed OSI-approved open
source licenses that involve the product’s being sold for a profit. See e.g. IBM’s Public Source License version
In keeping with software industry nomenclature, such works are referred to in this essay as “downstream”
works and the work from which they are derived is called the “upstream” work. This avoids the use of the term
of art “derivative”, which has a technical meaning in US copyright law that may not be applicable or applicable
in the same way outside the United States.
For people who do not code software, this may be a difficult concept to understand: think of a jurisdiction
where it is unlawful to sell a mixed drink, but not to sell a glass of orange juice and a shot of vodka for mixing
by the customer. The upstream provider furnishes a program that cannot be distributed in a mixed form by a
downstream programmer, but must allow the downstream programmer to provide both the original program and
the additional element to be added to make the new mixed program.
On its website, the OSI provides links to and copies of 47 different licenses that it has declared to
be consistent with these 10 Principles,28 and it has developed a certification mark to be used to
accompany products whose licenses are consistent with the OSI’s 10 Principles.29 In addition, a
developer who wishes to create a new open source license consistent with the OSI’s 10
Principles and receive the OSI’s certification mark may do so by submitting that license to the
OSI for comment and approval.30
2.3 The GPL: An extreme (?) example of an open source license
Of these open source licenses, the GPL is arguably one of the most controversial and is certainly
one of the most political. In its Preamble, the GPL sets forth that it is far more than simply a
means of stipulating the usage rights of a downstream user of software. According to the GPL,
“[t]he licenses for most software are designed to take away your freedom to share and change it.
By contrast, the GNU General Public License is intended to guarantee your freedom to share and
change free software--to make sure the software is free for all its users.”31 And by “free” the GPL
would mean both senses of the word: without restriction and without cost. One of the aims of the
GPL is to push for-profit software out of the marketplace.32
The GPL also contains provisions that go beyond the OSI’s 10 Principles. For example, the GPL
not only clearly disclaims any warranty for the software,33 but it may prohibit anyone from
offering a warranty for GPL-licensed software;34 this disclaimer may create issues in non-U.S.
legal systems where warranties in the consumer goods context cannot be waived even by
However, the most controversial element of the GPL is what has been described by some people
as its “viral” nature: any program based upon a program to which the GPL applies becomes itself
Open Source Institute, Open Source Licenses (www.opensource.org/licenses/index.html). The 43rd-47th licenses
were added on September 3, 2003.
OSI, supra note 8.
GPL, supra note 12, Preamble. See also LGPL, supra note 12, Preamble, which contains a similar stipulation
changed for the context of the LGPL.
David S. Evans, Politics and Programming: Government preferences for Promoting Open Source Software,
HAHN, ED. 34, 39.
GPL, supra note 12, Preamble and sections 11-12; LGPL, supra note 12, Preamble and sections 15-16 contain
identical text. So as not to single out the GPL and the LGPL for unfair criticism, it should be noted that many
open source licenses contain similar language purporting to waive warranties that are unwaivable in many
jurisdictions: see section 4.1 of this paper for more on this point.
GPL, supra note 12. While section 1 of the GPL states that a person “may at [their] option offer warranty
protection in exchange for a fee” and section 12 of the GPL states that “in no event unless required by
applicable law or agreed to in writing will any copyright holder, or any other party who may modify and/or
redistribute the program as permitted above, be liable to [the user] for damages”, the Preamble to the GPL states
to the contrary that “we want to make certain that everyone understands that there is no warranty for this free
software”. See also the section of the GPL entitled “How to Apply these Terms to Your New Programs”, which
suggests the use of the command “show w” to call up section 12 of the GPL.
See section 4.1 of this paper for more on this point.
- 10 -
subject to the GPL, whether the author wants it to be or not.36 While the GPL does not purport to
affect upstream code, it does purport to place severe criteria upon downstream use of GPL-
licensed code, and it would probably not be overstating the case to say that the viral nature of the
GPL strikes fear into the hearts of restricted-source software developers.37 If a programmer
working for a restricted-source software development company creates a module or section of a
program using code derived from a GPL-licensed program, not only does that portion of the
program remain GPL-licensed (requiring the company to distribute the source code for that
module or section), but under the terms of the GPL the entire program becomes open source as a
result of the decision to use the GPL-licensed code.38 That is, use of GPL-licensed code in a
small portion of a program results in the whole program’s being subject to the GPL.39 This goes
far beyond the OSI’s requirements for open-source software, under which the license must allow
modifications to be distributed on the basis of the original license; the GPL requires that
modifications must be distributed in accordance with the GPL.40
While it is questionable as to whether there is anyone with standing to enforce the GPL
especially outside of the United States,41 this “viral” nature of the license and the uncertainty
surrounding that status has caused restricted-source software producers to take notice of the GPL
and to be concerned that it will cause their proprietary technologies to become open source in all
senses of that term.42 Even under the OSI’s 10 Principles, it is not a requirement of open source
GPL, supra note 12, section 6. This is a direct consequence of the GPL’s applying not just to the program itself
but also to “any derivative work under copyright law” (Id. section 0).
See e.g. Craig Mundie, The Commercial Software Model
(www.microsoft.com/resources/sharedsource/Initiative/speeches/mundie.mspx) where Craig Mundie,
Microsoft’s CTO, called the viral nature of the GPL “a threat to the intellectual property of any organization
making use of it.”
See GPL, supra note 12, section 5 for this principle: “by modifying or distributing the Program (or any work
based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions
for copying, distributing or modifying the Program or works based on it.”
Moreover, the FSF has recognized the possibility that a programmer may wish to create a software library that
is open source but that can also be used by restricted-source programs without rendering those programs open
source (in order that the software library may become a de facto industry standard). To deal with this situation,
the FSF created the LGPL, which it describes as a hybrid between the GPL and the BSD licenses. The LGPL
specifically allows restricted-source programs to link to an LGPL-licensed library and to rely upon that library
in its operation without itself becoming open source (at section 5 of the LGPL). That is, programs upstream
from the LGPL-licensed library are not themselves made subject to the LGPL. However, programs downstream
from the LGPL-licensed library are subject to it.
RAJANI, supra note 18.
Again in the interest of avoiding an unfair emphasis on the GPL, it should be immediately noted that the same
issue arises with most if not all other open source licenses.
Interestingly, open source and the GPL have not been so threatening to software companies that they are afraid
to pay money to acquire open source and even GPL-licensed products. Microsoft’s first TCP/IP stack was a
BSD-licensed, open source implementation (although this has since been replaced by a restricted-source
alternative developed by Microsoft), its Hotmail® service has several servers in the stack running on FreeBSD,
and its Services for UNIX package includes both restricted-source and over 200 open-source tools, including
some governed by the GPL. Jason Matusow, Is This the Right Room for an Argument?
(www.microsoft.com/resources/sharedsource/Initiative/speeches/OReilly.mspx). Note also that where Microsoft
has changed the code for its GPL-licensed products, it has been scrupulous about releasing those changes to the
- 11 -
that the license be applied to downstream works.43 The choice by FSF to require downstream
works to be open source may have serious implications in the use of GPL-licensed software by
2.4 “Shared source” and the “Government Security Program” – are these
proprietary forms of “open source”?
While many members of the open-source movement would contend that open source “is not an
attack directed at specific companies,”45 it is impossible upon reading even random headlines to
contend that the open-source community has defined itself in opposition to a perceived common
foe: Microsoft.46 Far and away the largest restricted-source software company in the world,
Microsoft has recently moved slightly away from its prior perceived position, having chosen to
become a provided-source company for certain product lines under certain conditions.
Under its “Shared Source” program, first announced on May 3, 2001,47 Microsoft agreed to make
the source code for many of its Windows operating systems available to various communities.
As of July 2003, 14 different Shared Source license packages provide access to the source code
for up to 9 different Microsoft programs, including some of the most widely-used Microsoft
commercial software.48 All 14 of these license packages provide the licensee with the right to
access the source code, with most providing the right to debug, and some providing the right to
modify the source code for personal use, distribute the modified source code, and even
commercialize that modified code.49 One of these licenses, the Government Security program, is
targeted directly at governments and their need to “evaluate the security” of Microsoft software.50
At first glance, a license providing the right to access source code, modify it, and commercialize
those modifications would meet if not exceed the minimalist definition of “open source”, namely
For example, the BSD license does not require that downstream works be open source, simply that a person
who produces a downstream work must provide all the code to the downstream user that they received from the
upstream source. See BSD license (www.opensource.org/licenses/bsd-license.php); the BSD license has been
certified by the OSI as being compliant with the OSI’s 10 Principles.
Explored in more detail in section 4.1 of this paper.
Georg C. F. Greve, Free Software in Europe: European perspectives and work of the Free Software Foundation
See e.g. Clay Shirky, A Group Is Its Own Worst Enemy (2003) (shirky.com/writings/group_enemy.html).
Mundie, supra note 37.
These licenses provide access to all versions, beta releases and service packs for Microsoft Windows 2000,
Windows XP, Windows Server™ 2003, Windows CE, Windows CE.NET, C#/JScript/CLI Implementations,
ASP.NET Samples, .NET Passport Manager, and Visual Studio .NET Academic Tools. See Microsoft,
Microsoft Shared Source Initiative Overview
More information about the various rights provided by the various Shared Source licenses is available at
Microsoft, Shared Source Licensing Programs
(www.microsoft.com/resources/sharedsource/Licensing/default.mspx), with a table distinguishing their essential
elements at Microsoft, supra note 48.
Microsoft, supra note 49
- 12 -
that the source code be open to review by users of the software. But neither Microsoft51 nor the
open-source movement52 sees Shared Source as in any way equivalent to open source.
Putting aside complaints that basically amount to a claim that Shared Source is unfair to
developers because Microsoft receives a benefit from it as well as the argument that Shared
Source is just as “viral” as the GPL,53 there are two comments about Shared Source that are
relevant to use of Shared Source at the government level.54
The first comment derives from issues that Microsoft itself makes clear in the terms of Shared
Source licenses: they are limited by country. Shared Source licenses are not offered at all to
“Cuba, Iran, Iraq, Libya, North Korea, Sudan, and Syria, which are subject to US trade
embargoes”.55 Even this minimal restriction runs contrary to the OSI’s 10 Principles, which
require that open source software be made available to any person in any country.56 But beyond
this minimal restriction, certain of the Shared Source licenses are only made available in a
specific “white list” of countries.57 As of July 2003, residents of India wishing to join the OEM
Source Licensing Program would be told that they could not; this Shared Source license was not
made available to them. This may reflect a business decision by Microsoft, but it also reflects a
reality that for many countries, Shared Source is not presently and may never be an option for
The list of those governments to which Microsoft’s Government Security Program is made
available is not even published but must be obtained by sending an email to Microsoft to request
See e.g. Mundie, supra note 37: “Shared Source is not Open Source.”
Wheeler, supra note 5.
See e.g. Open Source Institute, Shared Source: A Dangerous Virus
There is a third aspect of Shared Source that may make it a difficult option for some governments, namely the
requirement that the government in question be a significant customer of Microsoft products. For example, one
of the eligibility requirements for any customer’s admission to the Enterprise Source Licensing Program is that
the customer maintain 1,500 Windows seats (Windows 2000 or above) under either an Enterprise Agreement or
a Select Agreement with Upgrade Advantage or Software Assurance; this may be a significant outlay for some
government ministries or even for governments. Microsoft, Enterprise Source Licensing Program,
Microsoft, Shared Source Licensing Programs Availability by Country
Namely Principle 5. See section 2.2 of this paper. Note that all Americans are subject to these trade restrictions,
not just Microsoft; it is just that many Americans decline to abide by them or have assessed the risk of
discovery and prosecution as low. They are, however, raised in the SCO v. IBM lawsuit, where SCO notes that
the potential presence of portions of UNIX code in Linux would be an attempt to circumvent US export control
restrictions. See paragraph 116 of SCO’s Amended Complaint and section 4.1.2 of this paper.
For example, the Enterprise and Systems Integrator Source Licensing Programs, and the Windows CE Shared
Source Premium Derivatives and Windows CE Shared Source Premium Derivatives Distribution Licensing
Programs were as of July 2003 only available in Australia, Austria, Belgium, Brazil, Bulgaria, Canada, the
Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, the
Netherlands, New Zealand, Norway, Poland, Portugal, South Korea, Spain, Sweden, Switzerland, the United
Kingdom, and the United States. See Microsoft, supra note 55.
- 13 -
the information.58 Governments that have not been approved by Microsoft will not be provided
any Microsoft source code, and they will find another alternative. But even those governments
that are approved for the Government Security Program receive only “the information and source
code access needed to evaluate the security of the Microsoft Windows platform”,59 which would
imply that the source code access provided is less than other licenses.60
The second issue arising from Shared Source licensing goes to the contention that modified code
cannot be released without a license from Microsoft. The idea that licenses are required from a
company to use and modify its products is not surprising in a commercial context, as it is how
restricted-source software remains restricted source. Nonetheless and while some Shared Source
licenses do provide for modification and non-commercial distribution and others allow for
commercial distribution of modified source code, the idea that permission from an American
company is required for a government to distribute programs that the government has itself
developed may be unpalatable in some countries. Governments that do not appreciate a
requirement to seek permission from any company, let alone an American one, may find open
source to be an attractive alternative.61
3. Overview of open-source software use by governments
Having reviewed in some detail the nature of open-source software licensing and provided some
meaningful distinction between “open source” and its alternatives, it is now time to consider the
issues arising from the use of open source by governments outside of the United States.62
Many of these issues have been previously flagged by other commentators as either being
impediments to the adoption of open-source software by governments or reasons that open-
source software should be adopted by governments (sometimes the same criterion is even
invoked as both an impediment and an incentive). What this paper will demonstrate is that many
of the legal issues that arise in the use of open-source software by governments are similar to
those confronted by governments outside the open-source context; in fact, these are issues that
arise with governments as soon as they confront the decision to start using any form of
information technology. Deciding between open-source, provided-source, or restricted-source is,
in many instances, a red herring. However, some issues, including some that are specific to open
source, can have significant impacts on legislation and government decision-making.
Id. Microsoft claims that the program is available to “more than 60 countries with intellectual property regimes
that meet international standards”; see Microsoft, Government Security Program
(www.microsoft.com/resources/sharedsource/Licensing/GSP.mspx). As of February 2003, Russia, China, the
UK, and NATO were known to be approved; see Inquirer Staff, Microsoft opens Windows source in China,
THE INQUIRER, February 28, 2003 (www.theinquirer.net/?article=8047).
Microsoft, supra note 49.
Interestingly, the Government Security Program appears to be the only Shared Source license that only allows
viewing the source code without providing rights to debug the code. Microsoft, supra note 48.
See section 4.1 of this paper for more on this issue.
This paper does not review purely private sector use of open-source software, although government regulation
of certain industries and permission to use open-source software in those sectors can be considered as
government action and will be discussed as appropriate. For such a discussion, see RAJANI, supra note 18. Note:
the present paper is based upon research as of July 2002; open source is a very fast-moving area of both law and
business and no representation is made for currency of research (or even links) after that date.
- 14 -
At the organizational level, conferences promoting the use of open-source software by
governments and the private sector in developing countries have been held in recent years in
Malaysia (to promote open source use in Afghanistan),63 Trinidad and Tobago,64 the Dominican
Republic,65 the Middle East (Bahrain, Kuwait, and Oman),66 and Vietnam.67
Some governments have gone a step further than just conferences. MIMOS Berhad, an advisor to
the Malaysian government, has launched the Asian Open Source Centre, or AsiaOSC, a
centralized registry of information about open source activities in Asia. Their website provides
an excellent resource to identify groups and projects ongoing in the region, country by country. 68
In addition, non-governmental organizations (“NGOs”) in many countries have partnered with
universities to investigate and promote open source, including in Argentina,69 Australia,70
Bolivia,71 and Uganda.72 On a regional scale, some NGOs unite efforts in many countries or even
continent-wide, including the Free and Open Source Foundation for Africa (FOSSFA),73 the
Open Source Foundation for Africa.74 And of course there are Linux and open source users’
groups in nearly every country.
Africa’s use of open source software, or any software at all, is typically concentrated in the larger
metropolitan areas, and use and adoption of open source solutions is in many ways contingent
upon development of a reasonable communications and information technology infrastructure.
However, there are several projects ongoing in various countries.75 Bridges.org, a non-profit
Asia Open Source Centre, Afghanistan (www.asiaosc.org/enwiki/page/afghanistan.html).
Taran Rampersad, The Trinidad and Tobago Linux Users Group and the FLOS Caribbean Conference, LINUX
JOURNAL, June 26, 2003 (www.linuxjournal.com).
CESAR BROD, FREE SOFTWARE IN LATIN AMERICA (2003) (www.maailma.kaapeli.fi/lamaerica.html).
Anne-Birte Stensgaard, Linux unstoppable in Middle East says IBM, AMEINFO, June 22, 2003 (2003, June 22)
Asia Open Source Centre, Vietnam (www.asiaosc.org/enwiki/page/Vietnam.html).
Asia Open Source Centre, ProjectInfo: About AsiaOSC (www.asiaosc.org/article_7.html).
BROD, supra note 65.
Asia Open Source Centre, Australia (www.asiaosc.org/enwiki/page/australia.html).
BROD, supra note 65.
Victor van Reijswoud, Open Source Software – the Alternative for Africa (n.d.) 5 (www.opensource.org).
FOSSFA, Renaissance for Liberating Africa (June 2003) (fossfa.org).
Id. See also van Reijswoud, supra note 72 at 5, who traces the origin of OSFA to a workshop in Addis Ababa,
NICO COETZEE, FREE AND OPEN SOURCE SOFTWARE IN AFRICA (2002). (www.maailma.kaapeli.fi/africa.html).
- 15 -
organization based in Cape Town, South Africa, began a study in 2002 comparing the use of
open-source and restricted-source software in Africa that should be complete by late 2004.76
The most significant government adoption of open source in Africa has been by South Africa,
and secondarily Nigeria.77 In May 2003, the South African cabinet of ministers approved the
Government Open Source Software strategy, adopted with an eye to cost savings, which
recommends that the government implement open source software in cases where it is an
appropriate option and proposes that open source policies be integrated more widely with e-
government policy, IT strategies, and the communications sector.78 In addition, the South African
Government Information Technology Officers Council has set a policy to prefer open source
applications when proprietary alternative do not offer a compelling advantage.79
3.2 The Americas
For a time and perhaps in response to reports that it would owe about $30 million USD to
acquire licenses for all of its illegally-obtained restricted-source software,80 Peru was considering
a law that would have made it one of the vanguard states in adopting open source. Under this
law, government agencies would have been required (not “encouraged” or “recommended”) to
use open source software. While this bill was eventually not passed, 81 it does represent one of the
strongest legislative positions in favor of open source that has ever been proposed.
The GNOME project, originally conceived in Mexico, provides a user-friendly desktop and set
of tools in developing GUI applications, both for the GNU/Linux operating system. A project
entitled Red Escolar Libre did not fare as well, designed to provide low cost support to Mexican
schools; today the project is essentially dead due to unforeseen implementation and support
Brazil presently has a number of open source software projects and initiatives ongoing, and, after
Mexico, is the most active country in Latin America, though almost none has been exported
(perhaps because Brazil is the only Portuguese-speaking country in the area). However, the most
significant open source development in Brazil and possibly in all of the Americas would be the
decision in June 2003 by the Brazilian government that it would migrate 80% of all computers
Philipp Schmidt and Shafika Isaacs, Comparison of Open Source and Proprietary Software in Africa 2002
John Yarney, South Africa, Nigeria move on Linux adoption INFOWORLD, July 8, 2003
Id. For commentary on this strategy, see the Center of Open Source and Government, The Center of Open
Source & Government Endorses South African Open Source Strategy and Provides Policy Guidelines
(www.egovos.org/southafricanstrategy.html). For a report from the government perspective, see National
Advisory Council on Innovation, Open Software & Open Standards in South Africa: A Critical Issue for
addressing the Digital Divide 2002 (www.naci.org.za/docs/opensource.html).
Paul Festa, South Africa considers open source, CNET, February 5, 2003 (news.com.com/2100-1001-
Craig Mauro, Opening doors for open-source, SILICONVALLEY.COM, June 25, 2002 (www.siliconvalley.com).
See section 4.1 of this paper for more discussion of this proposed bill.
BROD, supra note 65.
- 16 -
used in state institutions and state-owned businesses from Microsoft to the Linux operating
system.83 This plus Brazil’s legislation requiring the use of open source in municipal
governments would make Brazil one of the most aggressive proponents of open source.84
Perhaps not surprisingly given its status as subject to US export control laws, Cuba has also been
active in adopting open source. For example, Cuba uses Linux as the operating system for
INFOMED, a telemedicine network of the Ministry of Public Health, developed in 1992 and was
the world’s first to offer nationwide coverage and use the Linux operating system. 85
Although one of the most significant software-developing countries in the world, Canada has not
adopted open source at the government level in any significant or even noteworthy way. 86
Some commentators have predicted that 2003 is likely to see a significant increase in open
source software projects and usage throughout Asia.87 At the operating system88 and software
development levels,89 some Asian countries have taken steps toward implementations of open-
source software that go beyond trial runs. In addition, some countries, most significantly China
and Japan, have made significant private sector investments in open source,90 possibly in order to
develop an industry that could use the size of the Asian market to wrest overall control of the
software sector from Microsoft and other American companies.91
Gonzalo Porcel, The Brazilian Public Sector to Choose Free Software, PCLINUXONLINE, June 7, n.y.
Stefano Comino and Fabio M. Manenti, Open Source vs Closed Source Software: Public Policies in the
Software Market (2003) at 6 (econwpa.wustl.edu/eps/io/papers/0306/0306001.pdf).
BROD, supra note 65.
See e.g. Dee-Ann LeBlanc, Linux in Canada: Are We Going Open Source Yet?, LINUXPLANET, n.d.
Robin Miller, 2003: the year of Asian Linux THE REGISTER, December 27, 2002
For example, South Korea’s HancomLinux signed a contract with Korea’s Central Procurement Office to
supply the government with 120,000 copies of its Linux desktop office productivity software. FREDERICK
NORONHA, LIBERATION TECHNOLOGY FOR THE LANDS OF DIVERSITY? FREE SOFTWARE IN ASIA (2003).
Japan has taken some steps to implement open source in its government, such as a Linux-based payroll system.
Reuters, Japan Govt Opts for Linux for Payroll System, YAHOO! NEWS, July 8, 2003 (news.yahoo.com)
Michael Singer, Transmeta Bolsters Overseas Connections, INTERNETNEWS.COM, June 13, 2003
(www.internetnews.com/infra/print.php/2222101); RedFlag-Linux Staff, Oracle and Red Flag Software
Company have established a strategic cooperative relationship in China, May 7, 2003 (www.redflag-
linux.com/jujiao/enews_view.php?id=1000000016). See also NORONHA, supra note 88. While private sector
developments would be beyond the scope of this paper and ordinarily would not draw comment here, they are
noteworthy in this context so as not to understate the commitment of the Japanese and other Asian economies
(which can often be proxies for their governments) to open source.
Rob Enderle, Japan Strikes Against Microsoft with Open Source TECHNEWSWORLD, September 8 ,2003
- 17 -
Perhaps surprisingly, Malaysia claims to be ahead of all other Asian countries aside from Japan
in the number of GNU/Linux server shipments, having committed itself to open source in
November 2002.92 The People’s Republic of China has taken many significant steps toward a
home-grown software industry based upon open-source software, the most recent of which
would be the recent announcement of the State Council of the People’s Republic of China that, at
the time of the next systems upgrade for all government ministries, the government will purchase
only hardware preinstalled with domestic operating systems and applications.93 In addition, there
have been significant steps made toward development of Chinese open-source-based software,
including public-private partnerships with American- and other foreign-owned companies.94
The governments of the Republic of China (Taiwan),95 India,96 and Pakistan97 have all started
programs to promote and even subsidize the use of open source in government systems, and as
noted the government of South Korea has bought 120,000 copies of Hancom Linux; this would
be sufficient to convert 23% of its installed base of Microsoft Windows users.98 In Singapore,
companies using Linux receive tax breaks.99
However, not all Asian countries have adopted open source solutions, and even some countries
without many other options have not looked to open source as a way to implement information
technology. Both Chinas (the People’s Republic100 and Taiwan101) are also part of Microsoft’s
Government Security Program. The government of Iran has not shown any signs of wanting to
implement open source software; since Iran is subject to export control laws, open source would
provide one way for the country to build a software developer infrastructure, but it has
apparently declined to follow this lead.102
Charles Moreira, Malaysia backs open source CNET, December 8, 2002
(asia.cnet.com/newstech/systems/0,39001153,39071821,00.htm). See also NORONHA, supra note 88.
CNETAsia Staff Writers and Zhang Xiaonan, China blocks foreign software, CNET, August 18, 2003
(news.com.com/2100-1012_3-5064978.html). See also NORONHA, supra note 88.
Michael Singer, Transmeta Bolsters Overseas Connections, INTERNETNEWS.COM, June 13, 2003
(www.internetnews.com/infra/print.php/2222101); RedFlag-Linux Staff, Oracle and Red Flag Software
Company have established a strategic cooperative relationship in China, May 7, 2003 (www.redflag-
Tiffany Kary, Taiwan opens arms to open source, CNET, June 4, 2002 (news.com.com/2100-1001-
931765.html). See also NORONHA, supra note 88.
David Becker, India Leader Advocates Open Source, CNET, May 29, 2003 (news.com.com/2100-1016_3-
NORONHA, supra note 88.
Wheeler, supra note 5.
Comino and Manenti, supra note 84.
Inquirer Staff, supra note 58.
Winston Chai, Taiwan: Open-source pressure won MS price cut, CNET, March 3, 2003
NORONHA, supra note 88.
- 18 -
3.4 Australia and New Zealand
Australia is relatively active in the use and adoption of open source software and the government
is actively creating legislation to promote open source usage. On September 17, 2003, the
opposition Democratic party served notice of an intention to introduce a private member’s bill
dealing with “open standards” and requiring that the government “consider the procurement” of
open source and avoid the purchase of a proprietary system.103
The Government of Australia made it clear in 2002 that it supported the trial and implementation
of open-source software as long as it met the “fit-for-purpose and value-for-money” criteria.104 A
bill on the use of Open Source Software was put before the house in 2003 that outlined the
benefits of open-source software and contrasted them with perceived disadvantages to restricted-
source software; the Initiative for Software Choice (ISC) urged the government to drop the bill
on the grounds that the bill would limit software choices for Australia’s government.105 Perhaps
in response to this, an open source bill has been proposed for the state of South Australia, New
South Wales, and the Australian Capital Territory.106
At the EU level, open-source software is an actively-considered option. In 2002, the European
Commission awarded €250,000 to a consulting firm to develop guidelines and define EU
strategy with the adoption and use of open source software for desktop computing. 107 The EU has
also undertaken several initiatives and studies to evaluate and plan for the use of open-source
In almost every country in the EU, the use of open source software is on the government agenda,
but the most active country would have to be Germany. For example, in Germany, 12% of all
public sector desktops use open source software,109 and the Bundestag has mandated that all
public administration servers run Linux.110 Its federal Ministry of the Interior has produced a
Simon Hayes, Democrats move open source bill, AUSTRALIANIT, September 17, 2003
ZDNet Staff, Australian govt green-lights open source, ZDNET, November 11, 2002
Sam Varghese, South Australia urged to drop bill on Open Source software, THE AGE, June 16, 2003
Hayes, supra note 103. See also Simon Hayes, Open source laws likely for SA, AUSTRALIANIT, June 25, 2003
John Leydan, Brussels to spend €250k on Linux migration study, THE REGISTER, October 30, 2002
See e.g. International Institute of Infonomics (University of Maastricht) and Berlecon Research, Free/Libre and
Open Source Software: Survey and Study, June 2002 (floss.infonomics.nl/report/index.htm). See also RAJANI,
supra note 18.
Patrick Thibideau, EU embraces open source, COMPUTERWORLD, March 2003
Comino and Manenti, supra note 84 at 6.
- 19 -
publication entitled Standards and Architectures for e-Government Applications,111 which details
the standards that should be considered by German government ministries in implementing e-
government. Aimed at decision-makers in organization and information technology in German
administrations, SAGA provides heuristics to aid government in deciding what technological
standards to adopt. These heuristics are based upon 3 criteria: acceptable programs primarily use
a browser as their front end, they forego active content as much as possible so that users are not
required to reduce their security settings, and they do not store program parts or data on the
user’s computer in order to preserve privacy and security (e.g. they do not rely upon permanent
cookies).112 SAGA also provides a list of standards in certain areas of information technology.
The standards are either “mandatory” (when the standard is tried and tested and represents a
preferred solution, and there can be competing mandatory standards if they have clearly different
functionalities or core applications), “recommended” (when they are tried and tested but
consensus to adopt them has not been reached), or “under observation (when they are in line with
current trends but not yet mature or of unproven value).113
While SAGA is obviously not a full solution for open source,114 it is instructive to note that its
criteria when applied are source-neutral. For text documents, SAGA authorizes 4 file types as
“mandatory”: ASCII text (.txt), HTML, MIME, and PDF version 4, with XML “recommended”
and PDF version 5 “under observation”.115 PDF documents are created for use with Adobe
Acrobat Reader, a restricted-source technology,116 HTML documents can be created by any text
editor and read using restricted-source or open-source software, and ASCII text documents can
be created and read in any environment. Similarly, spreadsheets have 2 “mandatory” file types:
comma-separated value (.csv) and PDF version 4, with PDF version 5 “under observation”.117
Other European governments using open-source software in government and promoting its use
both inside government and outside include France,118 the Netherlands,119 and Italy; Italy and
France have also discussed legislation mandating open source.120 In public and parapublic
institutions, open source software is also readily available and used. In Denmark, Sun
Bundesministerium des Innern, SAGA (Standards and Architectures for e-Government Applications) (2003)
Id. at page 8.
Id. at page 17.
For example, SAGA is silent as to the operating system and basic office applications suite that should be used
on government computers.
Id. at page 32.
Although PDF file creation is available outside the Adobe Acrobat suite: OpenOffice 1.1 (on which portions of
this paper were written) has a feature allowing for the creation of PDF files.
Id. at page 33.
RAJANI, supra note 18.
IT Analysis, Linux in Europe, THE REGISTER, June 16, 2003 (www.theregister.co.uk/content/4/31207.html).
Camino and Manenti, supra note 84 at 6. See also Register staff, Linux in Europe, THE REGISTER, June 16, 2003
- 20 -
Microsystems has made a deal to provide StarOffice software to all school pupils and teachers.121
In addition, many European governments have committed funding to the development of open-
source software, with Germany again in the lead.122
Outside the EU, open source is just as actively-used: as befits the home of Linus Torvalds, the
creator of the Linux kernel, the Finnish State Administration is considering the replacement of
Windows with Linux on 147,000 computers.123
Again, not all countries in Europe have adopted open source, and some seem to have decided to
cast their lot with Microsoft and Shared Source. For example, Russia has very little open source
activity underway, and it is a member of Microsoft’s Government Security Program. 124 And in
the UK each agency chooses its own software, although the Cabinet Office has provided a policy
allowing use of open source.125
4. Implications of open source for governments
So far, this paper has addressed the use of open-source software as though there was a clear
dichotomy: buy restricted-source software or acquire open-source software. In fact, there is a de
facto “third way” – don’t buy restricted-source software, just copy and use it illegally. In 2000,
97% of all software used in Vietnam was used in violation of copyright and patent laws; this was
the highest percentage in the world, followed by 94% for the People’s Republic of China.126
While this approach may have worked in the past, as more and more governments bring their
countries into the international economy where intellectual property rights are protected
stringently, pirated software will become less and less acceptable both for private firms and
especially for governments.
As has been noted above, open source is not just a means of providing software but an entire
constellation of ideas. Some of these ideas may not mesh well with some ideologies, but the
ideological differences between governments do not seem to have impacted upon a government’s
decision to adopt or reject open-source software; that is, open source use does not seem to be
correlated to any type of government.
The rest of this paper will analyze the interplay between legislation and legislative decision-
making and open-source software use, and demonstrate that a commitment by a government to
RAJANI, supra note 18.
Stephen Shankland, Germany-Funded Linux software arriving, CNET, January 30, 2003 (news.com/2100-
RAJANI, supra note 18.
Associated Press, Microsoft Shares Code with Russia, WIRED NEWS, January 20, 2003
Office of the e-Envoy, Open Source Software – Use Within UK Government: Version 1 2002 (www.e-
RAJANI, supra note 18.For this reason, any figure stating the penetration of Microsoft Windows into a country
should be suspect, unless it is clearly noted as stating only the penetration of licensed, purchased copies;
similarly, figures indicating Linux installations will often not account for multiple installations, which are of
course legal. Wheeler, supra note 5.
- 21 -
the use of open-source software entails various other financial and ideological commitments for
which many governments may not be prepared.
4.1 Licensing and its limits: the hidden hand of US law
In order to understand the implications of open source outside the United States, it is important
to set forth the manner in which US law and legal concepts inform open source. Many aspects of
open-source licenses such as the GPL are predicated on US law or US legal concepts, and
outside such concepts the GPL and other open-source licenses may not be easily understood.
Moreover, and although open-source software is intended to be designed by programmers acting
in concert throughout the world and sent to users around the world, these programmers and users
are physically located in a particular area in the world, and it may be the case that these
programmers are being asked to waive rights that are unwaivable in their local jurisdiction.
Finally, many open-source licenses include waivers of liability and other conditions that are
inapplicable in certain jurisdictions. Some commentators have noted these waivers as
inapplicable in their local jurisdiction and that open-source licenses may therefore be
unenforceable. This may be true, although there would not appear to have been any instances
outside where courts outside the USA have been called upon to interpret these licenses. It may
also be true that a closer analysis of the arguments that the GPL and other open-source licenses
may be unenforceable demonstrate differences between US law and other laws dealing with
adhesion contracts. In fact, the argument over whether the GPL is enforceable outside the USA is
just one instance of a broader argument over the enforceability of adhesion contracts in general
under non-American legal systems.
4.1.1 Enforceability of licenses based in US law outside the USA
A general discussion of the differences between US law and non-US law is well beyond the
scope of this paper. However, it is impossible to understand the interpretation given to licenses
such as the GPL without an understanding of the civil law notion of “public order” and the civil
law treatment of consumers as protected parties. There are two types of public order in the civil
law, one that can be waived by the protected party (called “directive public order”) and one that
cannot be waived (called “protective public order”). Unlike in the United States, where many
states allow for the waiver of some or all consumer protections (e.g. the warranties that
traditionally accompany a contract for sale of goods under UCC-2), civil law jurisdictions treat
consumer protection issues as notions of protective public order and take the position that any
waiver of the application of consumer protection legislation is null.127 In addition, many civil law
jurisdictions contain requirements that all adhesion contracts must be drafted in the local
language or else it is null.128 The effect of such nullity is that the contractual stipulations that
would purport to bind the consumer are deemed to be unwritten.
The impact of this different perspective in the context of open source is significant. As noted
above, the GPL contains many conditions governing the use of GPL-licensed software, one of
For example, the Canadian province of Quebec, a civil law jurisdiction, contains the following statement at
article 3117 Civil Code of Quebec: “The choice by the parties of the law applicable to a consumer contract does
not result in depriving the consumer of the protection to which he is entitled under the mandatory provisions of
the law of the country where he has his residence...”
See e.g. Quebec’s Charter of the French Language, section 55, which holds that an adhesion contract that is not
drafted in French is null.
- 22 -
which is a disclaimer of all warranties.129 That is, the GPL contains a clear statement that a
person who decides to use GPL-licensed software does so at their own risk and no warranty or
other promise is made to the user that the software will work in any way.130 In many jurisdictions,
especially in civil code jurisdictions, such waivers violate local law and are invalid. For example,
it is arguable that under German and European Union law, a waiver of liability under the GPL
that would purport to exonerate a codewriter from any liability for harmful consequences arising
from use of the software or for defects in the software would be invalid.131 This would raise the
question of whether a programmer who releases code under the GPL could nonetheless be held
responsible in the EU or in Germany for any defect in the code. Certainly, from the text of the
GPL, no such responsibility is possible, but the laws of Germany and the EU would deem that
waiver as non-written and would not enforce it. While the end result of this question would
become one of private international law,132 it should suffice to say that a programmer outside of
the USA who relies upon the limitation of liability clauses in open-source licenses would be
well-advised to consult local counsel.
However, there is nothing special about the GPL or any open-source license in this regard. Many
restricted-source products are distributed under licenses that purport to have similar restrictions
on liability. For example, Adobe Acrobat Reader 6.0, the most recent version of this popular
document-viewing software, contains no less than 13 different license statements, some of which
are for open-source components of the software but others of which are for restricted-source
components, and all of which purport to exclude warranties. If the GPL and other open-source
licenses are invalid or fraught with problems because of their attempt to exclude liability, so too
are restricted-source licenses such as those for Adobe Acrobat Reader.
It would therefore seem to be a red herring to complain that open-source licenses are invalid
because they purport to limit liability. If the application of civil law systems to such limitations
of liability makes them invalid, then many licenses for many products other than open-source
software are equally invalid. Moreover, most users of software want a system that works, not
someone to sue if it does not,133 so the question of limitation of liability does not arise. If the
system ceases working and the vendor refuses to fix it, it is simply replaced, and that vendor may
have limited its liability but it has also lost an upgrade path (and the associated sales) for the
A deeper problem may be that the GPL and similar open-source licenses may be unenforceable
in many non-US jurisdictions. Some commentators on the GPL have expressed opinions that
arguments to the effect that the GPL may not be enforceable because there is no act of
GPL, supra note 12, sections 11 and 12. See also section 2.3 of this paper.
As in many contexts in this paper, the focus in this section on the GPL should not be understood as a particular
critique of the GPL, as other open-source licenses have similar provisions and the reference to the GPL is for
the sake of simplicity. See e.g. section 5 of the Apache Software License
GERALD SPINDLER, RECHTSFRAGEN DER OPEN SOURCE SOFTWARE 104-06 (2003).
The risk assessment of a judgment in Germany that would hold an American programmer of open-source
software responsible for defects in their code can only be made in light of a determination as to whether a local
US court would enforce that German judgment against the US-based programmer. Such a determination is
beyond the scope of this paper.
Wheeler, supra note 5, section 9.2.
- 23 -
acceptance of the license are nothing more than a misunderstanding or an attempt by restricted-
source providers to create fear, uncertainty, and doubt in the minds of users to discourage use of
open-source software in favor of restricted-source alternatives.134 To these commentators, since
the GPL does not require a user to accept a license at all unless that user decides to redistribute
the software or any part of it, and “because no one can ever redistribute without a license, we can
safely presume that anyone redistributing GPL’d software intended to accept the GPL.”135
In response, other commentators have noted that the GPL would not be binding upon someone
who does not understand it or by operation of law. It is a basic principle of all legal systems,
including in the US, that a person is not required to respect a document that they did not
understand. It would therefore be difficult to say that a programmer who cannot read English
would be bound by a license written in that language. The GPL and many other open source
licenses exist only in English. There are no translations of the OSI’s 10 Principles, as the OSI
found these principles “too difficult to translate accurately”.136 Moreover, they are contracts of
adhesion, being terms that are stipulated by one party and not subject to negotiation. As noted
above, many countries hold that contracts of adhesion must be written in the local language, and
that even if the person reading the contract can understand the foreign language fluently the
contract is not binding without an express consent to allowing the contract to be drafted in that
other language. The GPL notes in its Preamble, and rightly, that no one is forced to use GPL-
licensed software and that a user who does not like the terms of the license can simply refuse to
use the software and thereby avoid being bound. Many legal regimes would give a person
another option: the person may use the software as they choose without restriction, and since the
GPL is an adhesion contract and it was not presented to in the local language (e.g. German, for
Germany) the user is not bound by it.137
While a similar problem would exist for restricted-source licenses drafted in English, such
provisions would be less controversial in a restricted-source setting because there is no real
possibility of downstream programmers’ using restricted source code: they have no access to it.
In contrast, where source code is provided subject to a series of terms and conditions, and those
terms and conditions are unenforceable, the question arises as to what use the downstream
programmer may make of the source code; it may even fall into the public domain. As such, and
putting aside the state immunity issue,138 governments that use open source may be in a position
to do so with significantly more freedom than the US government.
4.1.2 The SCO litigation and its impact on open source in government
Finally, the use of open source outside the United States will never be completely divorced from
American realities. So long as there is law, there will be litigation, and that litigation can have
significant impacts on the use of open source outside the USA.
See e.g. RAJANI, supra note 18.
See OSI, supra note 3.
SPINDLER, supra note 131.
About which see section 4.4 of this paper.
- 24 -
One of the attendant costs of using licensed software is verifying that all licenses are properly
licensed. With open source, this verification is often quite simple: users of most open source
software are able to do whatever they want with it at no charge, and even GPL-licensed software
users are only limited in their redistribution and not in their use of the software. With restricted-
source, it is often necessary to be able to trace each installation on each computer to a specific
purchase of a license; failure to be able to do so is a failure to be able to produce critical evidence
in the event of litigation from the restricted-source company. And American litigation is
expensive, probably the most expensive in the world. These audits, and the penalties for being
non-compliant, regularly run organizations and governments into hundreds of thousands of
dollars, to say nothing of the cost of lost employee time.139 The ability to avoid such audits is a
competitive advantage to Linux and other open-source software – where distribution is free of
charge, audits are mostly irrelevant – but recent litigation in the United States has raised the
specter of Linux audits.140
In June 2003, The SCO Group, Inc., a successor in interest to certain portions of Caldera,
launched a suit against IBM that goes to the heart of open source and its future development. In a
nutshell,141 through a series of acquisitions SCO claims to have acquired all right, title, and
interest in and to the UNIX, SCO OpenServer, and UnixWare source code; it licensed this source
code to IBM and, according to SCO’s claims, IBM has caused UNIX and UnixWare code to be
incorporated into Linux.142 According to SCO, IBM’s motivation for this conversion is its
attempt to gain dominance over other technology companies: IBM was in the process of
converting its business from a seller of licenses to a seller of consulting services, and it would be
uniquely able to gain first mover advantage in a Linux-dominated environment, allowing it to
“undermine and destroy the ability of any of its competitors to charge a fee for distribution of
UNIX software in the enterprise market.”143
SCO alleges six causes of action in its complaint: (Causes 1-3) breach of contract, (Cause 4)
unfair competition, (Cause 5) tortious interference with contractual relations, and (Cause 6)
misappropriation of trade secrets. The suit claims at least $4 billion USD in damages (including
exemplary damages),144 plus punitive damages and a permanent injunction. IBM replied with a
See Wheeler, supra note 5, section 8.2.
Audits are not inconceivable in the purely open-source context. Presumably, if the GPL carries with it a
requirement to distribute source code and to license derivative works in accordance with the GPL, there is a
notional exposure to an audit – by whom, though, is anyone’s guess.
A full analysis of the SCO v. IBM litigation is beyond the scope of this paper and is in any event premature
SCO’s amended complaint is available online at www.caldera.com/ibmlawsuit/amendedcomplaintjune16.html.
It is probably not surprising that IBM has denied all claims; SCO’s website also contains a PDF version of
IBM’s defence, which PDF is defective and cannot be downloaded or printed although it can be read onscreen.
SCO Amended Complaint, paragraph 88.
Most news reports have described the amount claimed as $3 billion USD; see e.g. Matt Hines and Stephen
Shankland, SCO pulls second IBM Unix license, CNET, August 13, 2003 (news.com.com/2100-1016_3-
5063143.html). Cause 1 seeks damages of no less than $1 billion plus additional damages through and after
trial. Causes 1 and 2 seek restitution of all benefits gained by IBM including the full amount of revenues earned
by IBM from sales of AIX. Cause 3 seeks damages of no less than $1 billion plus additional damages through
and after trial. Cause 4 seeks damages of no less than $1 billion plus additional damages through and after trial.
Cause 5 seeks undefined damages. Causes 4 and 5 seek punitive damages. Cause 6 seeks undefined damages,
- 25 -
counterclaim seeking unspecified monetary damages and injunctive relief.145 While Causes 1-3
have serious import for the development of open source in general,146 the actual causes of action
raised in this litigation will probably not have much impact on government. However, for
governments that wish to use open source as a means to develop a local technology industry,
SCO v. IBM holds an important lesson.147
At first, there was concern that the SCO claim against IBM would be followed by suits against
Linux users for misappropriation of intellectual property.148 SCO even went so far as to send
letters to 1,500 IT managers at large corporations warning them that any use of Linux could
expose them to litigation.149 When SCO subsequently announced that it would not sue Linux
users for unlawful use of an allegedly licensed product,150 users of open source were spared this
potential exposure, but the threat from SCO puts the possibility for licensing disputes between
companies claiming that their intellectual property has been wrongfully converted into open
source in clear relief.151 Moreover, SCO’s recent threat to send invoices to Linux users would
mean that the question of whether users must pay for Linux is not yet resolved.152 While a few
companies (including Microsoft) have paid SCO for Linux licenses,153 the question of who would
trebled because of intentional conduct. All this, plus costs and attorney’s fees and pre- and post-judgment
See Stephen Shankland, Big Blue files counterclaims against SCO, CNET, August 7, 2003
These Causes seek an injunction to force IBM to return all copies of all Linux source code that it has
distributed; since Linux is open source and allows for unlimited and unrestricted copying, it is in practice
impossible for IBM to comply with this requirement. The effect of this injunction, if granted, would in effect
allow SCO to obtain an order to go into the premises of any organization using Linux and conduct a source code
audit; where the code is found, SCO would then be able to extract penalties and charge a fee. The threat of these
audits made the SCO v. IBM litigation attract significant attention from the open-source community and from
users of open-source software: for many companies, their use of Linux had been at least in part predicated upon
freedom from such record-keeping, and the need to keep such records would remove one of Linux’ competitive
There is a second lesson that open-source companies appear to have learned very well, namely the need for pre-
emptive litigation. In both the USA and Germany, SCO has been targeted with lawsuits from Linux distributors
(Red Hat and SuSE respectively) seeking declaratory judgments that SCO does not have any exclusive right
over Linux. Face value: Of monkeys and penguins, THE ECONOMIST, August 30, 2003, at 30.
Whether or not these suits would have had any basis in law. See Eben Moglen, Questioning SCO: A Hard Look
at Nebulous Claims, July 24, 2003 (www.osdl.org/docs/osdl_eben_moglen_position_paper.pdf).
David Becker, SCO raps Red Hat, sets license prices, CNET, August 5, 2003 (news.com.com/2100-1001_3-
Sam Varghese No plans to sue Linux companies, says SCO, THE AGE, August 29, 2003
(www.theage.com.au/articles/2003/08/29/1062050642514.html). This would probably be a good decision on the
part of SCO if reports are true that SCO’s own Internet site runs on Linux, as the public relations issue would be
difficult to explain. See CNET Staff, Microsoft, SCO lean on Linux, CNET, September 2, 2003
And, of course, SCO’s decision not to sue Linux users did not spare IBM.
Stephen Shankland, SCO to send out Linux invoices, CNET (news.com.com/2100-1016_3-5070583.html).
Face value: Of monkeys and penguins, supra note 147.
- 26 -
pay an invoice from a company that has publicly declared it will not sue people without them
Nonetheless, even without the threat of litigation against Linux users, the outcome of SCO v.
IBM will have policy impacts upon governments that wish to promote open source. Imagine a
situation where a software producer in Germany takes a copy of OpenOffice (licensed under the
GPL), creates a German-language interface, and distributes it. In Germany, if the GPL does not
apply, the producer can restrict distribution of that customized version of OpenOffice. But
OpenOffice is distributed with the GPL text embedded throughout its code. A customer seeing
that license and thinking that it applies may react variously: it may decide that it too has the right
to redistribute the software without fee (although it does not) or that it has been duped into
paying for something that it could have obtained elsewhere for no charge (and then sue). Another
producer wishing to customize the first interface would be prohibited from doing so without
permission, or it would have to recreate the interface from scratch (as the first producer would
not have been required to distribute its own source code or even the original source code).
Although damages in litigation outside the USA tend to be radically smaller for similar litigation
(and punitive damages basically do not exist), in a country where the GPL does not apply the
potential for software developers to end up in disputes over ownership and distribution rights to
code are magnified, not diminished. A government that wishes to promote its local information
technology sector by promoting development of open source will have to remove the uncertainty
surrounding the GPL, or it will see SCO v. IBM repeated tenfold as companies fight about who
has authorship and therefore ownership over software that one of them had thought was open
The SCO v. IBM litigation does not seem to have affected purchasing and use decisions in the
United States: a survey conducted after the institution of proceedings by SCO found that only
12% of around 400 software developers surveyed felt this litigation would affect customers’
decisions to adopt Linux.154 This makes sense. As long as end users consider themselves immune
to the prospect of their own business being caught up in the web of litigation, they are unlikely to
allow someone else’s lawsuit to affect their business.155 But if licenses such as the GPL are not
binding in areas like the EU, companies and governments outside the United States will find
their exposure to litigation to be more than academic. To create an environment where the status
of open source is known and certain, governments will have to create legislative regimes that
decide these questions once and for all. If not, they leave the decisions up to American courts
and litigants, whose priorities may be (will probably be) different.
4.2 Creating and supporting local developers (by legislation or otherwise)
Governments are not simply consumers of information technology. There is a social policy
impact in everything they do and every decision they make. In the United States, government
often plays an indirect role in shaping the economy (e.g. by favoring or disfavoring certain
businesses or industries with tax credits). Outside the USA, where laws are more favorable and
where government is not viewed with equal suspicion, governments will often provide direct
Matt Hines, Study: Linux use undeterred by SCO suit, CNET, August 4, 2003 (news.com.com/2100-7252_3-
It may be, however, that SCO will not stop with only one lawsuit. Recent press reports suggest that SCO may
be looking for other companies that it can target. See Stephen Shankland, SCO’s next target: SGI?, CNET,
September 5, 2003 (zdnet.com.com/2102-1104_2-5072061.html?tag=printthis).
- 27 -
subsidies to industries. This gives governments outside the USA the ability to create an industry
where none existed previously: if no one wants to program open source code because it doesn’t
pay, the government can make it pay by paying the programmers itself. And rather than
transferring its wealth to a foreign (often an American) corporation, a government that decides to
pay its own citizens to write code will keep its money in the country and often fulfill other social
goals at the same time. Even putting aside concerns about “spyholes” and other back doors that a
government might fear that a foreign power has caused to be placed in software,156 this social
welfare aspect to starting a domestic software industry has an undeniable attraction for many
It would be difficult to challenge the assertion that using open-source software will allow
governments in the developing world to achieve radical cost savings as compared to its procuring
restricted-source alternatives. This paper has previously noted the prevalence of pirated copies of
Microsoft software in Vietnam; one commentator’s query as to how many Americans would buy
legal copies of Windows XP and MS Office if they cost $38,436 (the equivalent to the average
American’s pre-tax income for 15 months) is well put.158 Certainly, a government transferring
such a proportion of its wealth into the hands of a foreign corporation would be ill-situated to
claim subsequently that there might be no money for hospitals or schools. However, and as each
of restricted-source and open-source advocates have noted, the initial cost of software is not the
proper metric; rather, customers (including governments) should consider the total cost of
ownership of open source and compare that to restricted source in order to reach any decisions.159
In that light, the fact that open source allows for the use of older machines that might be unable
to run modern versions of restricted-source software would also be a cost savings of no small
influence upon government, especially government in the developing world.160
Some commentators have noted that restricted-source operating systems produced by Microsoft
produced more revenue in the first two business days of 2002 than the whole Linux market did in
the whole year.161 This is a bit of an apples-and-oranges comparison, insofar as sales of open-
source software do not produce significant revenues as the software itself will often not
command much in the way of price (especially if it is GPL-licensed and therefore must be
distributed at no price). Nonetheless, some governments will have issues with their subjects or
electorates if they are perceived as contributing to such revenues.
About which see section 4.3 of this paper.
See Wheeler, supra note 5, section 2.2, where he discusses the attraction of this home-grown industry sector for
the People’s Republic of China, Germany, Peru, the United Kingdom, and the Republic of China (Taiwan); see
also section 10 of that paper, which discusses a Spanish government program that was started as a way to
“break the stranglehold” that Microsoft Windows presently exercises over the desktop.
RAJANI, supra note 18. The comparison is based upon the following factors: the cost of Windows XP and MS
Office in Vietnam is between $560 and $800 USD, the 2002 GDP per capita for Vietnam was $440 USD per
year, and the 2002 GDP per capita for the United States was $30,200.
Wheeler, supra note 5, section 7.4
CNET Staff, Linux moves on to next battles, CNET, August 4, 2003 (news.com.com/2100-7252_3-
- 28 -
4.2.1 Legislating a solution: laws mandating open source
In response to concerns about the degree of wealth transfer described above and in order to force
the issue, some jurisdictions have seen legislative initiatives proposing legislation that would
require certain governments only to procure open-source software.162 It is impossible to deny that
government is a significant actor in the software market even without legislation: simply by
purchasing sufficient product to run a modern bureaucracy, governments are among the largest
consumers of information technology, and therefore the buying patterns of government will have
a significant impact upon the direction in which technology will develop. Proponents of such
bills have typically not focused upon the cost savings that open source would create (although
they also do not hide their opinion that such savings are desirable), but rather upon ideological
bases such as promoting access to information by citizens.163 No such bill has as yet been passed
into law. Nonetheless, restricted-source software producers have banded together against this
perceived threat, taking positions in favor of “neutral public procurement rules” and opposed to
any requirement for open source.164
A preliminary comment about such legislation is that it would tend to suggest not that open-
source software is better than restricted-source but that it is worse. The fact that open source
might be alleged by some people to result in superior software than restricted source should
suggest in a rational economic system that open source would be adopted even without a law. If
open source is technically superior, users should elect to acquire it without any legislative
Restricted-source producers have tended to regard laws mandating open source as a
government’s legislating against property rights in a discriminatory fashion,166 and while this is
certainly one way to look at them, a government that has committed significant public resources
to the incubation of a local open source developer base may have a legitimate interest in ensuring
the development of that base by requiring use of its products in government. Looked at in such a
light, these laws are no different from legislation requiring the use of local contractors or
contractors owned by local minority groups. Laws of these types are prevalent in the United
States, and while such laws may be unconstitutional in the US if wrongly-drafted or if based on
inappropriate criteria, that does not stop American federal and state legislatures from passing
them fairly frequently.
For example, Peru (see section 3.2 of this paper) and Australia (see section 3.4 of this paper).
See e.g. a letter from Peruvian congressman Dr. Edgar David Villanueva Nuñez to Microsoft Peru’s General
Manager, available at www.opensource.org/docs/peru_and_ms.php.
Business Software Alliance, Principles for Software Innovation
(global.bsa.org/usa/policyres/Principles_Software_Innovation.pdf). See also Microsoft, Government and Policy
Comino and Manenti, supra note 84 at 3. See also Evans, supra note 32 at 40.
See e.g. a letter from Peruvian congressman Dr. Edgar David Villanueva Nuñez to Microsoft Peru’s General
Manager ( www.opensource.org/docs/peru_and_ms.php), which addresses various iterations of the argument
that government should not discriminate against some types of company or in favor of some types of purchasing
- 29 -
The confusion that surrounds these laws often reflects another instance of the hidden hand of US
law, this time in the minds of restricted-source software companies.167 The US Constitution is
much more hostile to such priorities as affirmative action programs than the governing laws
outside of the United States,168 and their having developed in an American-influenced
atmosphere often leads restricted-source software companies to presume that a country’s
promoting its own local industry is “unfair” and that a “level playing field” is necessary and
desirable. This perspective is incorporated in treaties such as NAFTA, which forbids member
states from giving any advantage to domestic actors in many spheres unless that same advantage
is extended to the actors from other member states. It is beyond the scope of this paper to provide
a full analysis of all international trade treaties and their potential impact upon open source. For
these purposes, it will suffice to note that any legislation passed to require open source that
would constitute a disguised trade barrier would very likely violate such agreements as GATT
and NAFTA.169 However, where it does not constitute a disguised trade barrier and where it is
not prohibited by local constitutional or other requirements, such legislation would be a rational
and effective way to promote a local development base in the open source sphere.
Arguments that such legislation would not achieve its goal because open-source software is
designed by people all around the world miss their mark. In the American context, these kinds of
laws are only permissible when defensible because they promote local industry doing things that
could not be done economically outside the jurisdiction or for other constitutionally-valid
reasons; this is an artefact of the application of the Commerce Clause. Where there is no
Commerce Clause (namely in just about every other country in the world), state legislation to
promote local developers would not be prohibited, but that legislation also does not have to
prevent non-locals from participating in the project. Such arguments are in fact suggestions to
the governments drafting open-source promotion legislation to ensure that they do not include a
requirement that the software used in government be programmed locally; they do not constitute
fatal flaws to the project.
4.2.2 Resource allocation: if government will develop software, then what kind?
Especially where laws requiring open-source software are enacted, governments will have to be
alive to the questions of resource allocation that will result.170 The sales pitch for open source is
It is also informed by a related concept, which is free market economics and more specifically the idea that the
government should not be in the business of picking winners. See e.g. Evans, supra note 32 at 46, where this
underlying idea is fleshed out.
To use an example from a neighbor, the Canadian Charter of Rights and Freedoms (similar to the Bill of Rights
in the US, and of equal constitutional importance) states at s. 15(2) that activities that would otherwise be
qualified as discriminatory are not precluded if their purpose is to improve the lot in life of the targeted group.
This would probably include any requirement that research funded by the government could only be made
available to open-source projects. See Ariana Eunjung Cha, Europe’s Microsoft Alternative, WASHINGTON
POST, November 3, 2002 (www.washingtonpost.com/ac2/wp-dyn/A59197-2002Nov2?language=printer), where
Microsoft’s position in this regard is set forth.
One question of resource allocation that is tangential to the scope of this paper but must be noted is related to
the spending behavior of individuals in a bureaucracy, and the perceived need to spend the whole amount
budgeted for any given item lest the budget be cut in the next year. Sales forces for products as diverse as office
supplies and furniture, to say nothing of those in the IT field, have significant experience with this phenomenon.
It is not impossible that a bureaucrat with control over a $5 million budget would stay with a more expensive
solution not because it is better but because of a perceived loss of status if the unspent amounts in the budget are
cut in future years.
- 30 -
that, as opposed to restricted source, open source allows the customer to verify that the software
does what it claims to do without holes, bugs, or unintended consequences.171 The corollary to
that pitch is that there must be enough people with the necessary skill and desire actually to
verify the software.172 It would be surprising if there was a large developer base with the skill set
required to test and debug health records software in the Estonian or Basque languages and that
was willing to do this in an open-source environment rather than charging what would possibly
be a healthy premium for this scarce resource.173
A government that acquires restricted-source software would be able to avoid this problem of
scarcity of developers. It would acquire a pre-existing program with a known cost, or the
software provider would contract to convert the interface to the necessary language as part of the
deliverables. As David Wheeler noted in a discussion of open source in government on Slashdot,
it can be difficult to find programmers for a particular project in such a way as to ensure that the
project works,174 and at least with restricted-source companies the government can insist on the
project’s being revised until it is done right. A government that is required to acquire only open-
source software would not have these options, and would have to find another means to achieve
this goal. It would have to ensure the development of a local programming base, in order to
ensure that it will have access to sufficient service providers when needs arise, or it would have
to become a significant employer of programmers itself.
Promoting the local language is a priority for many governments175 and in any even most
governments would rather that their citizens be able to work in their own language. So it could
be that creating such a base of programmers with expertise in porting software to the local
language would further that legislative goal as well. Nonetheless, governments that choose to
promote local programming communities will still have to ensure that there is sufficient
economic or other incentive to encourage programmers to develop the needed skills.176
This same pitch could also be made for provided-source software, where customers are given the source code
and can analyze it to their hearts’ content.
Moreover, it only makes sense in the context of mass-market software. Where software is developed for a
particular customer, there will likely be user testing incorporated into the development contract that would
provide for this kind of verification.
Open-source advocates note this as a problem with the open-source model, but also note that there is a
likelihood that a person might just take over a specific project in open source and run with it. See Wheeler,
supra note 5, section 9.12. While this might be true for such things as spell checks for an open source word
processor, it would seem less likely for a driver’s license registry or other government-specific application.
David Wheeler, Governments already support FLOSS development (ask.slashdot.com) Posting #6650644.
For example, the governments of Quebec and Latvia have enacted legislation requiring the exclusive use of
French and Latvian respectively in government and all of its workings.
At the same time, such governments will have to be alive to the possibility of code “forking”. “Forking” occurs
when certain programmers create code that adds functionality or redirects the evolution of the software, but that
code is not universally adopted. Open-source software is susceptible to forking because there is no central
“standards and practices” or similar office that can prevent programmers from taking software in multiple
directions; it is difficult to conceive of a group of rogue programmers inside Adobe from creating an
unauthorized version of Photoshop or Acrobat. While it is beyond the scope of this paper to examine forking in
depth, it may be that programmers working in an isolated linguistic environment would be more susceptible to
creating code forks.
- 31 -
Some governments have taken some initial steps toward porting open source software into the
local language, a necessary first step for a software industry. For example, the Cambodian
government has reached an agreement with UNICODE to develop Khmer based programming
language and characters as a GNU/Linux implementation,177 and similar language localization
projects have been undertaken in Vietnam.178 But these are only initial steps. Governments that
wish to promote open source, and especially those that wish to do so through legislation, will
need to consider the allocation of government resources and funding of the software industry that
such a policy would require, and whether they consider this to be an appropriate use of public
4.2.3 GPL vs. BSD: How open should government be?
A government that chooses not to spend its money on supporting and promoting a local
developer base will have to consider whether open source allows for the creation of viable
private-sector business models, or else it risks being left without an IT solution in the event of
systems crashes. Microsoft has publicly stated that it considers open source business model to be
fatally flawed, because open source requires “software developers to give away for free the very
thing that they create that is of greatest value in the hope that somehow they’ll make money
selling something else.”180 Many members of the open-source movement would agree that doing
business in the open source space requires that companies “take a second look at the business
model and prices, rather [than] technologies.”181 While a discussion of business models is beyond
the scope of this paper, and although it would seem at first glance that there must be a business
model that allows people to make money selling something that is also available without cost, or
the existence of libraries would have been fatal to the publishing industry long ago,182 there is a
strong argument that subsidizing the adoption and development of open source is welfare-
reducing for the society that does the subsidizing.183 Certainly one government, that of Sweden,
NORONHA, supra note 88.
Asia Open Source Centre, Vietnam (www.asiaosc.org/enwiki/page/Vietnam.html).
One example of an open-source implementation that looked good on paper but went wrong in reality is
Mexico’s “Red Escolar Libre”, or “Free School Network”, project. This project, implemented in 2000, looked
to provide 1 server and 6 computers in a lab for each of the 120,000 schools in Mexico; to save money on
Microsoft licenses, the project was intended to use Linux and open-source software. However, there was no
budgetary allocation in the project either for support or for training; the computers and the software were simply
shipped to the schools for local installation by untrained personnel. The project is widely-perceived both by
open source proponents and detractors as a colossal failure. See BROD, supra note 65 and Nuñez, supra note
Mundie, supra note 37. See also Microsoft, The Commercial Software Model and Sustainable Innovation
(www.microsoft.com/resources/sharedsource/Initiative/speeches/mundie_model.mspx): “[T]he GPL is
optimized to build a strong software community at the expense of a strong commercial software business
model. That’s why Linus Torvalds said... that ‘Linux is never really going to be a rich sell.’”.
RAJANI, supra note 18.
Kaser, supra note 14.
Comino and Manenti, supra note 84 at 16.
- 32 -
has considered this issue and noted the success of the Linux ventures of HP and IBM in 2002 as
promising good things for private open-source software companies.184
One of the most divisive questions in the open-source community is whether software
development should take place under the BSD or the GPL.185 There are strong arguments in favor
of both. Surprisingly for a topic that has consumed much time and thought, there does not seem
to have been much thought about which of the BSD or the GPL would be more appropriate for
government-sponsored code.186 As noted in this paper,187 the GPL places significant restrictions
on downstream users of GPL-licensed code that other open source licenses such as the BSD do
not. In particular, the BSD does not require that code using the BSD be licensed under the BSD
as well; the BSD-licensed code is there for the taking, and the taker has no obligation in return. A
BSD-licensed program must be distributed with its source, but the distributor can exact a
substantial profit for the software. In contrast, the GPL requires that downstream users be given
full and unrestricted access to and use of programs and source code at no cost.
The decision by a government to sponsor development of software requires that government also
to choose under what license the software should be developed, and that choice is itself highly
politicized. A government that chooses to sponsor the use of BSD-style licenses has chosen to
allow private software companies to take government funding and profit from it. This will
promote the development of a software industry but may lead to a situation where the
government may seem to have tried to “pick winners.” In contrast, a government that sponsors
use of the GPL has chosen to promote the spread of knowledge and technology at the possible
cost of discouraging for-profit businesses.188 It is also an asymmetrical choice: a government that
chooses the BSD can always change to the GPL, but a government that has chosen the GPL will
have great difficulty ever choosing anything else. As for a government that does not choose
which license it will promote, that is also a choice. Leaving the choice of license to the recipients
of government funding will allow some recipients to promote values of sharing knowledge and
others to promote the accumulation of profit, and will take this policy decision out of the hands
Moreover, there is no a priori reason that a government could not develop its own open-source
license for products and projects that it funds. For example, a government could set terms that
require unrestricted distribution of code to other nationals of the country while permitting
restrictions on distribution outside the country. While such a regime might be impermissible or
inapplicable inside certain trade or other alliances,189 it is not impossible to effect in the world,
STATSKONTORET, FREE AND OPEN SOURCE SOFTWARE (2003) 20.
Evans, supra note 32 at 39.
In the United States and at least for works produced directly by the government, the question is moot, as works
produced by the US government are not eligible for copyright protection. 17 USC 105.
See section 2.3 of this paper.
Evans, supra note 32 at 47.
For example, this might violate Chapter 11 of NAFTA, which prohibits discrimination against non-citizens (at
least where such discrimination impinges on citizens of the other states party). That is, the government of
Canada cannot extend special treatment to Canadians in an industry unless that industry is exempted from
NAFTA (such as softwood lumber) or unless that same special treatment is extended to Americans and
- 33 -
and it might allow countries with a sufficient population base to support such local development
and to gain a competitive advantage in software development.
4.3 “Spyholes” and preventing outside access to government information
For some reason, some governments and entities have developed the idea that the US
government may have forced American restricted-source software companies to provide
spyholes into the software to allow the US government to access secret information belonging to
foreign powers. This concern has been described as one of the primary motivations for Chinese
support of Red Hat Linux - if the operating system is open source then the government can check
the code itself and verify that no spyholes exist.190 This has been cast in the media as a Microsoft-
vs.-Linux debate,191 and while addressing it in that context shows room for a substantive debate it
leaves a part of the story untold.
The term “spyhole” is used to refer to a hidden porthole left in something like software that
would allow the programmer or a third party to have secret access to the software and/or to
manipulate the data stored in the system without knowledge of the customer or primary user.
While spyholes have been known to exist in the commercial context for purely commercial
reasons,192 one of the better-known discussions of spyholes (and one that is more apposite for the
present discussion) has arisen in the context of encryption.193 When encryption technology first
fell into widespread use, the US government, which had previously been able to engage in
widespread monitoring of communication and whose largest problem would be sifting through
the information, was confronted with an entire class of communication that it could not feasibly
monitor. The first reaction of the government to this technology was to promote the use of the
Clipper chip, a chip that would allow encryption by users but leave a back door for the US
government to enter (presumably after having first received a court order, although that may not
have been a hard and fast requirement). After an aborted attempt to require use of the Clipper
chip by regulation, the government then tried to encourage adoption of the Clipper chip by
subsidizing its development to make it the cheapest encryption technology; this also failed in part
because manufacturers were loathe to adopt an encryption technology sponsored by the US
government, and the government then returned to a regulatory approach whereby encryption
code would be regulated directly and a back door would be required.
Lessig raises this in the context of the government’s regulating code directly to effect an indirect
regulation of behavior,194 but his mention that the Clipper chip’s unpopularity derived in part
from hostility toward adopting a system promoted by the US government shows that non-US
CNETAsia Staff Writers and Zhang Xiaonan, China blocks foreign software, CNET, August 18, 2003
Craig Smith, Fearing Control by Microsoft, China Backs the Linux System, NEW YORK TIMES, July 8, 2000
See the discussion of Borland’s back door into InterBase to allow control of databases by administrators as
recounted in Wheeler, supra note 5, section 6.12.
This version of the story is adapted from Lessig, supra note 23 at 48-49.
He also raises the interesting if almost purely American question of whether the right to freedom of speech is
limited to speech that is capable of being understood by listeners (i.e. unencrypted speech); a discussion of this
topic is beyond the scope of this paper, but it does seem to presuppose a culture where everyone speaks the
same language when speaking without encryption.
- 34 -
companies have always had a reluctance to promote options that would prefer the US
government to others. Such non-US entities now seem to fear that the US government might be
forcing spyholes onto the world. But how? A government that wanted to ensure the efficacy of a
spyhole would attack the one thing without which all software cannot work: the operating
system. And a government that wanted to put a spyhole into an operating system would have to
do so in an environment where the spyhole would not be easily found: with restricted-source
software. Serendipitously, the largest restricted-source operating system producer, Microsoft, is
based in the United States. Is it possible, some have asked, that Windows contains a spyhole for
the US government?195
At the outset, it should be noted that the answer would have to be negative. It surpasses belief
that such a spyhole would have actually been put into any version of Microsoft Windows. If it
were required by law or regulation, those laws and regulations would be public and would have
been immediately disseminated across the Internet; in an environment where there are hundreds
of sites “proving” the US government’s suppression of UFOs in New Mexico, the absence of
Internet sites discussing such regulation is almost proof positive that it does not exist. Anyone
who would suggest that such an order or agreement may have been procured by less formal
means must then address why Microsoft was subjected to antitrust proceedings, if Microsoft
were so allied with the US government and so willing to accede to its demands. One would think
that Microsoft would have extracted a quid pro quo: we will put a spyhole into Windows, and
you will drop the prosecution. The presence of the prosecution therefore argues strongly in favor
of the absence of a spyhole. But the absence of evidence is never the evidence of absence, and
where a spyhole in Microsoft Windows cannot be proven not to exist, there will always be some
people and governments that will suspect its existence.196 That is, the question properly phrased
is not “is there a spyhole?” but rather “is it impossible that there could be a spyhole?”
It is unclear whether Microsoft’s Shared Source initiative could completely address this concern
held by countries such as China. Certainly, the Government Security Program allows the
governments of certain countries to access the source code for Windows to the extent that they
can verify its security.197 However, it is one thing to be able to test the security of an operating
system and another thing entirely to be able to verify code line-by-line. Moreover, the
Government Security Program is subject to such requirements as US export controls; a
government that is already concerned about the US government’s requiring spyholes to peer into
its systems may not be on the US government’s whitelist, or may be less than assuaged by
having been whitelisted.
The Chinese attitude in this regard is particularly instructive in light of the fact that China has
been approved for the Government Security Program.198 Any speculation as to why China would
seek access to Windows source code only to throw its support behind Linux would be exactly
Or for others. See the discussion of unsubstantiated claims that al-Qaeda was able to infiltrate Microsoft and
plant Trojan horses and back doors into Windows XP in Wheeler, supra note 5, section 6.12.
In a similar vein, search “Roswell”, “government”, and “UFO” on any Internet search engine for proof positive
that the absence of evidence of UFOs and government suppression thereof has not stopped a thriving industry in
See Microsoft, supra note 58.
Inquirer, supra note 58.
- 35 -
that: speculation.199 But one thing is certain: while the Government Security Program and other
provided source initiatives may be targeted to address certain concerns, there are other concerns
that cannot and may never be addressed by limited access to source code.200
Moreover, while there is probably no spyhole today, that does not in any way make a spyhole
impossible in the future. The more that code writing is concentrated in the hands of a few entities
susceptible to government regulation, and especially the same government or several of like
mind, the less likely those entities are to fight the regulation: their analysis will be one of cost
and benefit (are the sales they would expect to lose by accepting this regulation going to be
outweighed by the benefits gained) and not of ideology.201 Encryption technology is again
instructive. Individuals with sufficient interest will always be able to find encryption technology
for their personal use, but large corporations that program (and buy) software will tend to
discourage such individual action and will trend toward the solution that causes the least ripples.
Just as some governments have proposed legislation requiring the purchase of open source,202
other governments might legislate that they will only buy software with a spyhole. If the US
federal and state governments all adopted such legislation, the incentive for operating system
programmers to include such spyholes might become impossible to resist; if a restricted-source
software company were to refuse to comply with such legislation, this step might be sufficient on
its own to create a second viable restricted-source operating system company. Such a new
company may well be able to create sufficient economies of scale that it could then get its
products onto the average home user’s desktop, and if the price is right, onto the desktops of
governments that cannot afford restricted-source products.
So while spyholes may not exist today, there is nothing to prevent their existing in the future.
Given that reality, the rational response on the part of governments that do not want to use
software with such spyholes203 would be to ensure verifiability of the source code for any
operating system that they might use. It would be meaningless to put a spyhole into open-source
software: a programmer could just remove those lines of code that provide the spyhole and
Certainly, open source proponents might read this decision as an implicit vote against Microsoft’s software.
However, it is no less plausible to think that China might have wanted to see the Windows source code in order
to appropriate certain aspects of it for use in a Linux environment; it could even be the case that the Chinese
application to the Government Security Program was the result nothing more than a good-faith desire to assess
Microsoft software which was then overridden for political (job-creation) reasons.
Of course, there are people and institutions other than governments that can have more extensive access to
Windows source code under Shared Source; while they are required to sign non-disclosure agreements with
Microsoft, any programmer outside of the United States who discovered the existence of a spyhole could be
reasonably certain that their disclosure of that spyhole would go without sanction. The courts of a country
outside the United States would be receptive to the argument that a programmer finding such a spyhole would
be justified in disclosing its existence for reasons of national security. Not quite the Pentagon Papers, but
probably not that far off, either.
LESSIG, supra note 23 at 52-53.
See section 4.1 of this paper.
Of course, there may be countries that would use software with a spyhole even knowing of the spyhole, on the
basis that they might feel that they have nothing interesting to hide. Possible, but not likely. The recent upsurge
in privacy legislation both inside and outside the USA suggests rather that people want to keep their secrets
even if they have nothing to hide. For more on privacy law inside and outside the USA, see AMERICAN BAR
ASSOCIATION, CORPORATE PRIVACY HANDBOOK (2003).
- 36 -
redistribute the program.204 For those governments that insist on full verifiability, no private-
sector solution could be acceptable, and open source will be the only route to an acceptable
4.4 Openness and its alternatives: consequences of open source for society
The preceding section and its discussion of the (unfounded) concern that the US government
may force American companies to leave spyholes for it to access foreign confidential
information is in fact a subset of a larger concern: some governments do not even give access to
information to their own citizens. While no government is 100% open and transparent, there are
degrees of restrictiveness, and many governments that seem to be looking toward open source
are not open in any other aspect of their governance. The interaction between such governments
and the open-source community would probably not be harmonious.
Quite simply, open source promotes ideas of freedom and liberty that are at odds with the
principles and legislative regimes of some governments. While open-source proponents have
never hidden their political ideology, a government that looks at open-source software as nothing
more than a way to get information technology on the cheap will soon discover that, by using
this software in a manner consistent with the spirit in which it was developed, that government
has committed itself to an ideology that it may not wish to promote. And if that government
violates the spirit of open source, the programming community may lose its desire to create
open-source software, thereby killing the movement.
The community of open-source programmers is radically libertarian. Many open-source
programmers really think that there is no reason why a government or other large institution
should prefer a program created by a giant corporation to one created by a group of people sitting
in their basements who have never met each other and have no formal organization. There are
even people who think the unorganized people in their basements should be preferred to the large
corporation. And they may not be wrong. But the focus of open source on freedom and
empowerment, and access to all information about a system by any user, may run headlong into
the focus of many governments on power and control, and restricting information to elite groups.
Although it does not use this insight to note the same dichotomy, the position of the open source
community with respect to its ideology is most succinctly-stated by Microsoft: “Free Software
advocates believe software is akin to speech and should be free in the sense of ‘liberty.’”205 This
is similar to the open source mantra that the word “free” should be interpreted in the sense of
“free education” and not “free beer”.206 The history of open source is full of stories about harsh
reactions on the part of the community against those who would control access to information.207
LESSIG, supra note 23 at 106-07.
See Microsoft, Open Source Software
(www.microsoft.com/resources/sharedsource/Government/opensource.mspx). Prominent open source
developers would likely agree. See e.g. the description of the GPL as a “strong free license, much like the First
Amendment is a strong law protecting free speech in the United States.” OSI, supra note 53.
RAJANI, supra note 18.
One story in particular illustrates this focus on openness. In early versions of UNIX, the FINGER command
allowed users to see the last time another user had been logged into the system and whether that person had read
their mail. When a programmer changed the command to remove this functionality to protect the privacy of the
users (who may not have wished for others to know this kind of information about them), he was attacked by
- 37 -
The message could not be more clear: “the very existence of [the open source] community
requires freedom and openness”, and without that freedom and openness there would be no open
Proponents of open source seem not to have considered the inverse possibility in any meaningful
way. While it seems that every advocacy article about open source contains arguments either
against the idea that open source is less secure than restricted source209 or (more frequently)
promoting the idea that open source is in fact more secure than restricted source,210 these
arguments have been directed to showing that open source does not and could not contain any
spyholes or bugs. But this argument presumes that a government would want to have other
people know how its software works and what kind of information it is storing. Perhaps (and
perhaps only perhaps) that statement would be true for the US government, or the governments
of open and democratic countries such as Germany or Canada.211 It is probably less true for
governments of more authoritarian states such as the People’s Republic of China, Singapore, or
Saudi Arabia. As noted above,212 proponents of open-source-mandatory legislation have not
typically defended these laws by reference to cost savings but rather by reference to the values of
openness and citizen empowerment that open source is thought to promote. If a government
wants to control its citizens and their access to information, then adopting software whose inner
workings can be derived and understood by any person with sufficient technical skill is not the
way to achieve this goal. Today, there is little information technology of any kind in many
countries whose offline regulation is highly authoritarian.213 But an authoritarian government
given access to information technology will probably not wish to allow this space to remain
unregulated; if even the US government with the strong American protections on free speech has
felt the need to regulate the Internet,214 an authoritarian state will find the opportunity irresistible.
Moreover, the primary principle of open source is that it is stronger and more stable than
restricted source because of the ability of thousands of people to test the software by probing it
for defects, bugs, and unintended effects. In the open-source community, this is looked upon as
something similar to a right: if a system exists, it should be tested, and those people who do the
testing should be perceived as public servants and not as pariahs.215 There are many governments
others in the community for removing openness from the system. Openness was understood as a value that
trumped a user’s privacy interest. See LESSIG, supra note 23 at 77.
RAJANI, supra note 18.
See e.g. Wheeler, supra note 5.
See e.g. RAJANI, supra note 18.
Although and as noted in section 2.1 of this paper, governments today often insist upon both software escrow
agreements and exclusivity provisions when purchasing custom-developed software, which would suggest that
rather than promoting openness governments even in the US and Canada (to give only two examples) would
See section 4.1 of this paper.
See e.g. the discussion of Vietnam in LESSIG, supra note 23 at 188-90.
Those who disagree are directed to such legislation as the Children’s Online Privacy Protection Act, 15 USC
6501-05, and the Digital Millennium Copyright Act, Public Law 105-304.
See e.g. RAJANI, supra note 18: “hackers understand themselves as ‘warriors, explorers, guerrillas, and joyous
adventurers of the Digital Age’.”
- 38 -
that deny their citizens such “rights” and would harshly punish any citizen caught doing so; it is
questionable how such governments would feel when told that citizens of another country think
they have such a right to “attack” (as they see it) their computers and systems. Many private
individuals look upon probing the weaknesses of a computer network as harmless amusement or
a public service: “[t]o use Linux without criticizing it is to betray it.”216 Many of those
individuals write and debug open-source software. It is not wholly speculative to say that, if
these individuals start seeing their friends and colleagues arrested and their products re-
engineered to prevent such access, they might stop their productive programming efforts and turn
their attentions to attacking the restrictions upon their access. As one commentator has noted, “if
you are choosing products, do you really want to choose the product [against which] people may
have a vendetta?”217 And they wrote the software, so they know where the access points are and
how the restrictions will probably work.
Quite simply, openness of code is inversely related to a government’s ability to control access to
information.218 Even if the actual information in that database is not accessible, a skilled
programmer can look at the underlying architecture of a database system and know what kind of
information is being stored. By looking at the code libraries to which that database makes calls,
the programmer knows how the system works. It is a very short step from this knowledge to
creating a system that allows remote access to that information, or creates a system dump from
inside that causes the entire day’s new records to be downloaded to another computer in the
system. In a restricted-source environment, this is of course also possible, but when code is open
there are far fewer barriers. And open source programmers are people who are curious and like
to tinker with systems, and who believe that they have the right to do so.
So a government that wishes to restrict citizen access to systems must not only engage
programmers to produce its software, but also invest such resources that these programmers are
able to close off open-source software so well that the people who wrote the open-source
software cannot get around the barriers. Failure to do so would be costly, both in money219 and in
control. It also has to trust those programmers not to do the thing that they are supposed to
Clay Shirky, Short Takes on Linux (www.shirky.com/writings/short_takes.html).
Wheeler, supra note 5 section 6.10. To those who would suggest that such a change in focus or priorities would
be unlikely, it is instructive to consider the vast number of programmers who seem to have adopted as their
life’s mission finding all of the bugs and unintended effects of the various components of Microsoft Windows.
It is not long between media reports of various worms, Trojan horses, and viruses unleashed upon Windows,
and the recent (at the time of this paper) MSBlaster.exe virus, which contained a message addressed to
Microsoft’s Chairman Bill Gates (“billy gates why do you make this possible? Stop making money and fix your
software!”) is instructive. The actions of a lone renegade teenager cannot and should not be imputed to the
open-source community (indeed, there is no evidence or suggestion that the teenager in question ever wrote a
line of open-source code), and recent surveys suggest that the average open-source programmer is 28 years old
with 11 years of programming experience, hardly a teenager. See Wheeler, supra note 5 section 11.13. But it is
not uninteresting that the message found inside the MSBlaster.exe worm reflects certain beliefs that the open-
source community would likely share, such as the right of a system user to probe it for unintended effects or
bugs and an obligation on the part of the system programmer to close off that bug (rather than an obligation on
the part of the person who discovered the bug to keep that knowledge to themselves or to inform the restricted-
source software company quietly).
LESSIG, supra note 23 at 100.
The cost of just one virus, the LoveLetter virus in the winter of 2003, is estimated at $960 million USD in direct
costs and $7.7 billion USD in lost productivity. Wheeler, supra note 5 section 6.10
- 39 -
prevent others from doing. Not only does such an approach completely negate the primary
perceived benefit of open source (the worldwide community of debuggers and programmers
improving the system), to say nothing about the likelihood of code forking, but it is economically
irrational: there are restricted-source software companies that can do this better and cheaper or at
least no more expensively.220 And a restricted-source company within the jurisdiction and
therefore subject to regulation can be controlled by a government in a way that a worldwide
community of loosely-associated programmers simply cannot.221
There is no meaningful sanction that can be enforced against a government that treats open
source in this way. The GPL purports to bind those entities that use GPL-licensed software by
forcing them to redistribute their source code as well. This may work in a society based upon the
rule of law and respect for contract rights.222 But governments are not ordinary economic actors.
Notwithstanding the modern American interpretation of the state immunity doctrine which holds
inter alia that governments can be sued in US courts when their actions are equivalent to those of
an ordinary market actor,223 and while some governments outside the USA will permit suits
against them,224 not every government shares this view and many countries prohibit lawsuits
against the government. Moreover, if a government does not respect the terms of an open-source
license (e.g. it attempts to restrict distribution of software developed from a GPL-licensed
product), there may be no adequate remedy. Many governments are immune to injunctions in
their local courts and may refuse to respect foreign injunctions. It is difficult to envisage the US
government attempting to convince the government of China to respect an injunction from
Massachusetts ordering that the source code for its nuclear weapons launch system or for the
computers controlling the flow rates through the Three Gorges Dam must be released because
they were developed from a GPL-licensed kernel, to say nothing of how hard it is to envisage the
Chinese government’s ever accepting and respecting such appeals.
And why should the launch codes or the network architecture for nuclear weapons systems or
power plants be publicly accessible? The OSI takes the position that where a stable long-term
competitive advantage in a narrow field can be obtained by keeping data secret, the company or
person developing that data would have a good reason to keep that data secret,225 but the OSI is
far more balanced in its approach than many other open source proponents, and its one-
Applying the same logic as that used by open-source advocates to contend that open-source software will have
its bugs fixed faster than restricted-source, it would be logical that a restricted-source software company would
be faster to notice bugs or unintended effects than a government working on proprietary software running on
Linux, because the company would have more people reporting more errors than one government and the
company would have more people it could throw at the problem. Again, unless a government adopting open
source keeps the open-source community on its side, it loses one principal advantage of open source: access to
the community’s knowledge base.
See LESSIG, supra note 23 106-07.
Or it may not: see section 4.1 of this paper.
The interpretation of the Eleventh Amendment is beyond the scope of this paper. See e.g. Seminole Tribe of
Fla. v. Florida, 517 US 44 (1996); Pennsylvania v. Union Gas Co., 491 US 1 (1989).
See e.g. European Convention on State Immunity, art. 28, para. 2, which not only allows for suits by citizens
against their government but also allows the citizens of one state party to sue the government of another state
Open Source Institute, Software Secrets: Do They Help or Hurt? (www.opensource.org/advocacy/secrets.php).
- 40 -
paragraph overture into the discussion of open source in government simply states that such
adoption by government would be a good thing.226 When looked at more closely, there is no
reason to believe that the adoption of open source by government would lead to an increase of
open-source software for ordinary individuals. In fact, there is no reason to believe that a
government’s use of open-source software would produce any benefit whatsoever for the public.
For there to be such a public benefit, the government would have to allow its software to be
released to the public. And for many governments, there is no reason to believe that will ever
Assuming that the desire of the open-source community that governments use open source is
rational, the community must have concluded that such use of open source in government would
either lead to the development of more open source software, or the adoption of more open-
source values in government. If the hope is the former, then past conduct (which is usually a
good way to predict future conduct) by governments would suggest that software developed for
government will stay in government. If the latter, then that hope is likely to be frustrated.
As noted above, the government of Vietnam has taken steps to localize various open-source
software for use in Vietnamese and has been the site of a conference dedicated to the use of open
source.227 This is the same country that recently convicted two of its citizens on charges of
espionage for such capital offences as translating an article on the principles of democracy into
Vietnamese and posting the translation on the Internet.228 Vietnam’s Ministry of Culture also
announced in October 2002 that its prior approbation would be required to post any material
whatsoever on a Vietnamese website.229 It would seem unlikely that such a country will adopt
open values along with open source.
In his 1976 “Open Letter to Hobbyists”, Bill Gates asked rhetorically, “Who can afford to do
professional work for nothing? What hobbyist can put three man-years into programming,
finding all bugs, documenting his product, and distribute it for free?”230 The answer to this
question is now clear: open-source programmers can, and do, and plan to continue into the
foreseeable future, even if there is no business model that can make this commercially workable.
And if governments adopt open source, these “hobbyists” will have a market larger than they
could possibly have imagined. But just about every management textbook notes that, in Chinese,
the character for “danger” and “opportunity” is the same. Open source is on the cusp of this
dilemma today, and it is the imminent adoption of open source by government that has placed it
Many governments today are using open source, and many more are considering it. But none of
them has undertaken any systematic analysis of their legal system in the context of open source
adoption. A government that chooses to adopt open source and to promote its use by its citizens
Open Source Institute, Products (www.opensource.org/docs/products.php).
See sections 3 and 4.2.2 of this paper.
Caught in the net, THE ECONOMIST, August 30, 2003, at 30.
Wheeler, supra note 5 section 5.2.
- 41 -
must take certain legislative steps to ensure that open source will not be stifled by intellectual
property rights issues. It must consider whether it will pass a law mandating open source use in
government and the consequences of such a law, and whether it will dedicate scarce financial
and other resources to developing and maintaining a community of programmers (or whether it
will outsource this labor to the open-source community at large). It must ensure that open source
as created elsewhere is applicable to its domestic legislative environment and make the necessary
amendments to the relevant legislation in order to arrange for this. It must decide whether it can
be satisfied with something other than open source, in exchange for having access to the
expertise of restricted-source programs and programmers, and this decision is made in the light
of its relationships with other countries and the need for certain public perceptions at home (is it
more important to be seen as promoting a local information technology industry, or could that
money be better-spent on sanitation and public health, or fighter jets and tanks). And, last but not
least, governments that wish to consider open source must consider whether they wish to adopt
the libertarian values that underpin the open-source movement, and must consider the
ramifications if they accept the software but do not accept the values.
At this point, the open-source community also has some decisions to make. Open-source
programmers must individually consider how they will react to knowledge that a particular
government or governments that they find abhorrent have decided to use open-source software
without opening their societies. They will have to decide whether, in the absence of adoption of
open values by government, they will accept becoming a source of cheap labor for governments
using open-source software. While on one level nothing would change, as open-source software
today is produced as a result of the free labor of programmers around the world, it may be that
the open-source community might change its attitudes and approach with the knowledge that
while the users of open-source products may like the products, they don’t like the ideology that
goes along with it. Some open-source advocates are alive to this dilemma,231 but none of them
has squarely addressed it. If open-source software is adopted by governments that do not accept
open values, the open-source community will be required to make a decision: will it work for
people who refuse to listen to what it has to say? In short, will the community shut up and write
code, or does it fight back? The answer to this question is, appropriately, still open.
See e.g. RAJANI, supra note 18. “I myself have suffered at the hands of a dictatorship in Pakistan, one of my
best friends was tortured to death by the ISI (Inter Services Intelligence) of Pakistan in 1980, and numerous
others were tortured and spent tens of years in prison. Now as much as I would like [open source], I find it hard
to live with the idea that the ISI may be running Linux on their servers, and thus actually saving money to
perhaps buy more surveillance and torture equipment.”