GNU General Public License and the Distribution of Derivative Works

 

Mikko Välimäki
Lecturer, Helsinki University of Technology
mikko.valimaki@hut.fi

 

Abstract

This article discusses the concept of derivative works in the context of computer programs. It has been a practical problem to evaluate when one work is not a derivative of another but an original and independent creation. The issue has become more important with the growing popularity of open source and free software. As more source code is freely available, more derivative programs will be compiled and distributed. The most popular open source license GNU GPL essentially governs the distribution of derivative works and therefore depends on the interpretation of this concept. This article first discusses both the legal and technical meanings of derivative computer programs and then analyses typical interpretation situations of GNU GPL from an international legal perspective. It is found that while the legal concept may be ambiguous and have dubious interpretations, such legal fuzziness hasn’t affected the popularity of GPL. Open source developers continue to use GPL as a powerful governance mechanism for different goals even though it may happen in the shadow of copyright law.

Keywords: Copyright, computer program, derivative works, modification, translation, adaptation, distribution, GNU GPL.

---

This is a refereed article published on: 22 August 2005.

Citation : Välimäki, 'GNU General Public License and the Distribution of Derivative Works’, 2005 (1) The Journal of Information, Law and Technology (JILT).<http://www2.warwick.ac.uk/fac/soc/law2/elj/jilt/2005_1/välimäki/>.  

---

1. Introduction

Modern copyright laws typically hold the exclusive right to prepare derivative works and adaptations with the original copyright holder. It has been a practical problem to evaluate when one work is not a derivative of another but an original and independent creation. The issue has become more important in the context of computer programs with the growing popularity of open source and free software. ¹ As more source code is freely available, more derivative programs will be compiled and distributed.

Source code (programming language) consists of instructions to computer, which the programmer can compile into object code (machine language). Until the popularity of open source, computer programs were typically available only as object code, which is not readable by man. Source code is not needed for utilizing the program unless the program is intended for software developers. From source code programmers can find out the structure and internal functionality of the program and make changes and additions to it, for example, in order to fix or develop it further.

The background ideas of free software with open source code are commonly attributed to Richard M. Stallman , who founded Free Software Foundation. ² In 1989 Stallman introduced GNU General Public License (GPL), which has become the most popular and also most important open source license. ³ There are tens of thousands of independent software projects available under GPL terms on the Internet. ⁴ Many programmers both at work and in their spare-time use and contribute to projects under GPL. For example, the Linux operating system kernel and the most popular web database MySQL are under GPL license.

There is already a growing legal literature on open source licensing. ⁵ However, many studies discuss rather general issues while the most troubling legal questions are in the details, such as in the legal validity of different terms of GPL. Also, GPL is designed according to the United States law and so far most studies covering GPL are written from the United States point of view. ⁶ Since the interpretation of GPL in every country is subject to its own copyright and other laws, an international perspective is selected as the approach here.

This article proceeds as follows. First it is explained how GPL depends on the concepts of ‘derivative works’ and ‘distribution’ in copyright law and what kind of policy debates their interpretation have ignited in the software industry. Then, the article discusses how both the United States and European copyright law doctrines treat derivative works in computer programs. After that, the article identifies five practical situations where the derivative works issue under GPL has been debated among software developers. Finally, the article considers the viability of the derivative works concept as a means of regulating the creation and utilization of computer programs.

2. GPL and Derivative Works

This section explains how GPL depends on the concepts of ‘derivative works’ and ‘distribution’ in copyright law and what kind of policy debates the interpretation of these concepts has ignited in the software industry.

2.1 Definition of Copyleft in GPL

Under GPL, the source code of the program is openly distributed encouraging programmers to study it, get inspired and contribute more. However, GPL is not a free pass. In order to ensure that the source code remains open, the license strictly controls the further distribution of derivative works . It requires that no one changes the license terms of the derivative copies (and closes the source code) – otherwise distribution further is not allowed. The rationale is that because the original programmers have provided the source code for the general public, any subsequent programmer should also give his contributions back to the public. In other words, GPL uses copyright law to enforce openness.

This reciprocity obligation – also commonly called as the principle of copyleft – is stated in section 2 b) of the license: ⁷

Further, section 0 states that:

A closer look at the wording of GPL 2b) shows that it includes both ‘derived from’ and ‘in whole or in part contains’ – the latter giving impression that GPL might cover more than the derivative work concept in copyright law implies. One may argue that this latter part creates a vague contractual definition of what GPL means by a derivative work: another program needs only to contain parts of source code under GPL to become governed by it.

However, because there is no indication of the quantity or quality of the ‘contained’ code and its relationship to the combined work, it can be further argued that ‘contained’ is only another way to characterize derivative works. This interpretation is also supported by section 0. In other words, what is meant by a derivative work is in the end defined by the interpretation of copyright law. Therefore the concept of derivative works – as well as modification and translation – in copyright law is most central with GPL. ⁸

The first part of 2 b) further limits the applicability of the license to those derivative works that are ‘published’ or ‘distributed’. These both refer to well-founded legal concepts in copyright law. In sum, one can conclude that GPL 2b) governs the ‘distribution’ of ‘derivative works’ as further defined in copyright law.

2.2 Ongoing Policy Debates in the Software Industry

Because of the growing popularity of open source, GPL 2b) has ignited numerous policy debates for various reasons. Free Software Foundation uses mainly ideological arguments in favor of an extensive interpretation of the clause. For example Stallman advocates for a ‘free society’ where only open source – governed by GPL’s copyleft – would be used: ⁹

Those who fear the implications of the GPL 2 b)’s royalty-free requirement (‘at no charge’) to derivative works often call the license ‘viral’ or even anti-intellectual property. For example Microsoft has warned that GPL threatens the functioning of the software ecosystem where license royalties play a significant role. In 2001, Microsoft CEO Steve Ballmer famously claimed: ¹⁰

Since then, Microsoft has somewhat mitigated their position. Open source supporters, and the software industry now more generally, argue that the scope of the copyleft obligation in GPL is limited. In fact, Free Software Foundation as the license author provides detailed guidelines on how to avoid a situation where the license would pose problems to the licensing of a derivative work. ¹¹ So far, there is no evidence that any open source licensor would use copyleft obligations with malicious intention trying to turn all software into open source. ¹²

Another debate is about open source business models , which are based on the definition of derivative works in GPL. Well-known open source software companies such as MySQL and TrollTech offer their products with a dual licensing scheme: those users who can’t use a free GPL version buy a traditional royalty-based license from the companies. For example a software developer who needs MySQL database as the basis of his own product can’t use GPL if he wants to license the derivative work (consisting of MySQL and an own application) with a licensing fee (royalty). Thus, these companies have an incentive to advocate for an extensive interpretation of the concept of derivative works. For example MySQL’s licensing policy currently skips the concept of derivative works altogether and only bases its claim as if GPL would be only about the distribution right: ¹³

In the following, this article goes into the details of the derivative works both in the letter of the copyright law and its interpretation practice.

3. Derivative Works in Copyright Law

This section discusses what constitutes a derivative work of a computer program in the United States and European copyright law. First the applicable legal rules are explained and then three different interpretation approaches are further analyzed: source code approach, component based approach, and communications based approach. Two additional and closely related legal problems are shortly mentioned: the validity of GPL and the concept of distribution in network environment.

3.1 Derivative Works in the United States and European Copyright Law

The interpretation of the concept ‘derivative works’ is not straightforward. First of all, ‘derivative works’ is a strictly United States legal concept. 17 USC 106 (2) defines it as:

In the United States case law, courts have determined that to be derivative, a computer program must be substantially similar ¹⁴ and in some form include a portion of the copyrighted work. ¹⁵ To compare, in European laws there is no exactly corresponding wording to the United States derivative works. Article 2 of the Directive on the legal protection of computer programs states as prohibited act: ¹⁶

One could interpret this as saying that the European definition of derivative works is much broader and stricter: any alteration of existing works creates a derivative work. Instead, in the United States, the new work must be based on the underlying work. In the context of computer programs, taking only a short passage of someone’s copyrighted source code into a combined program could be considered as an ‘alteration of the work’ while the new program might not be considered as being ‘based on’ the recycled code. Case law however shows that in practice the European interpretation is close to the United States. The leading UK case after the directive was implemented, Ibcos Computers v. Barclays Mercantile Highland Finance, held that the relevant question is: ‘if there was copying, has a substantial part of that work been reproduced?’ ¹⁷ (emphasis added)

In addition to the economic right of derivative works, one should take into account the moral right of author integrity . It further restricts the creation of modifications, which could cause damage to the reputation or honor of the original author, and thus strengthens the concept of derivative works. ¹⁸ One can for example imagine an open source developer feeling his reputation or honor is harmed if someone modifies the source code in a way that it could be used in connection with ‘non-ethical’ software. In fact, one way to look at GPL is to see it promoting the historical ideals of authors’ inalienable rights to control the integrity and paternity of their personal creations. Probably only because United States copyright law happens to be silent on author integrity, also GPL lacks direct reference to it.

Finally, GPL as a copyright license must be interpreted in each jurisdiction under the applicable laws in force. As discussed, the United States and European copyright laws differ in their respective formal definition of derivative works. GPL license has been written with explicit reference to the United States style wording but one can argue that the same wording covers also European definition.

This raises another interesting legal problem, namely the validity of GPL in different jurisdictions. One lower court judgment from Germany concluded that the most relevant parts of GPL (and many similar open source licenses) are enforceable at least in Germany. ¹⁹ Obviously more work is needed in this direction to provide open source development models with a stronger legal basis. This is especially important in countries other than the United States since most licenses have been written and legally analyzed in the United States context.

In the following, this article discusses how the legal principles of derivative works can be interpreted in practice. It is assumed that both the European and United States copyright systems recognize the existence of derivative works.

3.2 Source Code Interpretation

The first interpretive approach can be called as the literal or source code interpretation . In a simplified example there are two source codes and it is claimed that one source code is a derivative work of the other. Lawyers have developed two theories applicable with the source code analysis of derivative works: the idea-expression dichotomy and the abstraction-filtration-comparison method.

The idea-expression dichotomy says that copyright applies only to original expressions and not to ideas. Therefore any idea behind the work, say a mathematical algorithm or an idea to develop a new kind of word processing software is not under copyright. In other words, copyright does not limit any subsequent author from developing a new operating system or compression algorithm. Existing programs can be studied and analyzed for the basis of new original works and only the literal copying of source or object code is restricted.

Abstraction-filtration-comparison method has been developed in the United States case Computer Associates International v. Altai. ²⁰ Ravicher has found evidence that this method is nowadays the dominant way of interpreting derivative works of computer programs in the United States district courts. ²¹ The method has been also applied in Europe. ²² The idea is in short that the similarity between two source codes must be proved by first abstracting the structure and functions in the suspected source codes, then filtrating inessential parts (non-copyrighted, public domain etc.) out and finally comparing the result. Comparison is not based on the idea-expression dichotomy but on a more detailed contextual analysis of source code structure, variable names etc.

The case relied heavily on the expert witness of a computer science professor whose view was that a computer program consists of both text and behavior. ²³ According to this view, the source and object code are copyrightable text while the actual operation of the program is more like behavior. Therefore for example interfaces and other behavioral functionality could not be regarded as text nor are they copyrightable.

3.3 Component Based Interpretation

The second approach can be called as the component based interpretation . In practice, a component-based view of computer programs may be more usable in open source development, which favors programming paradigms that rely on maximal source code reuse. Component based interpretation stems from the wording of GPL section 2 where ‘identifiable sections’ are read here as program components:

One can distinguish between three different situations: developer owned components, tailor made components and third party components. Perhaps the most common GPL problems occur with third party components when GPL code developed by others is used. Figure 1 below illustrates the issue.

---

  

Figure 1. A simplified component-based view of a computer program.

---

Assume a developer has a software product where he uses third party source code distributed in a component. The question is if the resulting work combining the main program and the component is considered as a derivative work of the component and hence under (partial) control of the third party copyright owner. The question can be analyzed further. For instance, what if the source codes of the main program and the component have been mixed (an internal or embedded component)? This kind of internal component tailored ‘inside’ the whole work creates most clearly a derivative work of the combined whole. What about cases in which the product uses the component’s functionality (e.g. adds a new runtime-interface on the top of it)? Since copyright does not cover use or interfaces, such external unmodified runtime components operating only through interface specifications would clearly not be derivatives of the product. What if the component has been linked to or linked from (e.g. an external library or device driver)? This is the vaguest case.

Consider a software product that links to library routines. Does it become a derivative of the library? Maybe it doesn’t; many library routines cover just standard functionality to help exactly in the ‘routine’ tasks. But what if these routines cover substantial and original functionality of the software and no other routines could be used? Further, consider a component according to a client-server setting where the component acts as a server to the client software product (component is linked from). Perhaps the software product would not be a derivative of the server component if it only uses the server’s services. But if the product depends heavily on the server’s functionality and does not run separately in any other setup without it, the situation is more dubious: if one wants to use the product, then also the component must be copied and distributed.

3.4 Communications Based Interpretation

The two interpretation criteria above are both based on the conventional wisdom of the contents of copyright law. While they may satisfy lawyers and project managers, more technical persons may still continue to ask what really constitutes a derivative program between two seemingly separate source code components. Free Software Foundation has suggested an interpretation based on more technical criteria and the mechanisms and semantics of communication between the components:

3.5 Summary

It is not easy to compare the different criteria to analyze when two parts should be interpreted as creating one whole according to the derivative works concept. The first criteria of source code interpretation gets clear support from copyright law and can be directly applied in most situations. The second criteria of component based interpretation is more ambiguous. It is however supported by GPL itself and can be also applied within the terms of copyright law in many situations. Only the third criteria of communications based interpretation sounded more remote to both copyright law and GPL.

Finally, the discussed criteria have some clear limitations. In networked environment one can think of situations, where third party components have been mixed with other parts creating a ‘derivative work’ with any of the criteria mentioned. However, the whole work is not under the copyleft obligation of GPL 2 b) since it is only run and accessed through the Internet but not ‘distributed’ as a software package. This is common when a program is based on e.g. web services or other online components.

4. Interpretation Situations

This section discusses different practical – and sometimes rather technical – interpretation situations where it has been not clear to software developers whether the whole work is a derivative of the component or any external source code under GPL.

4.1 Program Output

Consider a theoretical model of computer program as a black box taking input, making a computation, and producing output. One could say any output from a computer program is mechanically computed from the input. Therefore, it is worth asking if the output could be interpreted as a derivative work of input and computation.

The question is quite topical regarding program compilers. If compiler output is regarded as a derivative work of both the source code and the ‘work’ of a compiler, could the author of the compiler have also rights to the resulting output? If the output does not include any code or expression from the compiler, the answer seems to be straightforward no. But what if the resulting program includes any expression added by the compiler? Then the question comes back to source code based interpretation.

GPL section 0 has a quite open-ended wording on the issue:

While the issue of derivative works is compiler specific it is practically essential. No new programs can be made without a compiler and GCC works in a way that some common code will be copied to every binary compiled. Without this exception, it would be only possible to build GPL programs with GCC.

4.2 Programming Libraries

One frequently debated issue is if function calls to external library functions should be interpreted to make the whole program as a derivative work. Here, one can distinguish between two types of situations:

Some time ago there was controversy over this issue among developers and many of them claimed that run-time linking would not constitute a derivative work. However, a common understanding among open source developers – following an extensive component based interpretation – seems to be now that both types of linking constitute the combined program to be a derivative work. ²⁵ For instance Metzger and Jaeger argue that if a function under GPL is loaded into the computer’s memory at the same time with the main program and linked there to practically become a single executable then the whole work should be interpreted as a derivate of its parts. ²⁶

On the other hand, there should remain areas where linking is allowed. Otherwise it would not be possible to build any application to a modern operating system without the explicit acceptance of the operating system copyright owner. GPL has solved the question in section 3 as follows:

‘As a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.’

There has been one court case where the linking issue was almost taken under closer analysis. ²⁷ Progress Software Corporation had linked its Genimi table handler to MySQL AB’s database under GPL. Technically speaking, the linking of Gemini could have been called static since it was compiled inside the MySQL binary distribution. Progress didn’t however release Gemini’s source code and the parties ended up in a court. The court stated in a preliminary injunction:

The case was settled afterwards. The court was supportive to MySQL’s argumentation that the linking method used by Progress indeed caused Gemini to be a derivative of MySQL. It is interesting to note, however, that it might be possible not to release the source code of a program under GPL without causing commercial harm.

4.3 Plug-Ins and Device Drivers

Consider next a situation where one develops a plug-in or device driver to a program under GPL. Is such a plug-in a derivative work of the main program and, hence, under GPL? Free Software Foundation’s Frequently Asked Questions list answers in accordance with their dubious communications based interpretation. ²⁸ It states:

There has been also relevant practical debate on the issue regarding proprietary kernel modules such as device drivers in Linux. ²⁹ Linus Torvalds, the main author of Linux kernel, has added the following statement to Linux’s GPL:

This note has lead many programmers to believe that device drivers, and plug-ins in general, are not derivative works. However, the note has little if any legal effect. Derivative works are ultimately defined in law and not in the license. Moreover, GPL license does not allow modification of the license and, even more importantly, Linus Torvalds himself is only one of the numerous copyright holders to Linux kernel – some of which are unknown. Referring to estoppel doctrine, Torvalds has indicated this note should be taken as an indication that he is not going to support legal action against any proprietary Linux device driver manufacturers. ³¹

Torvalds has somewhat clarified his position on device drivers during the years. In 1995, he explained that kernel modules are ‘logically independent’ from the kernel itself and that they can be seen as ‘use’ rather than ‘linking’ to the kernel. He thought that any device driver written for example to UNIX could be ported to Linux without the need to use GPL. ³² In 2003, Torvalds further explained that: ³³

Obviously, Linux should be today familiar to most developers and Torvalds’ interpretation would hence mean that basically all new kernel modules in Linux should be under GPL. Again, this reminds of a communications based interpretation with questionable legal merits.

4.4 Client Programs and Graphical User Interfaces

Assume one develops a commercial client program for another program under GPL. A practical example is a graphical client to manage MySQL databases. Is a client a derivative work and under GPL? MySQL AB’s licensing page stresses the concept of distribution saying that ‘if you distribute a proprietary application in any way’ then GPL becomes binding. Obviously, the company regards all clients as derivative works and in order to even use a client with other terms than GPL the developer of the client would need to buy a proprietary license from MySQL AB. In effect, they seem to interpret GPL as if a separate (based on both component based and source code interpretation) client program from their database server – used for commercial purposes – would be under the derivative works doctrine because of GPL 2b). ³⁴

However, neither copyright law nor GNU GPL license for that matter place any restrictions on pure software use. Thus merely using a work under GPL unmodified can be the basis for a derivative work only under the dubious communications based interpretation. So clients are free from the copyleft obligation? To this, MySQL AB answers – in line with Linus Torvalds – that if one needs their database in order to run the client, then one is basically also distributing MySQL database and GPL becomes binding.

4.5 Software Subscription and Web Services

Some commentators have noted that there is an ‘ASP loophole’ in GPL. In essence, GPL applies only when works are distributed further. The using or running of the program does not oblige one to the terms of the license. It is also possible to modify the program and run it for private purposes without publishing the source code. This wasn’t an issue when the latest version of GPL was introduced in 1991.

However, today unpublished software can be used commercially easily through the Internet. In networked environment one does not need to ‘publish’ the computer program in order to use it. Most web server software runs practically hided from end users, who access the software through their browsers. As Tim O´Reilly contests: ³⁵

This sort of private modification of GPL seems to be allowed under 2 b). There are no obligations to publish the software, which is required in order for GPL to be effective. But what exactly is software publication? Outsourcing or hiring programmers to develop software in-house most likely does not constitute a distribution. Instead, if one hires an independent developer or a company who may desire to license the software to other parties later, then GPL most likely requires the software to be further distributed to anyone with minimal copying costs. Still, there remains a possibility that no third party becomes aware that the software is developed and licensed under GPL.

Obviously, the next version of GPL may try to address this usage model. At the moment for example Affero Public License has included a ‘network copyleft’ clause in effect requiring web service users to publish modifications. ³⁶ If enforceable, such a clause would take GPL towards extensive communications based interpretation of derivative works.

5. Conclusion: The Future of GNU GPL and Derivatives

The force is strong with GPL. Its main functionality rests on the concept of derivative works in copyright law, which is fuzzy and subject to contradictory interpretations. Especially a communications based interpretation seems to be popular among developers while its legal merits can be seriously questioned if one rejects the idea that copyright could cover communications or behavior for that matter. However, it seems that such fuzziness hasn’t really affected the popularity of GPL at all. There hasn’t even been but a few minor legal disputes on the interpretation of GPL 2 b). Almost everything that has legal relevance has happened in informal online and email discussions – in the shadow of the copyright law – as described in this article. ³⁷

The concept of derivative works is a powerful tool for software developers. As noted, some use it for ideological purposes (Free Software Foundation) and others have more economic goals (e.g. open source businesses). It must be stressed that GPL 2b) can be efficiently used to foster different goals . One may use GPL to make sure the software is not developed further in secret and thus ensure maximum individual liberties at the expense of corporate control. Another may choose GPL to be able to discriminate user groups and thus apply it as a business strategy.

The concept of derivative works is also relevant in the legal policy debate about the scope of copyright. Historically, copyright law started as book printers’ right to control the copying of the books they had printed. As of today, the rights granted have extended to cover almost any kind of use including the making of derivative works or any alterations based on the original work. From a detailed analytical perspective the criticism of this expansion trend – often supported by open source developers – may sound confusing. How does the opposition to copyright’s expansion play with the essential concept of derivative works in open source licenses?

Maybe the key is to link derivative works to the author’s right of integrity, which also restricts modification. As noted, GPL and other open source licenses can be seen as going against the expansion of economic rights to control copying and modification. However, at the same time they promote the historical ideals of authors’ inalienable rights to control the integrity and paternity of their personal creations. Now, in practice, the easiest way to enforce the moral rights – which for example still lack full codification in the United States copyright law – seems to be through the economic components of copyright. Author’s will, after all.

Notes and References

¹ In this article, the term open source is also used to cover free software.

² See < http://www.gnu.org/>. On the history of Stallman and Free Software Foundation see Williams (2002). Open Source Initiative, from which Stallman separated, was founded in 1998 and it quickly made the term open source commonly known. The purpose of Open Source Initiative is to make open source and free software more familiar among business users.

³ A short history of GNU GPL can be found here:
< http://www.free-soft.org/gpl_history/>. There are over fifty other licenses accepted by the Open Source Initiative, which qualify as open source. See < http://www.opensource.org/>.

⁴ For example at < http://sourceforge.net/>, the unofficial headquarters of open source projects, there is currently over 100 000 software projects of which around two thirds are under GPL.

⁵ See e.g. Metzger and Jaeger (2002) for an academic approach in German context. Rosen (2004) and St. Laurent (2004) are more practical guides to the licensing issues from United States perspective. Välimäki (2005) offers an academic law and economics perspective.

⁶ Metzger and Jaeger (2002) being perhaps the most important exception.

⁷ It should be noted that also numerous other open source and open content licenses alike are designed according to the guiding ‘copyleft’ principles of GPL. A good example is the popular Creative Commons licenses designed for other copyrighted works than computer programs. Those licenses typically allow free copying and distribution. The distribution of derivative works, however, may be restricted. See http://www.creativecommons.org/.

⁸ Computer programs and software products may also be protected with other intellectual property rights such as patents and trademarks. However, this study concentrates on copyright protection and especially the concept of derivative work.

⁹ See Stallman (1999).

¹⁰ The statement is commented in e.g. Greene (2001).

¹¹ For example Free Software Foundations’ Frequently Asked Questions about the GNU GPL at < http://www.gnu.org/licenses/gpl-faq.html> has currently over twenty detailed questions and answers regarding the interpretation of GPL clause 2b).

¹² See e.g. Boyle (2004), arguing that the intent of GPL authors and judicial common sense speak against a scenario where any major software product would be required to use GPL if it would include some notorious amount of GPL source code.

¹³ See MySQL’s licensing policy at http://www.mysql.com/company/legal/licensing/.

¹⁴ Litchfield v. Spielberg, 736 F.2d 1352 (9 ^th Cir. 1984). See also Lemley, Menell, Merges and Samuelson (2000), p. 208-209.

¹⁵ It was held in United States v. Manzer, 69 F.3d 222 (8 ^th Cir. 1995) that 70% similarity in the code base was sufficient to make the other work derivative. See also Lemley, Menell, Merges and Samuelson (2000), p. 208, referring to case Recall Vault Corp. v. Quaid Software Ltd., 847 F.2d 255 (5 ^th Cir. 1988) where the quality of the copying is discussed.

¹⁶ Council Directive 91/250/EEC of 14 May 1991 on the legal protection of computer programs. Official Journal L 122 , 17/05/1991 p. 42-46.

¹⁷ See Ibcos Computers Ltd v. Barclays Mercantile Highland Finance Ltd (1994) FS 275.

¹⁸ Author integrity continues to be a fundamental part of copyright law in the civilized world, and has been codified into international copyright treaties. According to Berne Convention article 6bis: “the author shall have the right to … object to any distortion, mutilation or other modification of, or other derogatory action in relation to, the said work, which would be prejudicial to his honor or reputation.” (emphasis added)

^{http://www.jbb.de/urteil_lg_muenchen_gpl.pdf> and it is commented by e.g. Höppner (2004). See also Guadamuz (2004).}

²⁰ Computer Associates International, Inc. v. Altai, Inc., United States Court of Appeals, Second Circuit. June 22, 1992.

²¹ See Ravicher (2002).

²² At least in a Finnish case Sonera Systems Oy v. VF Partner Oy (Helsinki Court of Appeals), decision given 28th December 1999, the principles of the Altai case were furthered in the opinion of a law professor and then applied by a computer science professor as an expert witness.

²³ Later professor Randall Davis published an article on the issue coauthored with law professors. See Samuelson, Davis, Kapor and Reichman (1994).

²⁴ See e.g. Stallman (2005) for one of the latest public opinions.

²⁵ This is explained in detail in e.g. GPL FAQ. See note 11 above.

²⁶ See Metzger and Jaeger (2002), pp. 44-45.

²⁷ Progress Software Corp. v. MySQL AB, 195 F. Supp. 2d 328, 329 (D. Mass.).

²⁸ See GPL FAQ, note 11 above.

²⁹ This question is discussed in great detail in the German GPL commentary by Institut für Rechtsfragen der Freien und Open Source Software (2005), p. 70-73.

³⁰ See e.g. http://www.gcom.com/home/support/whitepapers/linux-gnu-license.html .

³¹ Message by Linus Torvalds to kernel-discuss, 4 ^th December 2003.

³² Message by Linus Torvalds to gnu.misc.discuss, 17 ^th December 1995.

³³ Message by Linus Torvalds to kernel-discuss, 3 ^rd December 2003.

³⁴ As noted in section 2.2 above, there is an economic rationale for their interpretation.

³⁵ See McMillan (2003).

³⁶ Affero’s modified GPL is also supported by Free Software Foundation: < http://www.gnu.org/press/2002-03-19-Affero.html>. The license text itself can be found here: http://www.affero.org/oagpl.html .

³⁷ O’Mahony (2003) calls the informal enforcement mechanism as ‘the court of public opinion’. According to her, most community projects seek license compliance through informal means such as pressuring online discussions, emails and negative publicity. They try not to even threat with legal action or claim damages. Justification for enforcement comes from the collective prevailing opinion of the community.

Books

Boyle, J (2004) ‘Give me liberty and give me death?’, Financial Times, October 21, 2004, < http://www.law.duke.edu/boylesite/liberty.html>

Greene, T C (2001) ‘Ballmer: “Linux is a cancer”’, The Register, June 2nd 2001, http://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/

Guadamuz, A (2004) ‘Viral contracts or unenforceable documents? Contractual validity of copyleft licenses’, European Intellectual Property Review, Volume 26, Issue 8, pp. 331-339.

Höppner, J P (2004) ‘The GPL prevails: An analysis of the first-ever Court decision on the validity and effectivity of the GPL’, SCRIPT-ed 1:4, available at http://www.law.ed.ac.uk/ahrb/script-ed/issue4/GPL-case.asp .

Institut für Rechtsfragen der Freien und Open Source Software (2005) Die GPL kommentiert und erklärt. O´Reilly.

Lemley M and Menell P and Merges R and Samuelson P (2000) Software and Internet Law. Aspen Law & Business.

Metzger A and Jaeger T (2002) Open Source Software. Rechtliche Rahmenbindungen der Freien Software. C.H.Beck.

McMillan R (2003) ‘Tim O'Reilly: Software licenses don't work’, InfoWorld, 3rd July 2003, < http://www.infoworld.com/article/03/07/03/HNoreilly_1.html>.

O’Mahony, Siobhan (2003) ‘Guarding the Commons: How Community Managed Software Projects Protect Their Work’, Research Policy, Volume 32, Issue 7, pp. 1179-1198.

Ravicher D (2002) ‘Software Derivative Work: A Circuit Dependent Determination’, available at http://www.pbwt.com/Attorney/files/ravicher_1.pdf .

Rosen L (2004) Open Source Licensing. Prentice Hall.

Samuelson P and Davis R and Kapor M D and Reichman J H (1994) ‘A Manifesto Concerning the Legal Protection of Computer Programs’, Columbia Law Review, also available at: http://wwwsecure.law.cornell.edu/commentary/intelpro/manifint.htm .

Stallman, Richard (1999) ‘Why you shouldn't use the Library GPL for your next library’, http://www.gnu.org/philosophy/why-not-lgpl.html .

Stallman, Richard (2005) ‘Patently Absurd’, The Guardian Unlimited, June 20th 2005, http://www.guardian.co.uk/online/comment/story/0,12449,1510566,00.html .

St. Laurent A M (2004) Understanding Open Source and Free Software Licensing, O´Reilly.

Välimäki M (2005) The Rise of Open Source Licensing, Turre Publishing, available at http://pub.turre.com/.

Williams S (2002) Free as in Freedom, O’Reilly, available at < http://www.oreilly.com/openbook/freedom/>.