[This article explains the notion of free and open source software (‘FOSS’) and the reasons why governments throughout the world are giving it close consideration. In particular, it highlights key legal issues facing the adoption and development of FOSS by governments. From the aspect of government procurement the article examines the models used by governments to create a level playing field for the supply of FOSS, intellectual property warranties and indemnities and the operation of the Trade Practices Act. In terms of government development of FOSS, the article considers the licensing mechanisms that will be implemented in the development and distribution of such software. In the final section, the article assesses the threat software patents and the current SCO litigation provide for FOSS. The article concludes by emphasising that governments need to be fully aware of this landscape to assess what is the most effective technology available.]
Contents
I........................................................................................... Introduction 2
II..................................................................... The Free Software Model 4
A.. What Is ‘Free Software’?.................................................. 4
B... GPL and Copyleft Licences.............................................. 5
C... The Open Source Initiative................................................ 7
D.. Tension between ‘Open Source’ and ‘Free’ Software....... 9
III.................................................... Benefits of FOSS for Governments 10
A.. Cost................................................................................... 12
B... Open Standards................................................................. 13
C... Security............................................................................. 14
D.. Providing Information Resources to the Community........ 15
IV.................... Government Procurement and Supply of Free Software 17
A.. Government Procurement Practices.................................. 18
B... Indemnities for Title and Warranties for Performance....... 20
C... Requirements of the Australian Trade Practices Act......... 21
V..................................... Government as a Developer of Free Software 22
A.. The Obligation to Redistribute Source Code..................... 24
B... Enforceability of the GPL................................................. 25
C... Layering and Combining of Licences................................ 28
D.. Dual Licensing.................................................................. 29
VI......................................................... Threats to the FOSS Movement 30
A.. Software Patents............................................................... 30
B... The SCO v IBM Litigation................................................. 34
1.. UNIX and GNU/Linux — A Brief History.......... 34
2.. The Litigation....................................................... 35
VII................................................. Conclusion: The Choice to Be Made 37
A grassroots movement started by free software guru Richard Stallman in the 1980s has revolutionised the way we think about the development and distribution of computer software. Stallman was frustrated by the fact that he could not access the source code[1] of software that was controlling a Xerox printer in his lab at Massachusetts Institute of Technology (‘MIT’). His quest to open up access to source code in software has led to the creation of a powerful form of collaboration known as the free software movement.[2]
Free software is distributed with the source code disclosed, or open, at the point of distribution. Non-free or proprietary software is distributed with no source code disclosed, meaning that anyone who wishes to discover that source code must engage in a difficult and time-consuming process of reverse engineering.[3] Many developers fear that openly distributing program source code will promote free-riding on community-based developments because it allows recipients to use software to their advantage and profit without giving back to the community.
In order to remedy the most extreme examples of this, Stallman ensured that the source code he distributed was covered by a lawfully binding obligation: the GNU[4] General Public License (‘GPL’).[5] The GPL obliges those who modify free software code to disclose their modifications to any recipient of the altered software, which in essence means the whole community. In this way, the GPL attaches itself to the copyright in software code owned by a licensor so as to oblige recipients to share their improvements for the benefit of all users.
This was Stallman’s powerful insight: copyright in software code can be used not only to restrict access and exploit its benefits for monetary reward, but also to maintain open access for downstream users and developers. Thus, if software is released with free access to its source code, any improvements made by its users must be similarly disclosed.[6]
Today, many governments are expressing interest in the free software model, and the private sector is not far behind. Some governments have already begun the task of migrating to the use of free software in the public sector. The open source GNU/Linux operating system now rivals Microsoft Windows, at least at an institutional level.[7] The Australian Government Information Management Office (‘AGIMO’) recognises that the use of free and open source software is ‘particularly widespread in areas such as network infrastructure, single-purpose computer servers, security, internet and intranet applications, and network communications’ in both the private and public sectors.[8] The adoption of GNU/Linux and applications like Open Office and Mozilla Firefox for desktop computers has not been as rapid, but there is growing interest evident amongst large-scale government, business and end users.[9]
This article highlights the key issues facing governments in adopting and developing free software. Part III considers several benefits associated with government usage of free software. Part IV explores how issues of procurement, intellectual property infringement and non-excludable warranties interact with the development and supply of free software in the public sector. Part V deals with licencing issues in public sector development. In Part VI, we consider threats to the free software movement, including software patents and recent litigation against its adopters. We conclude that there are significant policy arguments in favour of governments adopting free software in appropriate cases, and a solid, informed analysis of the benefits and risks involved should be undertaken when evaluating proposed software solutions in the public sector. In order to fully appreciate these issues, we need to start with an understanding of the concept of free software and the most important free software licences.
Richard Stallman, founder of the Free Software Foundation (‘FSF’), describes four values embodied in the phrase ‘free software’:
• the freedom to run the program, for any purpose (‘freedom 0’);
• the freedom to study how the program works, and adapt it to your needs (‘freedom 1’). Access to the source code is a precondition for this;
• the freedom to redistribute copies so you can help your neighbour (‘freedom 2); and
• the freedom to improve the program and release your improvements to the public, so that the whole community benefits (‘freedom 3’). Access to the source code is a precondition for this.[10]
Free software is not free because it has no price; it is free because it embodies values that enhance liberty for users and programmers. As Stallman points out, ‘when I speak of free software, I’m referring to freedom, not price. So think of free speech, not free beer.’[11]
Alongside the support of the open source developer community, it is through the legal mechanism of the licence that the free software model is implemented and maintained. There are two main types of free and open source software licences. Simpler licences, such as the revised Berkeley Software Distribution (‘BSD’)[12] and MIT/X Window System (‘MIT/X11’) licences, allow redistribution of the licensed program and its use in both source and binary forms,[13] with or without modifications, on the conditions that the copyright notice is retained and any applicable warranties are disclaimed. There is no requirement that derivatives of the free software must themselves be free. On the other hand, ‘copyleft’ licences (such as the GPL) attempt to create a contributory commons by requiring that any redistribution of the software or its derivatives also occurs under the free licence.[14]
A licensing system that promoted sharing and innovation was integral to the development of GNU/Linux.[15] Stallman realised that without a legal mechanism to protect free software, commercial parties could incorporate free code in their developments without any obligation to make their improved or derivative source code available for access. To remedy this, Stallman created the GPL. The GPL covers the initial program and ‘any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language’.[16]
Stallman places the GPL in a direct commercial and political context called ‘copyleft’:
To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program’s code or any program derived from it but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable.[17]
It is a rudimentary yet powerful licence. By releasing code under the GPL, the licensor creates an obligation to make accessible the source code of any software deriving from the licensed source code. Consequently, a commercial developer who takes free code under a GPL licence and incorporates it into the code of their product is (upon distribution) obliged to make the source code of the entire product available to its recipients. As Stallman explains, the GPL ‘has the strength to say no to people who would be parasites on our community.’[18] It has this strength because Stallman and the FSF foresaw that they could exploit their copyright in software to control the way the software code was treated once it left their hands.[19]
Copyleft software licences (sometimes called ‘restrictive free licences’) retain software freedom for downstream users by preventing proprietary ‘code forking’. Code forking occurs when a version of the code is taken by a particular person or group of people in order to continue development of the software in a different direction from the original code — one code base branches out into several projects. Code forking is instrumental in preventing any single organisation from dictating the way in which software must develop. Problems arise when an entity takes free software and closes the code, creating a new proprietary product, which may be developed and commercialised without returning its improvements. The GPL prevents this by requiring a licensee, upon distribution of a derivative work, to release the source code of any changes or modifications to the community under the same terms as the licensor.
Non‑restrictive free software licences, on the other hand, do not include a similar restriction and will allow proprietary derivative code to be created and distributed. For example, the original Apache[20] licence allowed a derivative work to be released with or without modifications in source or binary form. The licensee could make changes without a requirement to share them provided the name of the derivative work was changed. The revised BSD licence does not oblige modifiers of licensed software to disclose the source code to their modifications when distributing a derivative work.
The GNU Lesser General Public License (‘LGPL’) provides what is known as a ‘weak copyleft’. It does this by requiring any changes to the software itself to be licensed under the same terms, but — unlike the GPL — allows linking the software to non-free programs. The LGPL is useful for free software libraries that, for compatibility reasons, would benefit from incorporation into non-free software. We discuss the issue of linking in greater detail below. The differences between copyleft and non-copyleft free software licences are highlighted in the following table, which provides examples of key clauses.[21]
Table 1: Examples of Free Software Licences[22]
|
|
GPL |
LGPL |
Revised BSD |
MIT/ |
|
Allows copying and distribution of verbatim copies |
ü |
ü |
ü |
ü |
|
Allows charging fees for copies |
ü |
ü |
ü |
ü |
|
Allows charging fees for warranty protection |
ü |
ü |
ü |
ü |
|
Allows publication in binary form without accompanying source code |
|
|
ü |
ü |
|
Allows distribution of modified versions of the software under the same licence |
ü |
ü[23] |
ü |
ü |
|
Allows distribution of the software or derivatives under other licences |
|
ü[24] |
ü |
ü |
|
Allows linking with software released under other licences |
|
ü |
ü |
ü |
|
Requires changes to the software to be documented |
ü |
ü |
|
|
|
Requires republication of the original copyright notice |
ü |
ü |
ü |
ü |
|
Requires publication of a disclaimer of warranty for redistributions |
ü |
ü |
ü |
ü |
|
Prohibits using upstream authors’ names to promote or endorse derivatives |
|
|
ü |
ü |
All of these licences are free software licences. The GPL and LGPL are copyleft licences, and attempt to ensure that any changes to the software are released to the public. The BSD and MIT/X11 style licences are simpler and allow downstream developers to use the code in nearly any way they see fit. Which licence a developer chooses is often dependent on his or her goals. The GPL helps foster and protect a free software community and codebase, while BSD-style licences are more useful for authors coding for the benefit of all potential downstream uses, whether in free software or not. Finally, the LGPL is useful for promoting the adoption of open standards, by allowing integration of common library implementations into all software, but still requiring changes to the library to be openly licensed.
A further aspect that warrants clarification is terminology. Namely, what is the difference between free software[25] and open source software?
The Open Source Initiative (‘OSI’) is a non-profit organisation. Its leading proponent, Eric Raymond, has conceptualised business models enabling commercial exploitation of open source programs.[26] Programs distributed with the Open Source Certified trademark[27] are published on an approved list of licences[28] that conform to the open source definition.[29] The main elements of such licences are:
• free redistribution so that a party may not require a fee or royalty for the downstream distribution of the program;
• the program must include source code and allow distribution in source as well as compiled form. If a program is not distributed with its source code, there must be a well-publicised means of obtaining the source code for no more than a reasonable reproduction cost — preferably by downloading from the internet without charge;
• derived works and modifications must be allowed and be capable of distribution under the same terms as the original licence;
• the licence may preserve the integrity of the original author’s code by requiring that any redistributions include the source code in its unmodified format along with separate patches (modification chunks) to incorporate subsequent alterations. In this way, ‘unofficial’ changes can be made available but readily distinguished from the base source code;
• the licence must not discriminate against any person, group of persons, fields of endeavour, technology or software package;
• the right to use the program must not be contingent upon entry to some other form of licence or agreement such as a non-disclosure agreement;
• the right to use the program must not be contingent upon the program being part of a particular software distribution; and
• the licence must not place restrictions on other software that is distributed along with the licensed software. For example, the licence must not insist that all other programs distributed on the same medium must be open source software.[30]
The difference between free software and open source software is mainly a philosophical one. Because the definition of ‘open source’ is somewhat broader than that of ‘free software’, it is clear that all free software is open source, but not all open source software is free. In practice, however, most licences that satisfy the OSI definition will also be considered ‘free’.[31]
The OSI was initially formed by a small group of computer scientists, including Bruce Perens and Eric Raymond, in order to promote the commercial uptake of free software and respond to concerns that the term ‘free’ would discourage commercial adoption. While the definition of ‘open source’ was drawn from accepted free software guidelines,[32] the emphasis of the OSI was not on freedom but on the benefits of using an open source methodology for software development. After a short period, Bruce Perens resigned from the board of OSI, regretting that ‘Open Source has de-emphasized the importance of the freedoms involved in Free Software.’[33]
The FSF has noted that the changed focus of open source software encourages commercial developers to
gain the favourable cachet of ‘open source’ for their proprietary software products — even though those are not ‘open source software’ — because they have some relationship to free software or because the same company also maintains some free software.[34]
By doing this, developers reap the benefits of the open source development methodology without returning their own improvements to the users of free software.
In an effort to be all-encompassing when discussing this area of activity, while still respecting the nuances of these ideological differences, it has become fashionable to use the term ‘free and open source software’ (‘FOSS’).
Why, then, have governments become interested in this grassroots and ideologically-charged model of software development and distribution?
In recent years, governments throughout the world have come to recognise the benefits of FOSS.[35] A study by The MITRE Corporation on behalf of the United States Department of Defence was cautiously optimistic, concluding that the open source model
encourages significant software development and code reuse, can provide important economic benefits, and has the potential for especially large direct and indirect cost savings for military systems that require large deployments of costly software products.[36]
Taiwan has an open source project supported by the National Science Council and Ministry of Education, which examines the use of open source products to reduce royalty payments for office software in government agencies and schools.[37]
Due to the high regard for privacy in Europe, the German government is supporting an open source personal encryption utility, GnuPG, to reduce reliance on proprietary privacy-enhancing code such as PGP.[38] The Linux community has also entered a cooperative project with the Software Research Institute of the Chinese Academy of Sciences and NewMargin Venture Capital, a venture arm of the Chinese government, called Red Flag.[39] Initially, it developed a localised operating system for servers, but now incorporates developments for PCs, Personal Digital Assistants and China’s computerised lottery system.[40] The Peruvian Parliament has a Bill before it to mandate use of open source products in government offices.[41] David Nuñez, a Peruvian Congressman, circulated a letter to Microsoft on the internet that sparked much debate on the relative merits of free and open code as opposed to proprietary development.[42] There are many more examples of governments moving towards open source solutions, including South Africa, Brazil, Spain, Finland and India.[43]
The Gartner Report identifies five key factors that have influenced and heightened public interest in FOSS:
1 public sector organisations must reconcile budget reductions with annual software price increases of up to 30 per cent. Alternative licencing arrangements reduce up-front costs, making open source software an attractive option;
2 supporters of open source software have been increasingly vocal amidst a more technologically literarate community, while proprietary licencing schemes have received negative publicity;
3 antitrust litigation against Microsoft and other large software vendors has engendered negative sentiments toward what is perceived as a monopoly over United States-based commercial software;
4 the World Trade Organization has introduced penalties for member countries that fail to prosecute piracy. Governments unable to enforce software copyright internally due to cultural factors may use open source software as a compliance strategy; and
5 finally, the range of open source software solutions has expanded dramatically, and now encompasses a growing selection of tools with substantial organisational support.[44]
More broadly, the four key factors most commonly cited as motivating the adoption of FOSS in government are cost, open standards, security, and benefit to the community.
The first benefit associated with FOSS is that it may reduce the total cost of software ownership. Free software does not, for example, require a product key for every computer, user or site. Thus, as Eben Moglen points out, the provider of a ‘fully redistributable system containing only free software … can reduce the unit cost of software to zero’,[45] leaving the customer to pay only for installation and support.[46]
The development model of FOSS is also more efficient than that of proprietary software. A free software developer can reuse code that was written for any other project, by any other developer, rather than having to start from scratch each time a particular solution is required.
A key benefit of using and contributing to FOSS is that in many cases the required infrastructure already exists. Taking an existing project and having publicly-funded programmers make required changes carries no expense other than the developers’ wages; the distribution channels, project management software and developer base are already in place.[47] When creating new projects, such tools need to be established, but their practical ubiquity and standard interfaces make deployment simple and keep training costs low.
In either case, interested developers from around the world can have the opportunity to aid the government in developing software that will benefit all involved at no cost to the government. However, cost should not be the only factor governments use to evaluate software solutions. The emphasis of the free software movement is on freedom, not price.
Many advocates argue that open standards are crucial in any government acquisition of software.[48] Open standards are file formats and communication protocols which are agreed upon by community consensus and not controlled by proprietary companies. The adoption of open standards guarantees future access to current data, even if the hardware and systems used to create that data become obsolete. It also entails that governments neither mandate the use of a particular vendor’s systems (by communicating through a proprietary format) nor lock future generations into using the same proprietary systems. The standard is always published, so users are free to comment, criticise, and modify it while knowing precisely what information is being stored.
While open standards do not equate exactly to open source, open source software is more likely to use open standards because of the public consultation inherent in the development process.[49] Pursuant to the Australian government’s support for increased interoperability between software standards, it aims to adopt open standards so as to ‘ensure that Australian Government ICT systems interoperate in a trusted way with partners from industry and other governments’.[50] Integral to such interoperability is the use of software with publicly-accessible source code and documentation.
Another benefit of free software relates to the positive effect that source code availability has on software security. Bruce Shneier argues that security is better served by full disclosure of vulnerabilities and fast release of patches[51] — characteristics shared by open source software. In proprietary software, vulnerabilities are harder to identify because there is no public access to the source code. Further, once a vulnerability is discovered, only the licensor has the power to patch the hole; users must wait for an official update. Conversely, free software benefits by having greater public scrutiny of the source code, faster release times, and, if necessary, the problem could even be fixed by its users.
A recent study of the use of FOSS in the United States Department of Defence identified that free software was vital to information security in three ways:
1 the free software community has ‘produced infrastructure software … with low rates of software failure combined with early and rapid closure of security holes, which makes such systems useful as the security linchpins in broader security strategies’;[52]
2 the communities have had a ‘long-term fascination with developing more and more sophisticated applications for identifying and analyzing security holes in networks and computers, resulting in [free and open source] products … that are invaluable to in-depth analyses of security risks’;[53] and
3 free software ‘contributes to security by making it possible to change and fix security holes quickly in the face of new modes of cyberattack. This ability, which allows rapid response to new or innovative forms of cyberattack, is intrinsic to the FOSS approach and generally impractical in closed source products’.[54]
William Caelli argues that since software
cannot be trusted to be secure,
users — and particularly governments — must be able to
examine the workings of software systems to be satisfied of their
security and be able to implement tougher security measures where
the system is found to be vulnerable.[55]
Caelli further argues that ‘open source licensing represents
the ideal for the evaluation of the underlying security
architecture in the operating system and the allied mechanisms that
activate and support necessary hardware security
features’,[56]
and that ‘[r]easonable prudence would thus suggest movement
towards an open source solution.’[57]
Finally, free software provides a framework whereby the benefits of publicly-funded software development can be returned to the public. When a government develops publicly-funded software, there is a strong argument that, subject to issues of security and confidentiality, the software should be made available to the public. While not all internally developed software may be suitable for public release, use of free software may provide a framework to release code to the commons without attracting liability or requiring further expenditure to support the software.
In this regard, Russell Pavlicek questions the windfall that private organisations reap from closed-code arrangements with governments:
Which is more deplorable: that a few profit-making software companies won't be able to make as much profit from publicly funded software, or that the public who already paid for the software once with their tax dollars will have to pay for it again when the large software company puts it into their closed‑source product?[58]
Where the line will be drawn between the use of GPL and proprietary software in government requires an assessment of the government’s role in society. Some argue:
The principal role of government and universities in the ecosystem is to undertake basic research and to dispense the findings both into the societal base of technical knowledge and to private enterprises and individuals capable of developing these innovations commercially.[59]
On the other hand, the role of government could be said to be to maintain the public good. By exercising their discretion in acquiring or creating software solutions, governments can pass on benefits to the public. This has the effect of cheaply increasing access to technology and the intellectual commons.
There is evidence that the Australian government may be rethinking the strong controls it presently retains over copyright under Australian law,[60] as the Copyright Law Review Committee has been given a reference to inquire into the legitimacy of and the continuing role for Crown copyright.[61] It has been suggested that a sensible outcome would be for the Crown to retain copyright in material it develops, but take advantage of open licensing schemes where appropriate.[62] This would maximise both economic advantage and public access to information.
Lawrence Lessig argues that governments are so entranced by the minimalist role they supposedly ought to play in a free market economy that they have become blind to the benefits of government intervention. He calls on governments to take a more active role:
When government steps aside, it is not as though nothing takes its place. When governments disappear, it is not as if paradise prevails. It is not as if private interests have no interests, as if private interests do not have ends that they will pursue. To push the anti-government button is not to teleport us to Eden. When the interests of governments are gone, other interests take their place. Do we know what those interests are? And are we so certain they are better?[63]
Rod Dixon suggests that policy makers need to understand the way in which ‘open source software development poses alternative explanations of human motivation for creative endeavors, which can be ignored or used to augment our public policy choices.’[64] Once the manner in which software flows through a socio-technical network is understood, policy makers should consider whether the traditional model for deployment of software in government and associated intellectual property management is the best model to promote government policy in the 21st century.[65]
This is not to suggest that closed development or acquisition of ‘off-the-shelf’ software has no place in government. In each case, there should be an honest evaluation of which path will yield the best results. It is suggested, however, that where public funds are used to develop software, that software should ordinarily be returned to the public. There must be strong reasons to justify a decision not to release source code, such as confidentiality concerns or the presence of a large economic market for the closed product which should be exploited.
Having determined that there are benefits in employing FOSS, how does government go about procuring it? There has been much debate over the past few years suggesting that standard government procurement practices are biased against FOSS and that a level playing field needs to be established.[66] To overcome any suggested limitations in the procurement process, governments throughout the world have responded by reassessing their procurement practices. Some have chosen to ensure the effectiveness and equity of their procurement processes by restating administrative guidelines,[67] while others have used legislation to place open source software on an equal footing.[68]
In Australia, the Commonwealth government has acknowledged the opportunities for innovation and other benefits that FOSS might provide.[69] While the Australian government has no intention of enacting a legislative requirement that its agencies specifically consider open source software in procurement processes, it has taken steps to ensure that its administrative procedures equitably facilitate the procurement of all types of software.[70] As Senator Helen Coonan, Minister for Communications, Information Technology and the Arts, explained following the release of AGIMO’s Open Source Software discussion paper in August 2004,[71] the government
seeks to clear the air on the debate and provide some factual information on [its] approach to open source software and how [it is] acting to provide a level playing field for all suppliers of software solutions to government.
As well as [the] position paper, the Government is preparing a range of tools to help government agencies evaluate emerging open source solutions against more familiar proprietary software on an informed basis and appropriately assessing value for money and fit for purpose.[72]
The message is that Australian government procurement policies ‘allow agencies to use whatever software is available providing it meets agencies’ needs and is cost effective as a business solution.’[73]
By way of contrast, the Australian Democrats have lobbied for (and, in the Australian Capital Territory, obtained) legislative support for a more level playing field.[74] In late 2003, the Australian Democrats attempted to legislate consideration of open source software for public agency procurement contracts in various jurisdictions. An initial and unsuccessful attempt to legislate at a state level in South Australia[75] was refined and presented as a Bill to the Federal Parliament, but this was also unsuccessful.[76] Only the Australian Capital Territory passed the Bill, in December 2003. The Government Procurement (Principles) Guideline Amendment Act 2003 (ACT) inserts s 6A into the Government Procurement (Principles) Guideline 2002 (ACT).[77]
The Act requires government entities within the Australian Capital Territory to consider open source software and avoid ‘software that does not comply with open standards’[78] or ‘for which support or maintenance is provided only by an entity that has the right to exercise exclusive control over its sale or distribution.’[79]
The Act explicitly states that software does not comply with open standards unless
the specifications for data representations used by the software (including, for example, file formats for data storage, transmission and network protocols) are completely and accurately documented and available to the public for use, application or review without restriction.[80]
It ties the definition of open source software to that of the OSI[81] and operates subject to a three year sunset clause.[82] The Act and proposed Bills aim to address concerns that ‘a small number of software manufacturers have a disproportionate and restrictive hold on the supply, use and development of software.’[83]
The Initiative for Software Choice (‘ISC’) opposed the Australian Democrats’ legislation. In response to the earlier Bill proposed by the Australian Democrats in the South Australian Parliament, the ISC wrote a letter to the state Premier, Mike Rann, stating:
The ISC strongly supports the development and adoption of all kinds of software — [open source software], hybrid and proprietary. All models have a place in the highly competitive software market. Only in this manner, through vibrant and open competition, does the whole of the market thrive, and consumers — both public and private — reap tremendous benefits.
Standing in stark contrast to open competition are state-mandated software preferences. These ‘preference’ policies strip merit out of the process by using access to source code as a proxy for ICT project success …
The result would be reduced options for software acquisitions, largely eliminating proprietary offerings that might be the best solutions for the given need. Additionally, constituents would suffer because the best solutions could never truly be acquired, with at least one development model — proprietary software — being restricted from agency consideration. Further, South Australia’s primarily [proprietary] ICT industry would be harmed because of foreclosed access to important state market opportunities.[84]
The ISC group is reported as saying that such government mandates would be a barrier to free trade agreements.[85] Democrat Senator Brian Greig, who proposed the Bill, rebutted these claims, specifically referring to groups such as ISC.[86] Senator Greig pointed out that many current government systems, often unwittingly, mandate use of proprietary systems because software procurement choices have not considered open source alternatives and will not work with open formats or open source software. Greig argued:
The forces of proprietary software and their supporters have tried to portray this bill as being protectionist in nature, one that tries to pick software favourites. It is in fact the complete opposite. Currently, we have a system that is largely based on proprietary formats, a system that does pick favourites. Removing this and opening up the playing field to all, is the raison d’être for this bill.[87]
Senator Greig points out that when the Thai government mandated use of open source software it was able to acquire both hardware and software for a price similar to that which it previously paid for Microsoft’s software licences alone. The result was that Microsoft dramatically reduced its prices in order to stay competitive in the government contract area. Greig claims that Microsoft would recoup lost revenue when they provided upgrades: ‘Microsoft’s actions echo the words of Henry Ford when he offered to give away his cars provided he could keep the monopoly on spare parts. It is this type of monopoly that the use of proprietary formats maintains’.[88] The key was to obtain, and then be able to control, the contract. By mandating consideration of open source alternatives, the Thai government removed what was previously a barrier to efficient market processes — ironically, a barrier erected by a policy of economic non-interference.
Irrespective of whether it has occurred through legislative or administrative processes, there can be little doubt that governments are now more aware of the intricacies associated with procuring computer software. Emerging from this discussion is the need to effectively provide for the equal consideration of FOSS alternatives.
Regardless of whether a government agency contracts for supply or creation of free software, it should consider whether it needs indemnities against claims of intellectual property infringement from third parties. When contributions are made by community-based developers to a project controlled by a government agency, it will often be useful to require a declaration by each developer that they have written the code themselves or acquired it on a compatible licence. This is common practice for the large free software development groups. Jeremy Malcolm considers it sensible for developers to assume the risk when developing open source software because they are in the best position to ensure that the code does not infringe the intellectual property rights of any other persons.[89]
Where a government agency enters into a contract for the supply of free software from a large vendor, it would be prudent to seek both indemnities for title and warranties that the software will work (and continue to work) as required, and that the software will be repaired or replaced if required.[90] In most cases, indemnities, warranties and continuing support agreements provide the only reason to enter into a supply contract with a large vendor. If they are not required, deployment and training can be undertaken in-house or through a smaller technical organisation. Risk assessment should be undertaken before any supply contract is entered into, whether the supply is for open or closed source software. If these indemnities and warranties are required, it will obviously be important to assess whether the proposed supplier has the means to fulfil its potential obligations.
Many free and proprietary software licences purport to disclaim all warranties, whether express or implied, in order to avoid the possibility of free software developers being held liable for any fault in the program. In Australia, the Trade Practices Act 1974 (Cth) (‘TPA’) provides certain non-excludable warranties where a corporation is carrying on a business. The TPA applies to the Australian government and an ‘authority of the Commonwealth’ when either is carrying on a business, but only Commonwealth authorities can be fined or prosecuted.[91] The TPA will be of significance when a government is either a consumer/procurer or developer/supplier of software.
The TPA establishes several consumer protection measures. Importantly, it prohibits misleading or deceptive conduct[92] and the making of false or misleading representations,[93] and implies warranties as to title and of quiet enjoyment.[94] It also imports requirements that goods will be fit for the purpose supplied, of merchantable quality, and, if supplied by reference, will correspond with the sample.[95] Finally, the Act sets conditions that services will be rendered with due care and skill and be fit for purpose.[96] These implied conditions and warranties cannot be excluded by contract.[97] Most of these provisions apply when a corporation[98] is supplying goods or services to a consumer in ‘the course of a business’.[99] Peter James notes that
[w]here software is supplied by way of gift, not sale, this requirement nevertheless would be satisfied if the software supply is part of a commercial dealing or if the supply is connected (even indirectly) with advancing or protecting the commercial interests of the supplier.[100]
This means that the implied conditions will generally only apply to suppliers of free software, and not individual developers.
If a government or government agency begins to engage in a commercial or a related supply of software to consumers, it must be aware that these provisions impose certain minimum levels of quality upon any software it provides, as well as regulating the manner in which that software is represented. On the other hand, if the government developer merely contributes to an open source project outside of a business relationship, no liability could arise.
Due to the loose wording of exclusion clauses found in free software licences, they may not be effective in limiting liability for negligence and consequential damages. Peter James notes that the ‘courts look at the provision as a whole and, if the exclusion attempts to limit liability for the very purpose of the contract, it will need to be clearly and unambiguously drafted to survive challenge’,[101] which the GPL is not. For these reasons, anyone supplying software under the GPL and similar licences may be liable for damages not only for direct losses, but also for consequential losses — including loss of profits or data — unless they adequately modify the relevant clauses in the GPL.[102]
When a decision is made to use free software for a government function, consideration must be given to whether the software should be developed internally, outsourced to hired contractors, or built upon existing software and customised by another supplier. Obviously, if the software required is already available in a form that is usable by the government, such as an office suite or desktop environment, governments should take advantage of the pre-existing code and have installation and training carried out by in-house staff or commercial vendors. However, where a substantial portion of the software needs to be created, it will be necessary to consider whether the department is capable of supporting its development and maintenance. There is also considerable momentum for the creation of shared government code repositories, so that one agency can create (or commission) a piece of software that is flexible enough to be reused by other agencies (‘white-branding’) and make it available for reuse.[104]
Section 176 of the Copyright Act 1968 (Cth) provides that the Commonwealth and states are owners of copyright in original literary works made by, or under the direction and control of, the Commonwealth or the state. Effectively, the Crown will own the copyright in both the software it creates in-house and the software it causes to be created by contractual developers, subject to any agreement to the contrary.[105] Whether development is out-sourced or not, the government should stipulate how the development is to take place. The majority of development could be completed by one group of developers, and released as free software after completion, or the core group of developers could act as a development hub for community-based free software developers. Each methodology has its own advantages and disadvantages.
Where development is completed by a core in-house or out-sourced group, without the aid of other members of the free software community, the development will be easier to manage. Schedules and costs can be more accurately planned, features can be implemented in proportion to their importance to the government agency, necessary sensitive information can be made available to a select group only, and the product can be made available to the public at a stage where it is stable and has been cleansed of any sensitive information. On the other hand, the developers would lose access to some of the benefits of open source development — principally, the way in which work is distributed over a broad developer base. Distributed development can provide not only cheap labour but potentially also a more productive and inventive team, leading to more efficient, secure code. Additionally, if the government’s intention is not to release code until after development has been completed, and the developing agency is building upon GPL-licensed code, it must take care to avoid earlier distribution of the software in order to prevent the obligation to distribute source code from arising.[106] This is particularly important when testing or evaluation versions of the software are provided.
Alternatively, software can also be effectively developed through government-sponsored, community-based development. According to this methodology, the core (in-house or contracted) development group forms the nexus for development, providing the framework, momentum and guidance to a wider community of free software developers. However, one of the major disadvantages to this approach is the extra overhead associated with managing a large distributed community, whose aims and schedules do not always align with those of the agency. Accordingly, this methodology is probably best applied to large projects that are likely to be of immediate use to a large number of people, where interested and motivated developers can provide substantial help in development.[107]
Finally, government agencies might also contribute to and customise a pre‑existing free software project, making any required changes without taking control of the development process. Under this approach the agency would not be responsible for management of users, but would be able to build upon pre‑existing work, extend the software to meet its requirements, and give the end product back to the community as a simple, one-off gift.
The obligation to redistribute must be clearly understood by any user of free software. If a government decides to use free software, it must be aware of the circumstances in which it will be obliged to disclose its modifications to the program source code. For restrictive free licences like the GPL, a government will be obliged to disclose the source for any derivative works it makes and distributes.[108]
Due to uncertainties in the licence (the effect of which will be examined below),[109] it is not clear exactly when a derivative work will be created. Modifications to the software are clearly derivative works and will be treated as such. The difficulty lies in determining when new programs, which simply make use of free software, or are designed to operate with free software — in short, mere use of licensed code — will be treated as derivative works. Stallman argues that any use of code released under the GPL by another program creates an obligation upon that other program.[110] However, because the GPL appears to carve out a set of rights from copyright law, it would appear that not all forms of incorporation are capable of giving rise to a derivative work. As Rosen argues, ‘[t]he primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program’.[111] However, he adds that ‘[t]he meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs.’[112] Accordingly, it is possible to create new software that uses and relies upon free software components without creating a derivative work.
The distinction, though fine, is important. If a program is a derivative of another work which is licensed under the GPL, any distribution of the new program must also be under the GPL. On the other hand, if the new software is not a derivative, the developer is free to release the software on any terms. For governments, this can be very important because it may oblige the release of sensitive or confidential information. To safely avoid disclosure, software that may contain or process such information should be designed to operate independently from any software licensed under terms which would compel disclosure of that information. In many cases, the sensitive parts of code can be built into separate modules, which do not form part of the main application, and therefore are not required to be licensed under the GPL.
Simply creating a derivative work, without more, will not give rise to an obligation to publish it under a free software licence. The derivative work must be ‘distributed’. However, what constitutes a ‘distribution’ is not clear. It is apparent from the FSF’s own comments that internal distribution within a single organisation will not be considered a ‘distribution’ under the GPL.[113] Similarly, Eben Moglen, general counsel for the FSF, takes the view that ‘Federal Government agencies may share free software without making a “distribution”.’[114] Thus, in Australia, sharing of code between federal government departments would probably not give rise to an obligation to make the source code available. The same might also be true for sharing between state government departments, and possibly between federal and state or state and state governments.[115]
However, if the software is shared with or by a statutory corporation, there will be a stronger argument that a ‘distribution’ has taken place. Where a commercial body exists to carry out a public function, but is otherwise independent from the government, it is probable that any sharing of software between it and another such entity would not be taken to have been made between two parts of the Crown or government; rather, the presumption would arise that a distribution between two separate entities had taken place. Accordingly, any software that contains sensitive or confidential information, if it forms a derivative of any restrictive free software, can be shared between government departments without requiring disclosure of the source. Even so, care must be taken to avoid distribution to third parties, including statutory corporations.
Finally, on the subject of sensitive or confidential information, it must be made clear that merely using free software to create or store the information will never give rise to an obligation to disclose. The concern only arises when such information is used to create or modify the software itself and that information becomes embedded in the code. As such, an end user who does not modify source code will never be under such an obligation.
There is considerable debate over the enforceability of the GPL and whether it is to be construed as a licence or a contract.[116] Specifically, if it is a contract, is there valid consideration to create an enforceable contract? On the other hand, if it is considered to be a copyright licence, is it possible to enforce the requirements that users distribute any derivative works under equivalent terms? Ben Giles argues that since the only promise that a free software user makes is to redistribute under the GPL if and only if they choose to distribute a derivative work, that promise is not sufficient and there is no consideration to support a valid contract.[117] This argument rests on the doctrine of illusory consideration, which means that promises that are only to be carried out at the promisor’s discretion cannot create a binding contract.[118] There has been no significant interpretation or modern restatement of this doctrine in Australian law. Arguably, due to significant changes to the way in which parties do business online, the doctrine has lost some relevance in recent years.
In contrast, Moglen suggests that the GPL is a copyright licence, not a contract: ‘[l]icenses are not contracts: the work’s user is obliged to remain within the bounds of the license not because she voluntarily promised, but because she doesn’t have any right to act at all except as the license permits.’[119] The exclusive rights of the copyright owner can be used to restrict reproduction, making a derivative work and distributing the software, and any user who does these things must do so in accordance with the terms of the licence.[120] Any obligations in the GPL that purport to do more than this will need to be supported by contractual consideration.
As yet, there has been no significant litigation concerning the enforceability and classification of the GPL, though in 2004 the Munich District Court issued a preliminary injunction against Sitecom Germany GmbH for alleged infringement of the GPL.[121] Moglen suggests that ‘there have been no such controversies because nobody thinks they're going to win them’.[122] Maureen O’Sullivan notes that the threat of damage to a firm’s reputation from the watchful open source community, as well as the possibility of a lengthy court case, has been successful over the last decade in ensuring that firms comply with the terms of the GPL.[123] It thus seems clear that even though the GPL has not been tested in court, questions about its technical legal enforceability are not barriers to its widespread use, because substantial compliance with its terms can be expected to continue well into the foreseeable future.
The other concern about free software licences is that a gratuitous licence can normally be revoked at will.[124] This means that, in the case where one single entity controls a significant portion of the copyright in the source code for a free software package, that entity may be able to terminate the licence and users will no longer be entitled to copy or redistribute the software. Jeremy Malcolm calls this ‘one of the best kept secrets of the open source movement’,[125] and notes the potential danger that an upstream developer could revoke the licence. This would cause all derived projects to be rendered invalid to the extent that they are derived from the original.[126] In practical terms, however, it would be hard for any single licensor to revoke a licence partially supporting a program — especially one which forms part of a large, distributed project.
In the event that a licence is revoked, it is likely that the doctrine of estoppel would prevent the copyright owner from asserting his or her rights. Equitable estoppel has been developed to prevent a person from unconscionably denying an expectation where they induce in another party (here the licensee) an assumption that a particular legal relationship exists between them, and that party subsequently acts, reasonably, in reliance upon that expectation.[127] If a licensor releases software under a free software licence, they are essentially inviting others to perpetually use, reproduce, modify and distribute that software. If another person does in fact make use of the software, and the original licensor purports to revoke the licence (a departure clearly to that person’s detriment), the doctrine of equitable estoppel would arguably prevent the licensor from denying that the licence could not be revoked.[128] Again, to reach this stage in legal proceedings would be quite rare. While revocation may be technically possible, it is unlikely to occur in the face of public opposition and a vigilant open source community. Regardless, as has been demonstrated over the last 12 months by The SCO Group Inc v International Business Machines Corporation litigation,[129] the developer community is more than willing to replace any code for which the licence has been revoked or that otherwise infringes copyright. For these reasons, the issue of revocability is much more a theoretical than a practical concern.
There are many different FOSS licences, a number of which are nearly identical to the copyleft GPL or the permissive MIT/X11 and BSD licences. Unfortunately, some of the minor differences render them legally incompatible with other licences. This is particularly the case when combining code released under the GPL licence with code released under licences which are not considered to be GPL-compatible. The copyleft nature of the GPL will not allow further restrictions to be placed upon software that is derived from code released under the GPL. It prevents code forking under different licences, which means that downstream developers cannot take the benefits of free software and create a closed product. Accordingly, if another licence imposes additional restrictions, source code released under that licence cannot be combined with other source code licensed under the GPL. Such a licence is said to be ‘GPL-incompatible’.
The problem is accentuated when a single distribution makes use of software that is licensed under a large number of free software licences. Peter James recognised this problem, noting the main licence groups in Red Hat Linux 7.1:[130]</