Fitzgerald, Brian; Bassatt, Graham; Rosen, Larry; Lard, Bill; Schellhase, David; Lind, Yancy --- "Legal Issues Relating to Free and Open Source Software" [2001] JlLawInfoSci 13; (2001) 12(2) Journal of Law, Information and Science 159

	Home \| Databases \| WorldLII \| Search \| Feedback Journal of Law, Information and Science

LARRY ROSEN (ROSENLAW.COM), BILL LARD (SUN MICROSYSTEMS), DAVID SCHELLHASE (FORMERLY LINUXCARE), YANCY LIND (LUTRIS TECHNOLOGIES)

Abstract

The paper examines many of the legal issues surrounding free and open source software and the licensing arrangements used to ensure that it remains free and open. First, the paper contrasts proprietorial software licensing which aims to protect the developer’s intellectual property monopoly in the software for reasons of commercial gain, with non-proprietorial software licensing which is developed by communities of programmers for little commercial gain. Then it looks at two types of non-proprietorial software licences, free and open source, examining the tension between the two and setting out the terms of various free and open source licences in table form. Finally, the article considers some of the legal issues relating to free and open source licensed software, such as the viral nature of free software, the point at which one is contractually bound by an open source licence, and some jurisdictional and choice of law problems which are likely to arise in the future with respect to the enforcement of free software licences.

The second part of the paper is the transcript of proceedings at a seminar at Santa Clara University on legal and commercial difficulties relating to open source software. The first contributor was Larry Rosen, a lawyer and executive director of Open Source Initiative who analysed the differences between free and open source software before considering some of the legal problems to which free and open source software licences give rise. He was followed by David Schellhase, an inhouse lawyer for a Linux services company, who compared the legal problems faced by a company working with open source software to those faced by a company working with proprietary software. Yancy Lind, a business man, then considered the difficulties faced by companies trying to make open source software commercially successful. Bill Lard a lawyer who is responsible for Sun Microsystems’ technology licensing strategy, then spoke about the place of public licensing in the industry in general and in Sun’s licensing strategy in particular.

Introduction

Background

This is a story about the models for distributing software, in particular the source (or human readable) code of the software. It is a story of many dimensions: law, politics, social planning, and culture along with economics.

In the classic free software scenario embodied in the GNU General Public License (GPL) software source code is distributed in a manner that is open and free (as in speech not as in beer) allowing software developers (usually many hundreds, known broadly as the ‘hacker community’) further down the line to modify and improve upon the initial software product. The initial distributor of the code controls its presentation and further dissemination through copyright and contract law (contractual software license). In general, the down the line developer and modifier is required to make source code of any derivative work that they distribute, available for all to see. In this process copyright law is used to create a ‘copyleft’ effect as opposed to a ‘copyright’ effect by mandating that code should be open and free for all to use in innovation and development of software. By way of contrast, in a proprietary or closed distribution model source code is not released and can only be ascertained through decompilation or reverse engineering.

Software code is protected as expression in the form of a literary text under copyright law. Copyright law will protect the expression of an idea or facts but not the idea or facts themselves. Patent law and trademark law, amongst other things, may also bestow legal rights in relation to software.^[1] Once code is written it can be protected in copyright law for the life of the author plus 50 years in some countries and up to 70 years in other countries (USA, Europe). As a general rule if code is written in the course of employment then the employer will be the lawful owner of the copyright in that code. Software is generally not sold but distributed through software (contractual?) licenses. This has led some to say in relation to software and other informational goods that the ‘licence is the product’. In the case of free and open source software the legal regime is built on the back of copyright in the original code along with the terms of the licence. Therefore the terms of the licence are crucial to understanding user and exploitation rights especially in a commercial setting.

Proprietary and Communal Software Licensing

Proprietary methods involve employing a team of programmers and tying them to a non-disclosure agreement. Cloistered for a period of time, they create, test and debug their code. Most importantly, copyright is claimed over the resulting code.^[2] Software is marketed as a copyright license and defined as ‘any product we make available for license for a fee’.^[3] Bill Gates has made it clear that code is zealously guarded and presented in executable form only: ‘…a competitor who is free to review Microsoft’s source code…will see the architecture, data structures, algorithms and other key aspects of the relevant Microsoft product. That will make it much easier to copy Microsoft’s innovations, which is why commercial software vendors generally do not provide source code to rivals.’^[4]

Licenses are sold under a Volume License Product Key (VPK) and the consumer is held liable for any unauthorized use of this key.^[5] A customer can run the program which is defined as the capacity to copy, install, use, access or display the product for the number of copies authorised. A proprietary licensee may not ‘reverse engineer, decompile, or disassemble products except to the extent expressly permitted by applicable law’.^[6] This is contrary to the view that software diversity is best facilitated by reverse engineering.^{[7 ]}Even so, a proprietary license recognizes that a copyright owner cannot require a licensee to enter a contract that is prohibited by statute, as is a contract to override reverse engineering rights in Australia;^[8] although it is unclear in the US whether the right to reproduce a program in order to facilitate reverse engineering for the purpose of interoperability can be overridden by contract.^[9] A licensee may not rent, lease, lend or host products.^[10] In return, the user is offered a limited warranty that the product will ‘perform substantially in accordance with our user documentation’ for a period up to ninety (90) days from first running the program.^[11] Whether the final product is sold by shrinkwrap or clickwrap license, licensees are dependent on the vendor for upgrades and patches. Traditionally upgrades enabled a licensee to purchase modifications when, and, as they saw fit. Microsoft’s Software Assurance scheme requires a user to buy an upgrade subscription as part of the license of a product.^[12] Critics claim that this upgrade scheme applies a fee to the licensee even if no upgrade is provided in that period and this merely offers a ‘right to upgrade that previously existed without any requirement for advanced payment to preserve the right’. ^[13]

Conversely, non-proprietorial software is created by communities of disparate developers for little commercial gain. Its benefits were propounded by Eric Raymond in his work The Cathedral and the Bazaar, first written in May 1997.^{[14 ]} He compares the commercial (non-free) development of software to the building of large cathedrals: ‘carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.’^[15] Slow to react, and with too few participants, the cathedral approach is not as effective as that of the bazaar:

Raymond identified 17 features of the non-proprietorial system that contributed to its successful creation of software such as the alternate operating system GNU/Linux.^{[17 ]} The most important are:

• Good programmers know what to write. Great ones know what to rewrite and reuse.

• Many programmers build on the efforts of others rather than doing things from scratch.

• The best programs are written by reacting to a need perceived by programmers.

• Treating users as co-developers allows bugs to be identified quickly and more effectively.

• Such communities have a scalability of reaction to a perceived problem that commercial developers even as big as Microsoft have come to realize.^[18] Raymond asserts: ‘[G]iven enough eyeballs, all bugs are shallow’.^[19]

Raymond argues developers in such communities are not motivated by commercial gain. An internal market of reputation exists. The principal role of the project leader is to facilitate ‘egoless programming’. On describing the role of a project leader in such a distributed format, he quotes the words of a Russian anarchist, Kropotkin:

Raymond claims community members are driven by ‘egoboo’ - the enhancement to self-esteem that results from successful participation in the group.^[21] The free community can bring more rapid attention to a problem whereas the proprietary closed-source responses are ‘frequently as late as they are disappointing’.^[22] ‘In the world of cheap PCs and fast Internet links we find pretty consistently that the only really limiting resource is skilled attention.’^[23] Critically, developers should have access to the source code of a program thus enabling modification and distribution with limited obligations to the licensor. It is source code that ‘links computers and humans. To understand how a program runs; to be able to tinker with it and change it; to extend a program or link it to another – to do any of these things with a program requires some access to the source’.^[24]

Free and open source development also has supporters in the commercial market place. Equipment manufacturers are keen supporters of open source software that will make their machines interoperable and broaden potential market share. They might use free or open code in ROM chips, which are executed when a computer starts up and dictates the range of activities it can perform. Interoperability is needed between these ROM chips and any software to be added later. For example, a manufacturer of computers may wish to be operable with Sun’s Star Office application and would use any open source or free code that could enhance such operability. In order to have their machines used as Web servers they would wish to be operable with all ranges of web software on the market. A hardware company that could sell a machine with a free or open source operating system may be able to increase its profit margins when it does not have to pay mandatory license fees to a particular supplier. Recognising quality, in 1998 IBM stopped putting out its own server product with its machines and adopted Apache, an open source server product with over 80% market share.

Governments, too, recognise the benefits of open source development.^{[25 ]} A recent study by Mitre Corporation on behalf of the US Department of Defence was cautiously optimistic concluding open source ‘encourages significant software development and code re-use, 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’. ^[26] Taiwan has an open source project supported by the National Science Council and Ministry of Education. It is examining use of open source products to save royalty payments for office software in government agencies and schools.^{[27 ]} Due to the high regard for privacy considerations in Europe, the German government is supporting an open source project, GnuPG, to reduce reliance on proprietary privacy enhancing code such as PGP.^{[28 ]}

The Linux community has 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 RedFlag. Initially, it developed a localised operating system for servers but now incorporates developments for PC systems, PDAs, and China’s computerized lottery system.^[29] The Peruvian parliament has a Bill before it to mandate use of open source products in government offices. Peruvian Congressman, David Villanueva Nuñez, 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.^[30]

The clash between non-proprietary and proprietary forms of development is a political, social and economic struggle. ‘Software pervades modern society; it can be found in almost every product. So naturally, if only a few people control software, their power increases and restricts users' freedom.’^{[31 ]} Development of such ‘gift cultures’ can mitigate ‘worrisome concentrations of corporate power in the software industry [by disdaining] those who seek to financially profit from the community's shared body of knowledge’.^[32]

This does not mean non-proprietary development groups are united. They differ over how to best maintain the communal aspects of software development. Since the stock market ‘tech wreck’, non-proprietary groups have accelerated their split into two main camps – the free software and open source movements. Their essential difference lies in their approaches to the commercialisation of non-proprietary code.

Free Software Foundation (FSF) and Copy Left

‘Free software does not mean that the software is free, as in requiring no payment. When I speak of free software, I'm referring to freedom, not price. So think of free speech, not free beer.’^[33] Thus asserts Richard Stallman, the founder of the Free Software Foundation. Software is not free because it has no price; it is free because it contains values that enhance liberty for users and programmers. Stallman applies four strict criteria to maintain free values in software:

2) 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.

3) The freedom to redistribute copies so you can help your neighbour (freedom 2).

4) 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’.^[34]

GNU/Linux

Stallman realised the advantage of accessing source code when he tried to change a program given to him by Xerox so it would run on printers in his MIT lab. Xerox did not make the source code available and instructed an employee not to give Stallman copies of the software. Comparing the sharing of programs to the sharing of recipes (and the improvement of programs and recipes by changing the source), he strongly criticizes proprietary control of software:

Free software developers often contribute to a program by accident and share source code on some ‘intellectual commons’,^[36] usually the Internet.^[37] One module can be used to integrate with a need of another developer. Thus software progresses incrementally.

When broken up due to anti-trust findings against it in 1984, AT&T tried to license use of its previously free Unix code. In reaction to this, Stallman launched a project called GNU – a recursive acronym meaning ‘GNU’s not Unix’. The aim was to create tools to build an operating system and then to produce such a system called GNU OS. By the end of the 1980’s tools such as a compiler had been developed but the project slackened as the kernel for GNU OS was being formed. In 1991, Stallman found by accident the Linux module developed by Linus Torvalds in Finland to add to his GNU program after his attention was drawn to it by other free developers who had seen parts on the Internet.^[38] Torvalds joined with Stallman and the GNU/Linux operating system emerged. This system was distributed with its source code.

In ’91 only Macintosh had advanced beyond a command-driven interface for operating systems. Such a system of complicated commands had to be mastered chilling the proliferation of computers to novice and irregular users. How many wanted to remember a command like ‘copy *.* A:’ in order to copy all files to a floppy disk from a hard drive? During ’91 Microsoft developed a serious graphical user interface (GUI) for an operating system not reliant on a DOS command driven system. The methods used by Microsoft to develop and ensure consumer loyalty to this system they developed and propertized is the subject of an extensive series of ongoing anti-trust cases. The GNU/Linux system has also met this challenge by adopting contributions of groups such as Samba to produce GUI interfaces for file and print servers.^[39]

The result is that Linux now represents an operating system with significant profile in the community, so much so that it is said to threaten the dominance of MS Windows. A recent statistical study shows some comparative findings:

• Reliability: In a ten-month test for reliability run by ZDNet, NT servers crashed an average of once every six weeks, the GNU/Linux servers never went down

• Security: Insurance companies covering ‘hacking’ incidents have begun charging clients 5 to 15 percent more where Microsoft's Windows NT software is employed instead of Unix or GNU/Linux, in Internet operations.^[40]

1.1.1 General Public License (GPL)

A licensing system that promoted sharing and innovation was critical in the development of GNU/Linux. The free software movement is concerned with colonization by commercial (non-free) groups incorporating free code into their developments. Any copyright taken out over the resultant program effectively privatises the free code used. Furthermore, non-free developers have freeloaded by not contributing anything back to the free community. To counter this, Stallman introduced the GNU General Public License (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’.^[41]

Stallman places the GPL in a direct commercial and political context called 'Copyleft’:

It is a powerful license. By mixing GPL’d code with new code in a derivative work the obligation arises to make all the source code known or ‘free’. Consequently, a commercial developer who takes free code under a GPL license into the code of their product is obliged to make the source code of the entire product available. Stallman argues this ensures 'freedom three' is maintained and the whole community benefits. The GPL ‘actually has the strength to say no to people who would be parasites on our community’.^[43]

The Open Source Movement

The open source movement is a non-profit organization. Its leading proponent, Eric Raymond, has conceptualised business models enabling commercial exploitation of open source programs.^[44] Programs distributed with the Open Source Certified trademark (OSI Certified) ^[45] are published on an approved list of licenses^[46] that conform to the open source definition.^[47] The main elements of such licenses are:

• Free redistribution so that a party may not charge a fee or royalty for the program unless it is a component of an aggregate software distribution containing programs from several different sources.

• The program must include source code, and must allow distribution in source code as well as compiled form. If a program is not distributed with source code (eg Apache license) there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge.

• Derived works and modifications must be allowed and be capable of distribution under the same terms as the original license

• The license must maintain the integrity of the authors code by guaranteeing that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, ‘unofficial’ changes can be made available but readily distinguished from the base source.

• The license must not discriminate against any person, group of persons or fields of endeavour.

• The rights attached to the program must not require entry to some other form of license or agreement such as a non-disclosure agreement.

• The rights attached to the program must not depend on the program's being part of a particular software distribution.

• The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.^[48]

Tension between Open Source and Free Software

It could appear that the difference between open source and free software is minimal but the move to embrace the commercial market by open source developers has led the free software movement to clearly differentiate themselves. The distinction is over the implications of the GPL. Copyleft software maintains freedom for all developers (and consequently users). It requires a licensee to give back under the terms of the GPL the source code of any changes or modifications. Open source software will allow non-free versions to be made. For example, the Apache license allows a work to be distributed with or without modifications in source or binary form. The licensee can make changes without a requirement to share them provided the name of the derivative work is changed. The Berkeley Software Distribution (BSD) License contains no obligation to disclose source code of modifications when distributing a derivative work.^[49]

Open source developers can use free software to add to proprietary software so a system can become a combination. While acknowledging that the real enemy is proprietary software companies, FSF are wary of open source groups who mix free and non-copylefted software. ‘In effect, these companies seek 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.^[50]

The tension is exacerbated by what many call the ‘viral’ nature of free GPL-licensed (GPL’d) code.

Table 1 - Basic Clauses of Some Free and Open Source Licenses

Some Legal Issues in Free and Open Source Licensed Software

The ‘Viral’ Nature of Free Software

The GPL aims to ‘control the distribution of derivative or collective works’. Clause 2 states that you can form a new work based on the original program provided that such a derivative work is itself licensed to all third parties at no charge under the terms of the GPL. Source code must be supplied. It is not aimed at claiming rights over entirely new works. The GPL refers to a derivative work as defined in copyright law.^[57] In US copyright law^[58] a derivative work must be based on one or more pre-existing works, and must recast, transform or adapt an original work.^[59] To be a derivative work the licensee must change the code in the original GPL’d work (pre-existing work). The copyright owner of the pre-existing work has the right to authorise preparation of derivative works.^[60] Copyright subsists for the author of the derivative work^[61] but only to the extent of the material added to the pre-existing work.^[62] In addition, copyright for the derivative work ‘does not extend to any part of the work in which such material has been used unlawfully’^[63].

Here lies an interesting issue. The copyright statute gives the author of the derivative work the right to control copyright in the added (non pre-existing) parts of a derivative work.^[64] The GPL insists they must reveal such changes. In this sense the GPL appears to override the rights given under the copyright statute to control the added (non pre-existing) parts of the derivative work. However, for the author of a derivative work to claim copyright under US law they will need to show they have not used the pre-existing work unlawfully.^[65]Therefore an author of a derivative program will need to rely on the permission to use code granted in the GPL (which also contains an obligation to disclose source code) in order to assert copyright in the derivative work, thereby relinquishing complete control over the added (non pre-existing) parts of the derivative work. Although, in an instance where the use of GPL’d code is a lawful act of fair use under s 107 of the US Copyright Act the need to gain permission pursuant to the GPL is removed.^[66] Does this mean there is no obligation to disclose source code in this instance?

It is these types of uncertainties that have led non-free developers to fear their source code might need to be revealed by any contact with GPL licensed software. Compounding these concerns, the GPL is silent on length of license term.^[67]

With one exception to be covered later in this paper, the GPL has not been tested in court. In order to avoid copyright infringement and the need to rely on the GPL, the down the line developer who wishes to distribute software will need to show that their code is an independent work and that it does not infringe the copyright owner’s exclusive right to reproduce or prepare a derivative work. What does current law say is an infringement of the exclusive right of the copyright owner to prepare a derivative work under s106 US Copyright Act? There is not a plethora of cases testing this issue with regard to software. For an infringement, there must be substantial similarity in the ‘total concept and feel’ of a derivative work in comparison to the underlying work. ‘The little available authority suggests that a work is not derivative unless it has been substantially copied from the prior work.’^{[68 ]} Yet, in another case, digital images that were ‘touched up or modified selections’ of original works were not found to make the later work an infringing derivative.^[69] Most importantly for free and open source developers, infringement was not found in a later work that was an improvement of a Nintendo computer game.^[70] The later work allowed a user to add lives to a game character, increase the speed of its movements and empowered it to float over obstacles. However, in another case, a company that downloaded game levels created by users utilising the ‘build’ utility provided in the game and burnt these to a CD for commercial gain was found to have created an infringing derivative work.^[71]

One commentator suggests three factors to consider when establishing whether a later work infringes. First, does the later work ‘substantially incorporate’ or is it ‘substantially similar’ to the pre-existing work? Second, has the copyright holder of the pre-existing work been compensated for such use? Third, what rights did the creator of the later work have to ‘display or to copy’ the underlying work.^[72] It is further argued that the copyright owner of the pre-existing work must prove the derivative use ‘was not customary or reasonably expected’ thus denying them opportunity to be compensated for their work.^[73] All free and open source developers know it is customary and reasonably expected for other developers to build on their efforts and, often, the only form of compensation in the GPL is the publication of source code for any derivative changes. The harm in misuse of GPL products often lies in lack of specific performance in publishing source code of the derivative changes.

As indicated above, the GPL does not apply to programs ‘reasonably considered independent and separate works in themselves’^[74] which can be distributed within a modified work but not come under GPL obligations. Chief legal representative of the open source licensing certification process, Larry Rosen, argues concerns about GPL’s ‘viral’ nature are exaggerated. ‘A derivative work is not created by merely touching; any more that one catches AIDS by merely hugging. A more intimate relationship is required.’^[75] Rosen indicates clear examples where infringement of the GPL work’s copyright would not occur. First, a proprietary program that runs a GPL work such as in the GNU/Linux operating system does not alter the GPL licensed work. Secondly, programs that are dynamically linked such as a printer driver for a Linux operating system do not interfere with each other’s source code. Thirdly, programs that interact with common data but use an application program interface (API) do not alter the source code of each program. For an infringement of the GPL to occur an author must ‘consciously recast, transform, or adapt the GPL-licensed software’ and then distribute this work under some license other than the GPL. Rosen also objects to the term ‘viral’. He sees the GPL license as a bargain between developers who make their work ‘free’ in return for others making their enhancements free. ‘A derivative work inherits the benefits of the GPL,’ Rosen claims. He prefers to see the power of the GPL as resulting in ‘inheritance’ of benefits rather than diseased infection.

Entering the License Contract

At what point is one contractually bound by taking an open source license? Acceptance of a license is a contractual agreement. To date, case law indicates a licensee accepts the conditions of a software license by opening the shrink-wrap of a program even if the license is not on the box, but inside it.^[76] For programs distributed digitally by some electronic distribution mechanism, the licensee must act in a way that plainly manifests assent in a clickwrap agreement. Mere downloading is not sufficient. Assenting action must be unambiguous. ‘The primary purpose of downloading is to obtain a product, not to assent to an agreement. In contrast, clicking on an icon stating ‘I assent’ has no meaning or purpose other than to indicate such assent.’^[77]

The GPL however indicates a different form of acceptance. Assent occurs ‘by modifying or distributing the Program (or any work based on the Program)’.^[78]

International Issues

As the free software distribution model grows throughout the world legal notions such as ‘jurisdiction’ and ‘choice of law’ will highlight the legal nature of the GPL and its international enforceability. Some of these issues may turn on whether we see the GPL as a license or a contract? To date in this article, these words have been used almost interchangeably. The distinction is important. Contract law is subject to the vagaries of various national approaches. For instance, some legal systems require a contract to be in local language for enforceability. A copyright license enables products to come under intellectual property laws that have been harmonised by international treaties such as the Berne Convention for the Protection of Literary and Artistic Works, WIPO Copyright Treaty (1996) and TRIPS. Along with the principle of national treatment this means that copyright law is (arguably) more widespread and uniform than contract.

Chief counsel for the Free Software Foundation, Eben Moglen, suggests the GPL is a copyright license not a contract. ‘Licenses 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.’^[79] In the only case to consider enforcement of the GPL requirement to publish source code, he made the following claim:

An analogy can be made with land to demonstrate Moglen’s view. I can give you a license to walk on my land. This requires no counter obligation from you. It remains a unilateral permission not a contract. But such a view ignores the obligation to publish source code on a developer wishing to distribute a derivative work based on a GPL product. This obligation makes the license more like a contract.

In Progress Software Corp v MySQL AB, Progress were accused of intentionally distributing a program called Gemini, allegedly a derivative work of the GPL program MySQL, without source code. The case was an application for a preliminary injunction to prevent Progress and its subsidiaries from sublicensing or distributing the program. The finding of the court was an inconclusive outcome for this test of GPL enforceability. ‘With respect to the General Public License (‘GPL’), MySQL has not demonstrated a substantial likelihood of success on the merits or irreparable harm.’^[81] In addition, Progress did comply with its source code publication requirements under the GPL during the course of the dispute and this did much to cure the breach according to the judge.

The license or contract categorisation issue is one point of consideration that needs to be resolved before it is known whether the GPL will be subject to the vagaries of local contract law or remains internationally effective as a copyright license. It will be interesting to see how courts respond to this issue. In Sun Microsystems Inc v Microsoft Corp the Court explained that:

Conclusions

Another commentator argues that the differentiation between license as an intellectual property right and contract is not one that creates conflict. Rather they are ‘two areas of law that have long co-existed and that, at least with respect to one, depend on the other for support in the direction of the goals that are purportedly at the heart of the core legal regime. Copyright and other forms of intellectual property law cannot, and have never been able to, foster active development and distribution of information products in society without relying extensively on contracts’.^[83] The free and open source licenses use this nexus between copyright and contract to create a new paradigm for creation and distribution of digital property.

The remedying of a breach of the GPL is also an evolving issue. Harm and loss, the traditional paradigms of the atom-minded, are difficult to show in communities where egoboo is the principal form of exchange. Other forms of loss have to be argued. What is most sought from any infringer is an equitable remedy to specifically perform by publishing the source code benefits of their changes to the whole community. In addition, misusers of GPL code would be more wary to impugn if they knew that upon a finding for infringement they could be held to account for profits.

The world of digital property is a new world where these issues are yet to be resolved. The following extracts from people in the field highlight problems and solutions that may be considered in the free and open source world.

Seminar Santa Clara University: Views of Open Source Practitioners

Preamble

The following is a revised transcript of a seminar that took place on June 7, 2001 at Santa Clara University Law School in California’s Silicon Valley. The seminar was convened by Professor Brian Fitzgerald and run as a special session of his course on ‘Digital Property’.^[84] It showcased key legal figures in the open source software community and provided invaluable insight into the practical issues facing free and open source software licensing systems in a commercial environment. The seminar was open to members of the Silicon Valley community.

Larry Rosen^[*] – A Legal View From the Open Source Community

1.1.2 Free Software Movement and Open Source

I am not religious about open source. My firm helps clients do both open source and proprietary software licensing. There are many, though, who support free software and open source software with religious fervour. Richard Stallman, for example, the author of the GNU General Public License (GPL), is very religious about free software. He draws distinctions between free software and open source software - I hope I don’t offend anyone here - that is like drawing distinctions between the Presbyterians and the Methodists; for someone like me who is Jewish, I often can’t tell the difference. I also think that most people that are out there dealing with software can’t tell what the difference is between free software and open source software. But people like Richard Stallman really do draw some very, very sharp distinctions. Here’s one way of describing those distinctions. I would call the free software advocates the ‘socialists’ of the software community. (Some people who want to insult them call them Communists,^[85] but that is really just histrionics; ludicrous arguments for asserting that open source and free software means the end of capitalism, as we know it.) Many free software advocates believe that computer software should be freely available to all as a public right.

Free software advocates say that software should be ‘Free as in speech, not as in beer,’ but as a practical matter, when using their approved software licenses like the GPL, they really mean free as in beer too. That is because software that is licensed under such licenses will inevitably be distributed, because of market pressure, at zero price.

The word ‘free’ when applied to software puts software companies in fear of their profits, but that fear is unreasonable. As I will describe in a few minutes, even though the price of software itself tends toward zero under free software licenses, there are still ways to make a healthy profit from ‘free’ software.

So open source advocates decided to change the name of the movement. The term ‘open source’ better conveys the ‘libertarian’ notions of open speech (e.g., publication of source code’) rather than the socialist notions of free software for all at zero price. The leaders of the open source movement created an ‘Open Source Definition’ to identify the required characteristics of licenses that promotes the free availability of source code and the free right to create derivative works therefrom.

At least initially, then, the open source movement grew out of a desire by supporters of free software licenses to come up with a less frightening, and more libertarian-sounding, name for the same thing. But fundamental differences, there still are, between these camps.

All free software licenses meet the Open Source Definition (‘OSD’) and are therefore open source licenses, but the converse is not true: Open source licenses are not necessarily free software licenses. There are many open source licenses that allow licensees to create proprietary derivative works and that don’t also demand licensing terms that inevitably drive the price of software itself toward zero.

The free and open source movement seeks to protect the rights of anyone, anywhere, for any purpose whatsoever, to use, copy, modify and distribute (sell or give away) software licensed under a free or open source license. As a practical matter, this requires free access to the source code.

A key distinguishing characteristic of free software licenses, and of some but not all open source licenses, is what I call the ‘reciprocity’ requirement.^[86] The GPL, for example, requires that any derivative works that are created based upon a GPL-licensed work must in turn be licensed and distributed under the same GPL license. Under such a reciprocal license, if you create a derivative work of an open source program and distribute it, your derivative work is also open source.

1.1.3 Open Source License Key Criteria

The open source leaders, Eric Raymond and his colleagues on the OSI board of directors, are the libertarians of the movement. They really believe that it’s perfectly alright to make money from software. They support the balance struck by Article 1, Section 8 of the United States Constitution, which provides that ‘The Congress shall have Power ... to promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.’ That means to them, however, that software copyrights ought to serve public purposes and not just be a vehicle for making lots of money.

The Open Source Definition (‘OSD’), which is managed by the non-profit corporation Open Source Initiative, defines certain licensing principles. It is a set of standard criteria for open source licenses. If a license meets those standard criteria, and if the license is approved by OSI, then the ‘OSI Certified’ certification mark can be applied to any software distributed under that license. The certification mark gives people a way of knowing that the software that they’re buying is licensed under a license that meets those criteria.

Any license that meets the OSD must provide for free redistribution. That is, someone should be able to take that software and redistribute it for free. While free distribution must be allowed under an OSI-approved license, a license cannot prevent someone for charging for the software, as long as any recipient of a copy retains the right freely to copy and distribute the software, and to use the source code freely to create derivative works. In practice, much software under such licenses will be driven to a zero price.

My 95-year-old mother will do nothing with source code. Having source code available to the average user is of no use whatsoever. But, for other programmers, or for companies that want to take advantage of the source code so that they can fix their own bugs, or when the vendor says, ‘I’ll fix it when I’m ready for it,’ having the source code is a real advantage.

The availability of source code serves the goals of the U.S. Constitution, in its expression of the purpose of copyright laws in the first place. If you can have the source code available you can learn from it. Programmers can learn from each other. They can figure out what other people have done and they can copy it. It’s copyrighted, but you’re free to copy. And, because you can copy, you can make better stuff. You can make derivative works. You can make improvements.

Any OSI-approved license must give the licensee permission to make derivative works. It’s not just ‘give me the source code,’ but ‘give me the opportunity to do something with the source code, to create new things, to make improvements, and then to do what I want with those improvements.’

Some restrictions or requirements on licensee behaviour are compatible with the OSD. For example, a reciprocity provision such as the one I mentioned earlier, says ‘you can make improvements and you can distribute your improvements but you also have to give them back to me.’ An open source license requires creators of derivative works to publish the source code.

Any OSI-approved license can provide for the integrity of the author’s source code: ‘If I write code and put it out there, you can’t take the code and erase my copyright notice. You can’t put your name on it as if you wrote it.’ It is important that people be given credit for what they do because, all these people out there doing all this stuff for free, what are they getting? They’re getting a t-shirt and they’re getting their name out there. They’re getting some sense of pride. Quite frankly some of them work for less than t-shirts. We have to have a way in the license of ensuring that the person who is contributing to the software is able to protect the integrity of his work.^[87]

An OSI-approved license cannot discriminate. You can’t say for example, ‘This software cannot be used for the manufacturing of weapons.’ You can’t say, ‘It can’t be used by the tobacco industry.’ You can’t say, ‘It can’t be used by people of a certain race or colour’ You have to make your software available to everyone for any purpose.

In an important sense, what the open source advocates are trying to do is ensure that software licensing promotes their philosophy about software. It is not a matter of trying to force the price of software to zero. It is not a matter of imposing the religion of open source on everybody. Nobody is forced to distribute his software under an open source license except when a licensee creates and distributes a derivative work of software that is made available under license with a reciprocity requirement. Even that reciprocity condition satisfies the balance required by the U.S. Constitution, in that it gives the original copyright owner the choice of setting the terms and conditions for the privilege to create derivative works. Open source software distribution relies on the copyright laws just as proprietary software distribution does.

1.1.4 Derivative Works

It is important for me as an attorney to care about what my clients care about, which is to create good software, to release it to the public, and to get credit for it and to be part of a community. Then they say they also want to make some money out of it. This creates a tension that I don’t think anyone in the open source movement yet knows how to address completely.

One can make money on open source software by selling services. That is not easy to do, and free competition makes high profits difficult to achieve in the service business. Indeed, it isn’t just the open source companies that are struggling to make money in this way; proprietary software vendors too have implemented the ‘support’ model and attempt to profit from their software by selling services.

In another example, one of my clients has an open source product that is supposed to integrate or allow the inter-working of instant messaging services. My client makes money by creating and distributing proprietary add-ons to his own open source software. They are licensing their client software as open source and their server software as proprietary.

Another kind of tension going on within the open source movement arises when companies try to get control over what is happening to their open source software. Such companies say, ‘Take this software, I give it to you under an open source license,’ but like reluctant game-players, their fingers never leave the ball. They are still latching on. They try to control what kind of derivative works can be created, or whether derivative works can be sold for a profit. Those controls cannot be written into an OSI-approved license.

There are many open source licenses. Which one you use for your software depends critically on your business model. When a client comes to me and says, ‘What license should I use?’ I say, ‘How the hell do I know! What’s your business model? Tell me what you want you want to accomplish. Tell me what you want to get out of your software licensing.’ Then I may point to a license that already exists, if we’re lucky an OSI-approved license. I may copy and modify a license from another company, or write a new one.

Let me just tell you a couple of typical licensing issues in the life of an open source attorney. These issues are things that are interesting to me partly because I don’t have really good answers yet.

I have a client who writes proprietary software and his proprietary software can be used with Samba, an open source program distributed under the GPL. My client’s software doesn’t strictly require Samba, but Samba is one of the programs it links with for certain uses. My client wants to deliver Samba on his CD along with his software. So far that’s easy. Even under a license with a reciprocity provision, like the GPL, it doesn’t affect your program if you merely place the GPL-licensed and proprietary software on the same CD.

But there is a slightly more intimate connection between Samba and my client’s proprietary program. In order to make his program work with Samba, he had to change Samba. So he took Samba and he wrote some new things in it, some little modifications. And then, he has his program (I’ll call it ‘X’ to protect the attorney/client privilege), and he wrote some stuff designed to link between those two programs. The problem is that the GPL says that if you create a derivative work, you have to license your derivative work under the GPL.

Now as a lawyer here’s what I told him. ‘Based upon the way you described your modifications, you have created a derivative work. You have drawn Samba and your changes to Samba functionality in one box on your system diagram. Therefore, under the GPL, you have to publish the source code of your derivative work, and you have to license your modified Samba program under the GPL.’

But what about his proprietary program, X? Since he kept X totally separate from the Samba modifications, I told him ‘this is not a derivative work of Samba, it’s a separate program.’ I have previously argued that if you make changes to a GPL-licensed program, that is statically linked to your program, then you have created a derivative work.^[88] But regardless of the form of linking, if your work is clearly not based, in any way, upon the GPL-licensed program, you have not created a derivative work.

There is as well an open source issue about what is copyrightable subject matter. Suppose you publish a standard, a specification, that tells people how to implement something, and someone reads that specification and goes out and implements it in a program distributed under an open source license. That person sits in a room somewhere and writes code based only upon the published specification. Is what he implements a derivative work of the standard? Is the author of the program subject to license conditions in the license to the specification? Can one have a copyright on a specification?^{[89 ]} Certainly there is no question that one can have a copyright on a printed version of the specification. Anything that you can put down in writing is copyrighted in that sense. But can you have a copyright on the ideas expressed in the copyrighted work? Just the way I phrased it made the answer obvious. An idea is not subject to copyright. But when an idea is expressed in a copyrighted work, and the work is licensed with restrictions on how the idea can be used, can other expressions of the idea be restricted. That would be incompatible with the philosophy of open source and, in the business of open source licensing; there are interesting questions like that. What is the limit of what you can copyright? What is the limit of what you can license legitimately? How do you license it? And, who has the right to be the licensor of an open source work?

Let me give you a third interesting example. I have a client who writes a very, very popular open source program and that program appears on computers all over the world. Lots of people use it. It’s frequently distributed under the GPL with Linux and other operating systems, and I’m going to call it program Y. My developer client found a hardware system, a piece of hardware with a keyboard and a monitor that is sold by a computer company. The hardware has no disc; instead, inside is a flash card and on that flash card is my client’s program.

By integrating my client’s GPL-licensed software on a flash card in hardware with other ‘proprietary software,’ has the hardware manufacturer created a derivative work that must be licensed under the GPL? That proprietary software links to my clients program in some way. Does that mean that all the other software in that box is a derivative work of my client’s software? Or only part of it? What is the implication of hardware being treated as a derivative work of a copyrighted program? Is there a difference between software that comes on a floppy disc or software that comes on a CD or software that is embedded in hardware to the point where it is indistinguishable by consumers from the box itself?

I don’t know the answers to these questions! Now that my client’s software is on that hardware box, can we force those people who created that hardware to obey the GPL and publish their source code? This question has never (yet) been litigated.

1.1.5 Standing to Sue

Also on that box is Linux. And Linux is also licensed under the GPL, so why don’t I just say ‘Listen client, let’s not sue based on your GPL software, let’s get the owners of GPL Linux to sue, lets get a company like Red Hat that distributes Linux to sue to protect their rights, and let them enforce the GPL terms!’ That’s not as easy as it sounds. Who can enforce the GPL? Well, the copyright law is really clear about this. The only one that has the standing to sue in a copyright action in a federal court is the owner of the copyright or the owner of an exclusive right under the copyright law. Who owns the copyright in Linux? The individual owners of each contribution to Linux, each of whom licensed their code under the GPL, can protect their own copyrights, but there is no ‘big Linux’ person with standing to do so. Each contributor owns the copyright to a little piece of Linux, and individually none of them can afford to sue. And a mere distributor of the Linux software, even a company as large as Red Hat, doesn’t have standing to protect the copyrights in Linux software, because it merely has a non-exclusive license (the GPL) to copy and distribute Linux.

My client’s GPL-licensed program, however, the one that I described above, does have clear copyright ownership. I know because I helped the original author register the copyright and formally transfer ownership of an exclusive right to a company that thereby has standing to sue to protect the copyright. That’s essential for him to have standing to enforce the GPL.

Richard Stallman and the proponents of free software would like as much software as possible to be forced into the free software world. So why don’t they expand the reciprocity provisions of the GPL to include ‘collective works,’ not just ‘derivative works?’ Referring back to my earlier example, putting Samba together with program X on the same CD would create a collective work.

Obviously, no licensee would accept software that came with a license provision that forced all software placed on the same disk to be open source; such a change would make the GPL unacceptable.

The boundary lines of ‘derivative works’ in the software world are still uncertain. That makes enforcement of the GPL a tricky proposition. What most often happens is that a ‘cease and desist letter’ works to stop activities that breach terms of the GPL. This isn’t because of the fear of litigation, but the fear of what the other hackers are going to say. So the GPL licensors win their battles without having to go to court. I think that the GPL and the ambiguity of the GPL has served some people well, despite the desire of lawyers like me to find clear and unambiguous answers to the tricky open source licensing questions I’ve identified today.

David Schellhase^[*] – An In-house Lawyer’s Concerns

1.1.6 Open and Closed Software Legal Issues

Proprietary

I want to contrast the worries I have as a lawyer, being from a proprietary software company as compared to an open source company. Lawyers worry a lot about a lot of different things. We let business people worry about making money. We’re worried about keeping money. In a proprietary software company, you have far fewer worries – it’s a closed system in effect. You worry about employees, you worry about customers and you might be worried about some people whose products are infringing. If you’re at the centre of this system, and it’s a relatively closed system, it’s a very closed loop in effect. I’m worried about getting rights from my employees, I’m worried about giving the proper rights that my customers deserve in a license agreement and no more. Basically I understand my universe very well. All these employees have signed a proprietary information agreement or they don’t come to work for us. All the customers are going to sign a license agreement that limits our liability to within acceptable limitations, which gives us some recourse against them if they’re out giving our technology away for free and so forth.

Open Source

In an open source company there’s lots more to worry about. From the open source company view I’ve got not only my employees and not only my customers, but there are dozens, maybe hundreds, maybe thousands of potential owners of intellectual property who are really outside this neat little closed system. Plus, there are hackers who might be contributing to some of my ongoing projects for customers. I’ll just give you one example of technology that the company that I represent has worked with a lot. It’s a technology called Samba that is a file print sharing technology for Linux. It basically turns Linux into Windows NT in effect. Samba was written by a former employee of Linuxcare, but long before he got to the company, so it exists somewhere out there in the ether on samba.org. Many customers, specifically hardware OEM’s (Editor’s Note: Original Equipment Manufacturers) who are interested in proliferating their hardware devices, are interested in Samba because it seems like a cheap alternative to Windows NT. In combination with Linux it seems like a free alternative. But they need to optimise their hardware boxes, so they call Linuxcare and look for us to consult. When that happens I’ve got a huge number of worries. I’m worried about all kinds of potential owners of property. I don’t know what’s in Samba. Samba is a million lines of code. I don’t know where it came from. It pre-dates my company by many years.

The Samba organization hasn’t necessarily said we’re going to give you all the rights that we have from our contributions to the Samba code. And if we’re making new contributions to the Samba code, we may want to give those back to samba.org. We may not want to give them to you, so you can’t give them to your customers. So your customers who are paying good money for the delivery of some kind of code, maybe won’t get the indemnities, limitations, liabilities and warranties they expect from a proprietary software vendor. That’s a big problem, getting big companies, big hardware OEM’s over the hurdle of understanding that they may not get all the nice warm fuzzies. The following table, which was handed out by David Schellhase to the seminar participants, highlights these points.

1.1.7 Employee Problems

Our biggest problem is with the employee base and hackers. The employees don’t want to sign proprietary information agreements. They don’t want to say, ‘You, the company, own every piece of our work product.’ That’s not what they’re interested in. If they were interested in money, they probably would have developed Samba’s proprietary program and would have sold it under a more proprietary licensing scheme. It wouldn’t be GPL’ed. It wouldn’t be out there for free. So they’re motivated by different things. It’s very easy to motivate people who have bought into the capitalist system. It’s very difficult to motivate employees who have a different incentive for coming to work everyday, because we’re just not sure what that is. Corporations in the American capitalist system aren’t set up to reward people with warm fuzzies or whatever else it is that people work for. So, I have got a lot of worries about my employees.

I’ve got to figure out a way to get what Linuxcare needs and to deliver to customers what customers are demanding out of these employees who are out of an organization that exists in the ether and isn’t beholden to anybody. My employees may work for that organization and contribute to it from time to time, but they’re not identified as Samba Inc, it’s Samba.Org. They operate by consensus largely and many of those people involved in that organization don’t work for me, they may not like me.

1.1.8 Hackers

Furthermore, I’m worried about these hackers because Samba is an ongoing project, and there are a lot of hackers out there who are contributing to it. When my employees are on a job for a customer, they may use some of the code developed by these hackers that isn’t yet in the mainline Samba code. They may be using bits and pieces of new stuff and I don’t know where they got it. They may be asking their friends, half a world away or more, to write a few lines of code and give it back to them by email overnight. This happens all the time in this world. That’s a very difficult thing to understand coming from a proprietary world. It’s also very difficult for customers to understand. So the number of worries goes up astronomically, maybe exponentially, as you move from the relatively closed system of the universe that you understand, to the much more open system of the universe that you don’t understand and may not know about. Lawyers obviously fear the unknown, because they can’t control the unknown. There’s a lot more fear and a lot more worry here. The crux of the matter, the relationships with the employees, is critical. Convincing the customers that are not going to get all of the rights that they are used to getting is the other big hurdle. So you’ve got these two big hurdles and lots of ancillary worries along with it. In some respects it’s a daunting challenge and it’s interesting that Bill said it costs more to give your code away. That may very well be. I don’t know of a truly profitable open source company yet and it’s unclear whether there will be one. Linuxcare has raised close to 80 million dollars in venture capital. We’re down to less than 10 million and it’s unclear that expenditure wasn’t just handing our customers a bunch of very steeply discounted consultancy services. That’s not clear, we don’t know.

I’m really more worried about customers. I’m more worried about HP than I am about a hacker in Czechoslovakia. A customer might sue because a piece of code, which we have said is good code, which we have good rights to, wasn’t written by us. So a hacker comes along and says, ‘Oh, I see that HP is incorporating a line of my code. I’m going to go and sue Linuxcare, or I’m going to go and sue HP.’ HP is going to say, ‘Well these guys indemnified me, these guys said they created the code.’ Even if there are no warranties and indemnities in the licenses, try convincing a big multinational hardware company that they don’t deserve the indemnity. Sometimes you just hold your nose and hope.

A more likely scenario is one of our employees found a piece of code and said this is out there under the GPL, or under some other license, and it’s an elegant solution to my little problem which has been vexing me all night, I’m going to take it. A consulting company model like ours gives the rights in what we are doing for the specific customer. You give them the ownership of it. You may retain a license back but typically you give the rights to them, so they feel that they have ownership including copyright and the ability to patent it. So you need to make sure that your getting a full license back. They may actually own that code. This has not been litigated. A number of actions have been settled where, under GPL in particular, a code found its way into a product, and was discovered. Typically what happens is they take the code out or publish their sources and it goes both ways.

I think what you’re seeing in the open source world is some very strange bedfellows. And it’s not clear to me that the marriages are going to last. I think there are some inherent problems between the people who believe in community values versus the sorts of folks who want to use open source software for commercial purposes. I think that there could be a big dust-up, and the dust-up is coming. It may not be a big dust-up; it may be that the two go their separate ways. I think they have had a flirtation, they may have gotten engaged, they may now actually be married, but I don’t think it’s going to be too long before there is a separation and maybe even a divorce. The people who are most interested in open source software are historically the larger corporate hardware vendors. They are interested in ubiquity for their hardware platform, and, for want of a better term, they are software agnostic or operating system agnostic. They love Linux, they love Samba, they love some of the other open source software when it fits their purposes. When it doesn’t, or if it turns out it doesn’t, there will be hell to pay, or they will go back to the closed system that they’re used to.

Don’t get me wrong. There is plenty of risk in both kinds of models as companies are finding out. These other owners of software, people like IBM, have hit up companies, famous companies that you all know the names of, for millions and millions of dollars in patent licensing revenues over the years, and will continue to do so. The whole landscape is fraught with peril, but people continue to do business. It’s not clear to me that the hacker community or the open source community is going to want to continue to do business with the larger hardware vendors when they figure out what the hidden agenda is. And the hidden agenda is that monogamy is great, as long as you know it is with me, and my systems. You know: ‘Don’t cheat on me with HP or IBM or Compaq or anybody else. Stick with me’.

I got a call from a friend of mine the other day who is the CEO at another open source company of fifty people or something and he said: ‘My open source developers are in revolt’. He meant that it is really difficult, because these people tend to march to their own drum. So the answer is, you do it very delicately and I will give you some prime examples. We have gone from 280 employees to 30 by the way. When we had 280 employees, not every one of them had signed our proprietary information agreement. That’s a big problem, and that necessitated some interesting dances with our customers. We have had these issues where we have had to go to customers and say: ‘You know what, we don’t have all the rights you want. You’re going to have to sign a license that doesn’t look anything like your Oracle or Microsoft license. It basically says: ‘You’re going to take a lot of risks with us, and we’ve all got our fingers crossed. We think that these things are OK and we don’t think we are infringing, but we can’t give you ownership rights or a good warranty.’’ That all went back to our handling of relations with employees. We didn’t want to alienate them by forcing them to sign what they viewed as an onerous, burdensome proprietary information agreement that everybody in Silicon Valley sort of signs when they join a company, and forgets about. So the answer is I think people are still confronting it.

Luckily we are a consulting company. We don’t have the problem some of the product guys have, which is: Why should I pay you for something that is available on the web free? That is the Red Hat problem. We don’t have that problem because we are providing bodies and bodies do have a cost. For a senior developer we can still charge $200 an hour. Even though you may not own my product you still get some kind of a license to it, or you get to pick that person’s brain and maybe get your people to code it or something like that. So it’s not a perfect model and it’s really not perfect if you’re a big hardware vendor used to squashing everyone and getting your way.

1.1.9 Patents

I’m less worried about patent infringements. The potential patent owners, the open source developers, are also the ones typically interested in spreading and proliferating open source technology. If we’re talking about a hardware vendor or somebody who is a software vendor, whose application sits on top of Linux or something like that. These guys are much less worried about the hackers because they tend to not have the resources that lead you to worry about patent litigation. I mean that’s a game for rich people. These people tend not to be rich. And they tend to be free about their intellectual property and they’re less likely to bring the patent suits.

If I’ve got huge economic resources, if I’m big enough, they will come calling on me. We will do some kind of cross license because I’ll have some patents too that they’re probably infringing. So I agree in the abstract, it is a huge concern, and it can paralyse you, if you really thing hard about it, because there are so many elements to it. But, I’m not so worried about it on a practical day-to-day basis. Worry about the other stuff.

Being a defendant in a patent infringement case, particularly in software, is a high class problem to have. I’d love to have that problem, because it would probably mean I would have a hundred million more in revenues. It means I’m probably with a profitable successful company…

Yancy Lind^[*] – A Businessperson’s View

1.1.10 Lutris Technologies and Java Application Server

We are in a really interesting transition phase right now where it’s not clear at all if the marriage between corporate America and open source is going to survive. We make this thing called an open source Java application server (JAS). JAS is an important piece of middleware software. If you’re going on the Internet today, you typically don’t go to web sites for very long. Apache is out there, but you quickly get handed off from a web server to a thing called an application server. An application server is what makes the Internet run today, it’s how you get to back-end processes like databases and e-commerce systems. The JAS is the critical battleground right now in the software community. Whoever controls the JAS will control software computing for the next 20 years. That is why in a list of 5 types of licenses put up there by Sun, there is one license that was exceptionally closed compared to the others and that was around Java.^[90] Because Sun realises that the most important piece of technology that they have today is something called Java, and it’s got their most restrictive license around it.

So, what is open source software? The answer is – it is wide open for debate right now. A lot of companies and groups have shared source code and software development over a lot of years and it really has had some wonderful things come out of it. You know TCP/IP is a great example of the early days of this whole idea. The term open source software came out of the Freesoftware Foundation because they realised you could not go around selling free software and have it accepted in corporate America. So they had to come up with a new name and called it open source instead.

There’s really good reasons beyond that. There’s this idea in the open source community that we want to have this freedom of intellectual purity. We want to be able to share ideas, but we don’t necessarily want to be able to rip each other off. So there is this very famous saying in open source that says, ‘Open source is about free speech, not about free beer’. And that means we’re all about sharing ideas, and working together to make things better, we’re not all about giving away money. We still have to figure out how to make money.

We don’t think the GPL is a good license frankly, because of the viral aspect of it. The core issue is ‘Are you interested in satisfying the hacker community or are you interested in somehow making money?’ That’s really what it comes down to in a corporate sense, not as an individual. The GPL in particular applies to this ethic. This whole idea about the hacker community and people who are just individuals out there making sure that they can contribute and that they can be in this large group of alpha geeks. My code is better than yours. I can do that better. There is this whole ethic around that and the GPL is a license that appeals to that ethic.

What is it about open source that really appeals to me as a businessperson? Well, it’s this idea of innovation. It’s just a wonderfully powerful idea. We really do have this large three thousand member development committee who actively work with us and innovate and share ideas with us. We’ve gone off in directions and had wonderful breakthroughs because people were working with us. The lack of a single vendor dependency is just an incredible benefit. Self reliance to fix bugs - companies do like to have the source code. They like to know that their alpha geeks on their staff can get inside that product and do something with it. One of the really big issues in software development is relying on the vendor’s release cycle. What if I have a bug that has to be fixed now and I can’t wait for 3 months for your next release cycle.

1.1.11 Case Studies – Plantronics and General Electric

We go into big companies and build things with them. One was called Plantronics. They are the world leader in headsets. They had us come in and start building a very large e-commerce system for them. They started out using [a major corporation’s product], which is a direct competitor to my product. They started finding some bugs in the product and it didn’t do as advertised. They went through all the traditional kind of mechanisms that the competitor provided such as support groups. Finally there is just a bug and how does it get fixed? They call up the competitor.

So they threw out the competitor’s software and Lutris came to the rescue. We were able to show them the power of having access to the source code. Use our application server versus that application server and if you have a bug in it we will fix it for you right there, or you can fix it. Whatever the case, there is the code. Here’s all the build utilities, all the make files, all this kind of stuff – just go!

I’ll give you another example. GE is one of the largest companies in terms of market capital in the world today. Their largest division is the home appliance division. They make things like washing machines. They recently threw out [a rival company’s] application server in favour of my product. They did that for a very similar reason as Plantronix. One of the great things about Java is that it can be decompiled. [Editor’s Note: a decompiler takes executable code of a program and turns it into source code]. That means that people like Sun don’t like that, but developers love it, because you can still get access to the source code. So what happened was GE found a bug in the rival’s application server. They wouldn’t fix it, wouldn’t give them any time of day. So internal IT guys at GE decompiled the application server, found the bug and sent the fix back to our rival company. They said ‘How neat, we’ll get that into our next patch release!’! And, GE said, ‘That’s great’ and ripped it up and put our stuff in.

Two very powerful real world examples of why open source software is a wonderful, wonderful tool. True value to customers. Value you could never get from a closed source product. From a businessman’s perspective I have got a product that competes with the giants of this industry who have hundreds of engineers working on these products. I have forty. My product many consider to be superior with a fraction of the engineering costs. So, just from a pure return-on-investment perspective, open source is something I can leverage massively to give me a real economic advantage.

1.1.12 Commercial Viability of Open Source

So, open source is a great thing. Is it working? The answer is yes and no. Unfortunately there is a no to it. It was only three years ago that open source software really came on the scene from a mass consciousness kind of perspective. They’re talking about it because of the fact that there is a wonderful PR angle. There is this David versus Goliath angle going on with Red Hat versus Microsoft. Three years ago Red Hat had not gone public yet and there was this thing called Linux. And there was this great article out there called The Cathedral and the Bazaar.^[91] Press people were drooling over this stuff. And suddenly open source software burst on the consciousness.

A lot has happened in the last three years. Open source software has moved out of the fringes and is the main stream today. There is no doubt about it. Open source software has absolutely proven itself as an extremely powerful software development methodology. The best application server in the world is mine. And it’s open source software. The best web server in the world is Apache, there’s no doubt about it. It’s open source software. Many people would consider Linux to be the best operating system in certain niches. It’s open source software (OSS). It’s clear that OSS has proven itself as a software development methodology.

But it’s not at all clear if there will ever be a successful stand alone software company using open source. Because, the only way it looks like you can make money off OSS is by packaging it with something else. It’s a great way of maintaining margins for existing products. Hardware companies love OSS because they can maintain price. The number one problem that hardware companies have today is maintaining margins. That’s it! And you can only manufacture your margins for so long before you just get to a certain point where you can no longer squeeze another penny out of your manufacturer. So you have to bundle stuff in and open source software is great for that.

So, some examples as to why hardware companies love this, or some proof of this. IBM this year is putting one billion dollars into OSS. A lot of money right? But, for them, not that much. It’s a way to harvest out of the OS community, package that stuff into their hardware, and be able to maintain their pricing of their hardware, maintain their margins. Hewlett Packard have stated publicly that Linux will be their only operating system within 5 years. HP-UX will be gone. They won’t be selling any Microsoft products. It’s an amazing statement, unbelievable. Compaq right now is the number one Linux platform in the world. And even Sun is making some moves towards OSS. Everyone is moving there.

But OSS has not created any viable stand-alone software companies. There is not a single example of success. Lots of failed struggling companies. Anyone in this space right now is hurting big. And it’s not clear if it will ever be profitable. And at the end of the day, if it completely collapses, we’re going to be back to the good old business model that I used to have to worry about which is profitability. There’s not a single OSS company that’s anywhere close to being profitable.

It’s an interesting time to watch what’s going on here, because what we are seeing is these huge computer companies saying: ‘OS is the future’, but software companies struggling with how we’re going to make it. My company included. And, the other interesting part is if you look at most of the OSS projects out there today – they’re not alpha geeks - they are actually employees of big companies, making it happen. Most of the developers who work on Apache today work for either Sun or IBM. That’s just the truth, most of the developers who work on Apache today are doing it because a large hardware company has an economic interest in seeing Apache succeed.

Bill Lard^[*], Senior Director of Licensing Strategy and Architecture at Sun Microsystems

1.1.13 Introduction

This section of the transcript looks at a Sun public license that does not have OSI approval and is called a ‘community’ license – Sun Community Source License (SCSL) Version 2.3. This is not to be confused with the Sun license that does have OSI approval as shown in section 2.5 of this article. Sun has slightly different SCSL’s for each product. The license considered for this article relates to their Java 2 Platform that provides ‘Write once run anywhere’ capability for applications developers.^[92]

a) requires developers to become a community member by entering into the license;

b) under research use rights, limits distribution of source code of the original contributor to other community members;

c) requires licensing back to Sun of source code for ‘Error Corrections’ ‘as soon as practicable’;

d) allows distribution of fully compatible, object code to third parties as part of a value-added product under a license of their choice, consistent with the SCSL once Sun and the licensee have signed a ‘commercial use’ attachment; and

e) compatibility of licensee implementations must be determined by use of the Technology Compatibility Kit supplied by Sun.

1.1.14 Serial Licenses

An important consideration not really legally tested today is that true open source licenses are entered into serially. You can receive source code in a chain that was originated by someone 100 people before you, so privity of contract starts to wither away. Now the GPL supporters believe that anyone who makes a contribution to an open source bundle who has copyrights, and has retained those copyrights, also retains the right to sue on copyright infringement based on the copyrighted code in that bundle. So if you download some code that’s got 1000 contributors and you utilise it in a way that’s inconsistent with the license, you’ve got a potential claim by any one of 1000 people for copyright infringement and possibly breach of contract. But like I say, it’s not tested, so we don’t know whether the courts would find standing for an early contributor whose contribution had been substantially diluted over time.

1.1.15 Viral Nature and Inheritance

The Linux operating system is available under a combination of GPL and LGPL and the distinction here is really important. They require you to license your technology back, under the very same license, not just any old license. You may have heard of the viral impact of GPL code. The Free Software Foundation prefers to use another term, ‘inheritance’. To put this in context, Sun has a proprietary operating system called Solaris. It’s our Unix environment that we use for all of our products and everything we ship is based on it. It comes from a very long heritage of technology that was developed in Berkley and AT&T and then after a while it was licensed under a proprietary license by Unix Systems Laboratories, a subsidiary of AT&T. Over the years the Solaris code base has acquired a substantial amount of third party technology that had confidentiality requirements and a variety of other restrictions. That technology cannot be, in whole, made available under an open source license because of this contractual baggage. If we were to take GPL code and integrate that with Solaris, there are circumstances where we could wind up with an obligation to open source the Solaris code base under the GPL. It could create a situation where we’re either in breach of the GPL or in breach of contract with a bunch of folks that had contributed to the Solaris code base over many years. So this is a really critical concern if you’re going to use technology that’s licensed under either GPL or LGPL.

I might mention that the LGPL code was designed to provide for interaction with proprietary software, but primarily for libraries. It was designed to do that where the free software community wanted to make sure that their libraries were used because there was more benefit to having even the proprietary guys use them, and make them standard, than to hold back and try to force people to have their code become open. That’s an important distinction and it’s also being used now in a way that I think is very interesting. If you want to take GPL code and use it in some way in conjunction with proprietary code, you may be able to do so if you use LGPL code as an abstraction layer between your proprietary code and the GPL code. It’s important that the GPL code is dependent on the LGPL code and not the other way around. Otherwise, the LGPL code may be converted to GPL code and your proprietary code may be affected as well.

1.1.16 Sun Community Source License: A Non-OSI Approved ‘Public’ License

So here’s the one the open community guys have given us a hard time about - The Sun Community Source License. It is a public source license, but not an open source license. It provides technologies that were developed at Sun in conjunction with many of our industry friends. It makes the code available publicly, but under a different licensing model. The reason the community license is used is because the number one value proposition behind Java technology is compatibility, ‘Write Once, Run Anywhere’. You can write an application once, and it will run on any Java platform regardless of the microprocessor and operating system if it’s a compatible implementation of Java. In order for that to work we need to make sure that people do not fork the code^[93] and create non-compatible implementations and take it off in a different direction. That being said, in the industry, even in the open source world, people tend to manage compatibility very well. If you look at Linux, there are six flavours of Linux, but they’re not that different in flavour. The difference here is that the community developing Linux has an incentive to have a compatible set of implementations of the Linux operating systems so all Linux applications will run on any of them.

In the case of Java, there is at least one company that would prefer to see one platform rather than applications that run on all platforms. They have the ability to basically take the developer base and move them away from what would otherwise be applications development for a broad set of microprocessor and operating system platforms. You can’t just say we’ll trust the world to make sure this doesn’t happen. So as a result of that, we do a few specific things. One is, we have a public source license. So if you want to get Java technology you have to go to the website, click on the license and accept it, and that puts you in privity of contract directly with Sun. That takes care of many concerns about enforceability and standing.

There are a couple of other things that are important about the community license. It’s not fully open to the world. We only allow downloads to countries where we are comfortable that intellectual property protection and enforcement is reasonable. There are about 50 countries on the list. The rest of them currently are not available to download. Granted, you can take that technology, download it to the UK and get in your car and drive to Libya, well with difficulty, but I mean, you could do that, so there are those that would argue that we’re not protecting much. Nonetheless, we think it’s important to limit distribution to those areas where we know Sun will be able to enforce the license requirements. So that’s basically the Community License.

1.1.17 Issues in Public Licenses

So why a public license? I mean what in the world would possess someone to give away technology? In the 70’s where developers at universities were basically using their operating systems as their research base, if someone working on code had a problem with it, finds a bug, or it locks up, if they leave for the day and are the only one that has access to the source code, the guy that comes in and wants to work in the evening can’t use the system because it’s got a problem. If you make the source code available to all the researchers that are running on that server, and someone has a problem during the evening, they can go in and fix the bug, if they’re competent to do so. So this evolved into group development in a relatively closed way, that grew to be much more worldwide over time, particularly with the Internet. Starting in ‘92 with Linux in particular, but from ‘95 on, when the worldwide web became the vehicle for getting access to the Internet, the amount of people exchanging code in development just exploded worldwide. That’s why you’ve got so many thousands of developers today that are working with Linux. So, encouraging community contribution is one of the key things, and the idea there is that innovation always happens elsewhere. If you only rely on your 10 or 15 or 100 employee engineers to develop technology, you’re not going to get the benefit of the other thousands that are out there that might be willing to participate in your program if the circumstances are appropriate. What are appropriate circumstances? Have you set up the right cultural environment for the community? Have you provided the right incentives for developers to participate and get benefit from actually developing in that community?

Standards are another really important area. If you want to get technology out there and have it adopted as a standard, having the source code available to people so they can get access to it and use it, is a very good way to go. Again, you still need to be able to interact with the community and invest the time and money to make that community work; otherwise, it’s not likely to happen. We’ve got a number of projects that are out there today, in file sharing, and transfer of files over the Internet. We want very much to make sure they stay open standards – and we’re willing to make the code available to assist in that happening.

Generating revenue – now this is primarily with the community license, because we reserve the right to charge people royalties for distributing products that integrate our code. That is not something that you see with open source in terms of distribution of the source code itself. The open source guys can charge for distribution of binaries, but they primarily look to other means to generate revenue. For example, the Red Hats of the world provide both support and professional services intended to generate revenue. Whether that model is scalable remains to be seen.

Capturing developer mind share is another important issue. Sun has a number of platforms where we want to encourage developers to write applications. Having access to source code is very helpful to be able to debug programs and to write better applications, because if you can actually see how the operating system works, your applications can take advantage of that. So, we have a number of programs to make technology available for that purpose.

Also, Governments – actually there’s a lot of discussion right now about whether various Governments are going to require that only open source be available. The Government of Denmark has actually been looking at that. They’ve got Microsoft terrified right now because they’re suggesting that maybe they should just only use open source technologies for their operating systems, rather than the closed environment that Microsoft sells. Well, not a great idea if you think about it. If you only allow people with open source to sell to the Government, you’re going to have most of the proprietary systems that are around here today, not being used by the Government. I mean, certainly we couldn’t do it, because Solaris is not open, can’t be, at least not today. Microsoft couldn’t do it. Same thing with HP and IBM – although I imagine some of their systems can be delivered on Linux. But, its not always a bad idea, Governments often require access to source, usually in escrow. Sometimes it’s easier to just do an open source arrangement for them and make sure they have access to it that way.

Goodwill is another possible goal - simply making the code available because you’re not using it. At Sun, and many companies like us, we have lots of projects. Sometimes we have projects that are focusing on very similar things at the same time and one will win and one won’t. So the one that wins goes off and becomes a product someday. The people that worked on the one that didn’t are thinking, ‘I put a few years into this thing and look what’s happened – maybe we should give it to the world’. That might be the right thing to do in some circumstances, but there are costs associated with doing that. There’s a lot of hidden costs associated with properly handing code off publicly, so you really have to weigh the benefit of making it available for free, versus the costs associated with it. There is a lot of code scrubbing that has to be done to be sure that it is suitable for public consumption.

1.1.18 Posting Code

So what about the actual process of posting source code publicly? Once you make the decision that you want to do it, how is it actually done? What should we be concerned about?

From a public perspective, make sure the code is of reasonable quality and useful to your target audience. You don’t want to throw your garbage in the street as it were; it’s considered to be bad form. For the most part, if you just have a project that died and you just want to get the code out there, to say ‘Gee what a nice thing I did,’ it probably won’t work. You also have to make sure there aren’t any inappropriate comments in the code, because when a programmer’s up in the middle of the night, irritated about something, casting aspersions on Bill Gates in code comments is not the thing you want to see out there the next day. So you go and do research, do scripts that look for key words or peoples’ names, foul language, what have you. You can also do a script to search for third party copyright notices. If we didn’t realise we had some code from a third party, making it publicly available suddenly makes it known that you did, and you have potential liability. So it’s good to make sure that the least you have done is a reasonable search for third party stuff.

Programmers may or may not realise they have developed patentable inventions in their code. Also, the code may read on patents you already have filed and have issued that are sitting in your patent portfolio. So we need to take a look, check with the patent database and look for anything that might be affected by publishing the code. If anything is patentable, you have to decide if you want to file on it before making it available to the public.

If you intend to encourage community development, you have to provide incentive for people who are not into monetary rewards to hack the code and post their contributions. It usually has more to do with things like the personal satisfaction of having provided a really cool piece of code and see others actually use it.

So you got the code out there, its clean, looks good, you’ve got a community working and people are actually providing contributions back. What do you do about that? If you went out under a Berkley style of license then if people are providing code back there’s not a mechanism to dictate the license terms under which you receive it. For example, the Apache foundation using a BSD style of license also requires a contributor agreement for major contributions to their code base. So if you want to provide code, you need to sign an agreement that says, ‘I own the copyright, I wrote this myself, my employer doesn’t have copyright under my employee agreement, and if I know of any encumbrances in terms of other intellectual property that might require a license, I will tell you so that you can decide whether to take it or not.’ This is a very key concern because if you allow code to come in and you don’t know where it came from you can’t be certain if the full rights are there.

1.1.19 Posting under GPL

If you put code out under GPL, someone can take that code and make modifications to it but it triggers an obligation to make their modifications available under the same license. If you want to create a community under GPL where people are going to provide code back, then it all has to be GPL code. So if you have in mind to do something else in addition to GPL then you need to have ownership in that technology because the owner of the copyrighted code has the right to do what they wish with it. They still have the obligation to license under GPL if the code was derived from GPL code, but they have the right to license it under other license terms as well. Hackers often license the same technology under a GPL and a proprietary license so they can charge for the proprietary version. If you have GPL stuff out there people are not too excited about going and getting it, especially commercial entities, so you can say, ‘By the way, I can license you a propriety version as well and it will only be $100,000, great!’ That’s one way open source developers make their money.

1.1.20 Employees

We’re actually working on a program that would allow for variations on our employee agreements because we have probably fifty employees that are contributing to Mozilla and other projects. We have a ton of other employees doing Linux work and a variety of other things including Gnome.org. Those are all projects sponsored by Sun in some way or another. We can sanction that, but we also encourage our employees as individuals to participate in research programs, because we think it’s a good thing to do. The difficulty is if I’m in the server group and I do web servers for Sun-iPlanet and I’m busy throwing stuff over the wall to Apache, that’s probably a problem because if you read the employment agreement even with the California labour code requirements there’s a conflict. So what we’re looking at is providing in advance a waiver to that requirement for employees who want to participate on a particular program. It would be for whatever period of time that they want to do it. But it wouldn’t be for any open source project there is. What we are grappling with is how to weave this process into Sun’s conflict of interest policy.

1.1.21 Downloads

So downloads. This is where you bring open source code back in house. What are the issues? Where did it come from? Did the people that contributed knowingly or not knowingly provide code that was infringing others’ rights? That’s a hard thing to know. You can do a contributor agreement and get some kind of commitment that they had a right to license it.

Looking at who created the technology itself is helpful. If it’s well known developers who have been working in the community for a long time, it’s likely there would be a reasonable level of comfort that they have the right to provide the code. Pride of authorship is important to these developers. If the product that you actually put the technology into is critical to your business, and you are unable to ship it due to an injunction, then you think twice about what technology goes in and who wrote it. You don’t want to compound the problem by having the potential for copyright claims that come in from code that was improperly provided. I have seen through our own processes where a list of copyrights and a license associated with a specific technology turned out not to cover all of the included code. On further examination we found references to the Free Software Foundation, which means GPL licensing terms. Under the circumstances, we couldn’t use the code as planned. So a very careful examination of the technology is really critical.

1.1.22 Conclusions

What this all means to Sun, as a corporation is that there is a place for public licensing. No question about it, we use it and encourage it, we support a lot of programs, and we get a lot of benefit from it. You have to choose your license wisely, whether you’re licensing out, or bringing technology in. You need to weigh your liabilities. People think that it’s cheaper to go and get code off the web and use it in their products. Sometimes that’s not so because of your attached liabilities. Also creating an open source development program to have the community develop the code for you may seem a lot less expensive, but often it costs more to do that, than it does to develop it yourself. You need to have other reasons to do the open source, so that you get the benefit of going out there and bringing in technology.

Acknowledgements

I would like to thank Bill Lard, Larry Rosen, David Schellhase, Yancy Lind, Graham Bassett, Anne Fitzgerald, Carl Middlehurst and the Law School at Santa Clara University for their generous assistance with this project.

^[*] Professor Brian Fitzgerald BA (Griff) LLB (Hons) (QUT) BCL (Oxon.) LLM (Harv.) is Head of the School of Law at Queensland University of Technology, Brisbane, Australia. Brian holds postgraduate law degrees from Oxford University and Harvard University. He is co-editor of one of Australia's leading texts on E Commerce, Software and the Internet - Going Digital 2000 - and has published articles on Law and the Internet, Technology Law and Intellectual Property Law in Australia, the United States, Europe and Japan. His latest publication (with his sister Anne Fitzgerald) is Cyberlaw: Cases and Materials on the Internet, Digital Intellectual Property and Electronic Commerce (2002). Over the past three years Brian has delivered seminars on information technology and intellectual property law in Australia, New Zealand, USA, Canada, Norway and the Netherlands. In October 1999 Brian delivered the Seventh Annual Tenzer Lecture - Software as Discourse: The Power of Intellectual Property in Digital Architecture - at Cardozo Law School, Yeshiva University in New York. In October 2000 he was invited as a part of the Distinguished Speaker series hosted by the Ontario wide Centre for Innovation Law and Policy to deliver an address on Digital Property at the University of Western Ontario Law School in London, Canada. During the first half of 2001 he was a Visiting Professor at Santa Clara University Law School in Silicon Valley USA, teaching a seminar on Digital Property www.scu.edu/law/FacWebPage/Fitzgerald In March 2001 he convened a forum on ‘Innovation, Software, and Reverse Engineering: Technological and Legal Issues’ and in June 2001 he organised a seminar on ‘Legal and Business Issues Relating to Open Source Software’ both held at Santa Clara University in Silicon Valley. From 1998-2001 Brian was Head of the School of Law and Justice at Southern Cross University in NSW.

^[**] Graham Bassett is a Research Associate at QUT Law School. Until 2000, Graham developed information technology systems in private schools in Sydney. He is completing a Law degree and has worked as a Research Assistant for Professor Brian Fitzgerald in the area of free and open source code software licensing.

^[1] B. Fitzgerald, ‘Digital Property: The Ultimate Boundary?’ (2001) 7 Roger Williams University Law Review 47; B. Fitzgerald and A. Fitzgerald, Cyberlaw: Laws Relating to the Internet, Digital Intellectual Property and E Commerce (2002) Lexis Butterworths, Sydney Australia; A. Fitzgerald, B. Fitzgerald, C Cifuentes and P Cook (eds.) Going Digital 2000: Legal Issues for Electronic Commerce, Multimedia and the Internet (2000) Prospect Publishing, Sydney.

^[2] Software has been protected as a literary work under the US Copyright Act since 1980: Lotus Development Corporation v Borland International Inc [1995] USCA11 37; 49 F. 3d 807 (1st Cir. 1995), and under the Australian Copyright Act since 1984: Data Access Corporation v Powerflex Services Pty Ltd [1999] HCA 49. Article 10(1) of the Agreement on Trade-Related Aspects of Intellectual Property Rights (TRIPS) Agreement, part of the World Trade Organisation Agreement of 1994 and binding on all members of the World Trade Organisation (WTO) provides that: ‘Computer programs, whether in source or object code, shall be protected as literary works under the Berne Convention (1971).’ More recently software has been subject to a vast amount of patenting throughout the world: Welcome Real-Time SA v Catuity Inc [2001] FCA 445 (Australia); State Street Bank & Trust Co v Signature Financial Group Inc 149 F. 3d. 1368 (Fed. Cir. 1998) (USA).

^[3] Microsoft Open License Agreement v 6.0, October 1, 2001, para [1] – applicable from July 1, 2002.

^[4] State of New York v Microsoft Corporation, Direct Testimony of Bill Gates, April 18 2002. [http://www.microsoft.com/presspass/trial/mswitness/2002/billgates/billgates.asp], para [307] April 20 2002.

^[7] B. Fitzgerald, C. Cifuentes, A. Fitzgerald and M. Lehmann, ‘Innovation, Software and Reverse Engineering’ (2001) 18 Santa Clara Computer An High Technology Law Journal 121; B. Fitzgerald ‘Intellectual Property Rights in Digital Architecture (including Software): The Question of Digital Diversity?’ [2001] EIPR 121.

^[8] Note 7, pp143-144. For example in Australia, under s47D of the Copyright Amendment (Computer Programs) Act 1999, the owner or licensee of a program is permitted to reproduce a program (under certain conditions) in order to engage in reverse engineering for the purpose of achieving interoperability, and this right cannot be negatived or overridden by contract. However, this right is granted on the basis that the reverse engineering is undertaken to facilitate interoperability required by the owner or licensee of the program. In US law, reverse engineering for interoperability is allowed in certain cases under the fair use doctrine provided for in s 107 Copyright Act 1976: see Sony v Connectix [2000] USCA9 80; 203 F. 3d 596 (9th Circ 2000), and s1201 (f) Digital Millennium Copyright Act (DMCA) 1998.

^[13] A NZ company has made a formal complaint about the impact of this new ‘software-as-service’ paradigm. See ‘Complaint to the Commerce Commission by Infraserv Limited as to certain anti-competitive behaviour of Microsoft NZ Limited’, [www.clendons.co.nz], May 09 2002.

^[17] For a brief overview of the development of GNU/Linux see section 1.2.1 of this paper.

^[18] In two leaked memos Microsoft admitted to the benefits of non-proprietorial development methods at Linux and proffered whether such development could be slowed by court challenges: Bob Trott, ‘Microsoft Pondering Legal Challenge to Linux’, CNN.com, November 1998, <http://www.cnn.com/TECH/computing/9811/06/linux.threat.idg/> (November 22, 2001).

^[22] Patrick K Bobko, ‘Open-Source Software and the Demise of Copyright’ (2001) 27 Rutgers Computer & Tech. L.J. 51 at [79].

^[24] Lawrence Lessig, The Future of Ideas: The Fate of the Commons in a Connected World (2001) Random House, NY, p50.

^[25] For an article overviewing international legal efforts to utilise open source code see: Paul Festa, ‘Governments push open-source software’, CNET News.com, August 29 2001, [http://news.com.com/2100-1001-272299.html?legacy] 19 July 2002.

^[26] Carolyn A. Kenwood, ‘ A Business Case Study of Open Source Software’, The MITRE Corporation, July 2001, http://www.mitre.org/support/papers/tech_papers_01/

^[27] Tiffany Kary, ‘Taiwan opens door to open source’, ZDNet News, June 4, 2002 [http://zdnet.com.com/2100-1104-931885.html] 19 July 2002.

^[30] Thomas C Greene, ‘MS in Peruvian open-source nightmare’, June 5 2002, [http://www.theregister.co.uk/content/4/25157.html] 17 July 2002.

^[32] David Bollier, ‘The Power of Openness, Why Citizens, Education, Government and Business Should Care about the Coming Revolution in OpenSource Code Software: A Critique and A proposal for the H20 project’, paper for the Berkman Center for Internet and Society, Harvard University, March 10 1999, <http://eon.law.harvard.edu/opencode/h20/> , (23 July 2001); B. Fitzgerald, ‘Software as Discourse: The Power of Intellectual Property in Digital Architecture’ (2000) 18 Cardozo Journal of Arts and Entertainment Law Journal 337.

^[33] Stallman Richard M, ‘Free Software: Freedom and Cooperation’, Speech at New York University, New York, 29 May 2001, <http://www.gnu.org/events/rms-nyu-2001-transcript.txt> , (August 27 2001). On the power of free software models to enhance digital diversity consider: B Fitzgerald, ‘Intellectual Property Rights in Digital Architecture (including Software): The Question of Digital Diversity?’ [2001] EIPR 121; B. Fitzgerald, ‘Software as Discourse: The Power of Intellectual Property in Digital Architecture’ (2000) 18 Cardozo Journal of Arts and Entertainment Law Journal 337.

^[36] For the enhanced power code writers have in the cyberspatial intellectual commons see: Lawrence Lessig, ‘Symposium: Key Address: Commons and Code’ (1999) 9 Fordham I. P., Media & Ent. L.J 405 at [410].

^[38] Note 33 The history of this connection is best covered in the book by Sam Williams mentioned in Note 39.

^[39] For a detailed overview of the history of GNU/Linux see: G. Moody, Rebel Code: Linux and the Open Source Revolution, (2001) Penguin Books, NY, USA. See also: Lawrence Lessig, The Future of Ideas: The Fate of the Commons in a Connected World (2001) Random House, NY, p50ff.; Sam Williams, Free as in Freedom: Richard Stallman’s Crusade for Free Software (2002) O‘Reilly, Chapter 11.

^[44] These include loss leader; widget frosting; give away recipe/open restaurant; accessorizing; free the future, sell the present; free the software, sell the brand; free the software, sell the content. Potter Shane W, ‘Opening UP to Open Source’ (2000) 6 Rich. J.L &Tech 24.

^[49] For more on the differences between GPL free software and open source see: Joe Barr, ‘Live and let license’ ITworld.com, 23 May 2001, [http://www.itworld.com/AppDev/350/LWD010523vcontrol4/]; Larry Rosen, ‘Which open source license should I use for my software?’ [http://www.rosenlaw.com/html/GL5.pdf].

^[56] www.opensource.org/licenses/mozilla1.0.html.

^[57] GPL, Note 41, Clause 0. Nonetheless there still appears to be some uncertainty as to what this means and as to whether this is the only type of derivative work contemplated by the GPL. Is any work that employs GPL’d code regardless of whether it would be a derivative work under US copyright law – a derivative work in the eyes of the GPL?

^[58] Australian copyright legislation does not use the term ‘derivative works’. A copyright holder has the exclusive right to make adaptations of a work under ss31 (1) (a) (vi) of the Australian Copyright Act 1968. For software purposes, an adaptation is a ‘version of the work (whether or not in the language, code or notation in which the work was originally expressed) not being a reproduction of the work’: s 10 Copyright Act 1968. See also B Sookman, Computer, Internet and Electronic Commerce Law (1991) Carswell Canada 3-210; Vault Corp v Quaid Software Ltd [1988] USCA5 922; 847 F.2d. 255 (5^th Cir. 1988) Under s 31 (1) (a) (i) Copyright Act 1968 it is unlawful to reproduce the whole or a substantial part of a work without permission of the copyright owner : s 14 (1) Copyright Act 1968; Data Access Corporation v Powerflex Services Pty Ltd [1999] HCA 49.

^[59] Copyright Act, US 17 USC § 101.

^[60] Note 59, § 106(2).

^[61] Note 59, § 103(a).

^[62] Note 59, § 103(b).

^[63] Note 59, § 103(a). Contrast the Australian position: A-One Accessory Imports Pty Ltd v Off Roads Imports Pty Ltd (No 2) (1996) 34 IPR 332; S. Ricketson, The Law of Intellectual Property 2nd ed. Volume 1 (1999) Law Book Co., Sydney, 116-120.

^[64] Note 59, § 103(a).

^[65] Ibid. A further issue is the extent to which the unlawful user prevents copyright arising in any part of the later work: M. Nimmer and D. Nimmer, Nimmer on Copyright Lexis Nexis, Chapter 3. Cf. the Australian law: A-One Accessory Imports Pty Ltd v Off Roads Imports Pty Ltd (No 2) (1996) 34 IPR 332, which suggests copyright can be claimed and protected in an adaptation unlawfully embodying a pre-existing work. This may impact on the legal significance of the GPL under Australian law.

^[66] See further: S. McJohn, ‘The Paradoxes of Free Software’ (2000) 9 Geo. Mason L. Rev. 25.

^[67] See further Uniform Computer Information Transaction Act (UCITA) s308(1) & (2). Updated August 10 2001, <http://www.ucitaonline.com/ucita.html> , (November 23 2001). UCITA is a model law promulgated for adoption by the US states which creates a 'sale of goods' styled regime for the licensing of software and other informational transactions. It is argued that the process of transacting software and other informational products is not adequately covered by existing sale of goods type legislation, which finds it hard to classify software. In the case law software is sometimes classified as a good and sometimes as a service; leading commentators to label software the digital chameleon. UCITA aims to avoid this debate by creating a sui generis regime governing the formation, performance and termination of information transactions. It has been highly controversial in its content and has only been adopted by two US states: Maryland and Virginia, http://www.nccusl.org/uniformacts-subjectmatter.htm.

^[68] Litchfield v Spielberg 736 F. 2d. 1352, para [1357] (9^th Cir. 1984).

^[69] Tiffany Design Inc v Reno-Tahoe Specialty Inc 55 F. Supp 2d. 1113, para [1121] (Dist. Nevada 1999).

^[70] Lewis Galoob Toys Inc v Nintendo of Am. Inc [1992] USCA9 2282; 964 F. 2d 965 (9^th Cir. 1992).

^[71] Micro Star v FormGen 154 F. 3d. 1107 (9^th Cir. 1998).

^[72] L Loren ‘The Changing Nature of Derivative Works in the Face of New Technologies’ (2000) 4 J. Small & Emerging Bus. L., 57, para [84].

^[73] Amy Cohen ‘When Does a Work Infringe the Derivative Works Right of a Copyright Owner?’ (1999) 17 Cardozo Arts & Ent L. J 623, para [657].

^[74] GPL, Note 41, Clause 2.

^[75] Rosen Larry, ‘The Unreasonable Fear of Infection’, RosenLaw.Com, [http://www.rosenlaw.com/html/GPL.PDF], (23 September 2001).

^[76] The decision of ProCD, Inc v Zeidenberg 86 F.3d 1447 (7th Cir. 1996) held that shrink-wrap, and arguably click-wrap, licences are enforceable in the USA in certain circumstances: Hotmail Corporation v Van Money Pie Inc 47 U.S.P.Q. 2d. 1020 (N.D. Cal. 1998); Register.com v Verio Inc. 126 F. Supp. 2d 238 (S.D.N.Y. 2001); Lemley, Menell, Merges and Samuelson Software and Internet Law (2000) 494-5. See also Hill v Gateway 2000 Inc 105 F. 3d 1147 (7th Cir. 1997) NBA v. Motorola, Inc. [1997] USCA2 86; 105 F.3d 841 41 U.S.P.Q.2d (BNA) 1585 (2d Cir. N.Y. 1997); cf. Wrench LLC v. Taco Bell Corp.51 F. Supp. 2d 840 (W.D. Mich. 1999), Klocek v. Gateway, Inc. 104 F. Supp. 2d 1332 (D. Kan. 2000). Lemley et al suggest that the weight of this decision should not be overstated as it goes against the majority of judicial opinion on the issue: Lemley, Menell, Merges and Samuelson Software and Internet Law (2000) pp 490-3; see also B Sookman, Computer, Internet and Electronic Commerce Law (1991) Carswell Canada 2-71 ff. Nevertheless the rationale of ProCD has been codified in ss 208-9 Uniform Computer Information Transactions Act (UCITA).

^[77] Specht v. Netscape Communs. Corp 2001 U.S. Dist. LEXIS 9073 at [26] per Hellerstein USDJ.

^[78] GPL, Note 41, Clause 5.

^[79] Eben Moglen, ‘Free Software Matters: Enforcing the GPL, I’, August 12 2001, [http://emoglen.law.columbia.edu/publications/lu-12.html] January 25, 2002. See also: B Fitzgerald, ‘Digital Property: The Ultimate Boundary?’ (2001) 7 Roger Williams University Law Review 237; B Fitzgerald, ‘Commodifying and Transacting Informational Products Through Contractual Licences: The Challenge for Informational Constitutionalism’ in CEF Rickett and GW Austin (eds), Intellectual Property and the Common Law World, Oxford, Hart Pub, 2000, 35.

^[80] Progress Software Corp. v. MySQL AB 2002 U.S. Dist. LEXIS 5757. The ‘Declaration of Eben Moglen in support of defendant’s motion for a preliminary injunction on its counterclaims’ made on February 22 2002 is found at: [http://www.fsf.org/press/mysql-affidavit.html] May 08 2002.

^[81] Note 80, para [2].

^[82] [1999] USCA9 438; 188 F. 3d 1115 at 1121 (9th Circ, 1999).

^[83] Raymond Nimmer, ‘Breaking barriers: The relation between contract and intellectual property law’, [http://www.2bguide.com/docs/rncontract-new.html] May 1 2002.

^[84] Brian Fitzgerald, ‘Teaching Digital Property’, <http://www.scu.edu/law/FacWebPage/Fitzgerald/index.html> , (23 April 2001).

[*] Lawrence E. (Larry) Rosen is an attorney and founding partner of Rosenlaw.com, a law firm in California. He is a computer specialist. He has extensive experience teaching computer programming and has been a department and product manager in the computer and communications industry. As an attorney, his specialty is technology, but he is also a skilled litigator and negotiator, and a legal advisor to individuals and companies throughout the Bay Area and the world. He is executive director of Open Source Initiative, a non-profit organization that reviews and approves open source licenses and that manages the ‘OSI Certified’ certification mark for open source software.

^[85] For a critique of the free and open source distribution model see: Mathias Strasser ‘A New Paradigm in Intellectual Property Law? The Case Against Open Sources’ (2001) Stan. Tech. L. Rev. 4 at para [85] who argues ‘In reality, however, Stallman's vision suffers from the fact that, as with any communist ideology, its appeal is likely not to be powerful enough to attract sufficient manpower to develop enough free software to make it a feasible alternative to proprietary code’.

^[86] See section 3.1 of this article.

^[87] In this regard consider the notion of moral rights to attribution and integrity of a work which have long been part of the law of continental Europe. Australia adopted a moral rights regime in December 2000 through the Copyright Amendment (Moral Rights) Act 2000. For an overview of the very limited protection of moral rights in the USA see: Carter v Helmsley-Spear Inc 71 F. 3d. 77 (2^nd Cir. 1995); Gilliam v ABC Inc 538 F. 2d. 14 (2^nd Cir. 1976).

^[88] See section 3.1 of this article.

^[89] Pacific Gaming Pty Limited v Aristocrat Leisure Industries Pty Limited [2001] FCA 1636.

^[*] David Schellhase, works inhouse as an attorney with Linuxcare, a Linux services company <www.linuxcare.com>. He is currently writing a book Inhouse: The Practise of Law Inside an Emerging Growth Company. He has also worked as an attorney for a number of law firms in Silicon Valley.

^[*] Yancy is CEO of Lutris Technologies in Santa Cruz, an Internet middleware software company <http://www.lutris.com/> . He is a businessman, not an attorney, and aims to make open source companies commercially successful.

^[90] See section 4.5 of this article on the Sun Community Source License.

^[91] Raymond Eric, Note 14.

^[*] Bill Lard is Senior Director of Licensing Strategy & Architecture at Sun Microsystems, Inc. He has been an Attorney with Sun for nine years handling software related matters. His current role is to establish the future direction of Sun's overall technology licensing strategy and architecture.

^[92] Java 2 Software Development Kit version 1.3.1 Sun Community Source License, <http://www.sun.com/software/communitysource/java2/index.html> , (Feb. 23, 1999).

^[93] Code forking involves creating a derivative or modified, privately controlled product that has not complied with industry standards and thus leads to a multiplicity of forked private versions. See: Marcus Maher, ‘Open Source Software: The Success of an Alternative Intellectual Property Incentive Paradigm’ (2000) 10 Fordham I. P., Media & Ent. L.J. 619 at [678].

AustLII: Copyright Policy | Disclaimers | Privacy Policy | Feedback
URL: http://www.austlii.edu.au/au/journals/JlLawInfoSci/2001/13.html

*The GNU General Public License (GPL)*^[51]
Definition: Source code (Clause 3) – ‘the preferred form of the work for making modifications to it.’ Includes for all modules, interface definitions files, scripts for compilation and installation of the executable. Program or ‘work based on the Program’ = the Program or any derivative work under copyright law ‘a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language’. (Clause 0)
Clause	Permits	Obliges
	Copy and distribution of verbatim copies. Charging fees for: • Act of transferring copies; • Offer warranty; protection in exchange for a fee.	‘Conspicuously and appropriately publish’ on each copy a copyright notice. Disclaimer of warranty. Pass on a copy of this license with the copy.
2	Make modifications ‘thus forming a work based on the program’. Copy and distribute modifications.	Place prominent notices in modified files of your changes and date thereof. Allow any work ‘that in whole or in part contains or is derived from the Program or
*2.1 The GNU General Public License (GPL) (cont)*
Clause	Permits	Obliges
		any part thereof’ to be licensed ‘as a whole’ for no charge to all third parties under the terms of this License.
3	Copy and distribute work as object code or in executable form.	Accompany this with complete machine-readable source code under license requirements of Clause 1 and 2; OR accompany it with written offer for up to 3 years to give any third party at a fee for no more than costs the source code under license requirements of Clause 1 and 2.
5		Modification or distribution of the Program constitutes acceptance of the license terms.
7		Legal obligation under other intellectual property rights prevent you from distributing the Program.
11	No expressed or implied warranty, not even with regard to merchantability or fitness for purpose. Entire risk and cost for defects is borne by licensee.
12	Licensor is immune from damages arising from Program unless stipulated in writing

*GNU Lesser Public License*^[52]
Notes: This license is for software libraries. A software library is a ‘collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. Yet when a program is linked with a library the result is a derivative work. Under GPL this would mean the entire work would have to be made free. Compatibility of the library with other software that may be proprietorial is paramount. To avoid that whole work coming under GPL requirements the aim of this license is to ‘permit linking those libraries into non-free programs.’ For example, proprietorial developers may wish to use a ‘free’ library that has become a de-facto standard such as many of the Linux standards. This license would allow this software standard to be incorporated into a non-free product. Terms Work based on the library = code derived from the library. Work that uses the library = code must be combined with the library in order to run.
Clause	Permits	Obliges
1	Copy and distribution of verbatim copies of the library’s complete source code.	‘Conspicuously and appropriately publish’ on each copy a copyright notice. Disclaimer of warranty. Pass on a copy of this license with the copy.
2	Modify the library or any portion of it. Copy and distribute modifications.	Modified works must themselves be a software library and copied and/or distributed with notifications for free to third parties.
3	Can apply terms of the GNU GPL to a derivative work not part of a library that uses a portion of code from the library.
4	Distribution of copies of the library or portions or derivative works must be accompanied by Source code.
*2.2 GNU Lesser Public License (Cont)*
Clause	Permits	Obliges
5	Work that uses the Library	Linking a work that uses the library with the library creates an executable that is a derivative of the library. This executable is covered by the License.

*BSD^[53]and MIT License*
Clause	Permits	Obliges
	BSD Redistribute and use program in source or binary form with or without modification. MIT No limits on rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the software.	Redistribution of source code and binary form to contain copyright notices and disclaimer as to warranty only; license silent on making source code for derivative works available. Need to publish disclaimer as to warranty.

*The Artistic License*^[54]
Definitions: Package = collection of files distributed by copyright holder, and derivatives of that collection of files. Standard Version = a program package that has not been modified or has been modified in accordance with wishes of the copyright holder.
Clause	Permits	Obliges
1	Copy and distribute verbatim copies of the Standard Version of the Package
*2.4 The Artistic License (cont)*
Clause	Permits	Obliges
2	Can apply fixes and other modifications derived from public domain or from the copyright holder of the Package. Package so modified becomes the standard version.
3/4	Can further modify/distribute Package.	Notices in each changed file and must do ONE of the following: 1. Place modifications in a public domain; 2. Use modified package only in own organization; 3. Make other distribution arrangements with copyright holder; 4. Rename executables not in standard version and provide documentation of how they differ to standard.
5	Charge fees you choose for support of package but not the Package itself Can distribute Package in aggregate with other (possibly commercial) packages.	May not advertise the Package as a product of your own.

*2.5 Sun Industry Standards Source License (SISSL) (Cont)*
Clause	Permits	Obliges
2.1(a) – (d)	Initial Developer Grant World wide, royalty free, non-exclusive license subject to third party intellectual property claims to use, reproduce, modify, display, perform, sublicense and distribute original code with or without modifications and/or as part of a larger work. A patent claim to sell and offer for sale the original code.
3.1		Distribution of licensee’s modified code must comply with all requirements of the Sun standards body. If they do not meet requirements must publish deviations from standards and offer in source code form under this license.
3.2	Can charge fee for warranty support indemnity liability obligations for modified works but not Initial Developer.
3.3	Distribute any executable and source versions of modifications under license of own choice	Terms which differ from this license are not offered by Initial Developer and indemnify initial developer from any liability.
3.4	Can combine original code with other code to create a larger work and distribute as a single product.

*Mozilla Public License Version 1.0*^[56]
Definitions: Contributor = each entity that creates or contributes to the creation of modifications. Contributor version = original code, prior modifications and modifications of particular contributor.
Clause	Permits	Obliges
2.1	(a) Initial Developer grants world-wide, royalty-free, non-exclusive license (subject to third party intellectual property claims) to use, reproduce, modify, display, perform, sublicense and distribute. (b) Utilize patents of original developer to the extent necessary to use original code.
2.2	Each contributor to give rights under 2.1 (a)-(b) above.
3.2		Source code versions of modifications must be made available on same media as executable version of program or via an accepted electronic distribution mechanism (if by EDM must be available for 12 months after date it initially became available or at least 6 months after a subsequent version became available).

*Apache License*
Notes: Redistribute source code and binary forms with or without modification
Clause	Permits	Obliges
1-2	Redistributions in source or

*2.7 Apache License (cont)*
Clause	Permits	Obliges
	binary form must include copyright notice, disclaimers and list of conditions in license.
3		End-user documentation included with the redistribution, if any, must include acknowledgment of Apache.
4-5		May not use Apache name in derivative works or to endorse any derivative works.

Table 2. Select Legal Issues in Software
Open Source Products			Proprietary Products
Concern level	Ability to do something about the concern	Legal issue	Concern level	Ability to do something about the concern
(Pre-release)
High	Medium	Employees holding back rights	High	High
High	Low	Copyright and trade secret infringement	High	Medium
Medium	Very low	Patent infringement	High	Medium
(Post-release)
None	Very low	Warranty	High	High
None	Very low	Intellectual property infringement indemnification	Medium	High
None	High	Unusual license provisions (channel readiness)	High	Medium

Journal of Law, Information and Science