GNU General Public License and the Distribution of Derivative Works
Lecturer, Helsinki University of Technology
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/>.
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.1 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.2 In 1989 Stallman introduced GNU General Public License (GPL), which has become the most popular and also most important open source license.3 There are tens of thousands of independent software projects available under GPL terms on the Internet.4 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.5 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.6 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.
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.
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:7
‘2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work … provided that … b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.’ (emphasis added)
Further, section 0 states that:
‘The “Program”, below, refers to any such program or work, and a “work based on the Program” means either the Program or 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.’ (emphasis added)
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. 8
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.
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:9
‘We free software developers should support one another. By releasing libraries that are limited to free software only, we can help each other's free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition.’
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:10
‘The way the license is written, if you use any open-source software, you have to make the rest of your software open source… [GPL’d software] is a cancer that attaches itself in an intellectual property sense to everything it touches’ (emphasis added)
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.11 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.12
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:13
‘If you distribute a proprietary application in any way, and you are not licensing and distributing your source code under GPL, you need to purchase a commercial license of MySQL’ (emphasis added)
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.
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.
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:
‘derivative work’ is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a ‘derivative work’. (emphasis added)
In the United States case law, courts have determined that to be derivative, a computer program must be substantially similar14 and in some form include a portion of the copyrighted work.15 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:16
‘(b) the translation, adaptation, arrangement and any other alteration of a computer program and the reproduction of the results thereof, without prejudice to the rights of the person who alters the program’ (emphasis added)
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?’17 (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.18 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.19 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.
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.20 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.21 The method has been also applied in Europe.22 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.23 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.
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:
‘These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. […]’
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.
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:
‘What constitutes combining two parts into one program? […] We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.’
The viewpoint taken is software as speech and communication. If one part of the program speaks with the other part with ‘physical contact’, there could be a derivative work in place. However, it is well known that copyright does not cover communication mechanisms or protocols as such. In fact, Free Software Foundation’s interpretation criteria sound closer to patent law (method claims) than copyright law. On this basis, it is interesting to note that Free Software Foundation strongly opposes software patents.24 Maybe their far-reaching interpretation of copyright law only speaks of how much development control Free Software Foundation would like to address through GPL.
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.
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.
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:
‘…the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.’
Popular Gnu Compiler Collection (GCC) happens to be in the category where code may be copied into the binary. Therefore it has a special exemption to GPL:
‘As a special exception, if you link this library with other files, some of which are compiled with GCC, to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License.’
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.
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:
1. Run-time linking: when an operating system function call is used outside the executable.
2. Static linking: when a function call is compiled into one executable and called within the program.
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.25 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.26
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.27 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:
‘MySQL has not demonstrated a substantial likelihood of success on the merits or irreparable harm. Affidavits submitted by the parties’ experts raise a factual dispute concerning whether the Gemini program is a derivative or an independent and separate work under GPL, [paragraph] 2. After hearing, MySQL seems to have the better argument here, but the matter is one of fair dispute. Moreover, I am not persuaded that the release of the Gemini source code in July 2001 didn’t cure the breach.’
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.
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.28 It states:
‘If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, so plug-ins must be treated as extensions to the main program. This means they must be released under the GPL …’ (emphasis added)
There has been also relevant practical debate on the issue regarding proprietary kernel modules such as device drivers in Linux.29 Linus Torvalds, the main author of Linux kernel, has added the following statement to Linux’s GPL:
‘NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of “derived work”.’30
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.31
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.32 In 2003, Torvalds further explained that:33
‘- anything that was written with Linux in mind (whether it then also works on other operating systems or not) is clearly partially a derived work.
- anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it.’ (emphasis added)
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.
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).34
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.
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:35
‘…all of the killer apps of the Internet era: Amazon, Google, and Maps.yahoo.com. They run on Linux or FreeBSD, but they're not apps in the way that people have traditionally thought of… one of the fundamental premises of open source is that the licenses are all conditioned on the act of software distribution, and once you're no longer distributing an application, none of the licenses mean squat.’
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.36 If enforceable, such a clause would take GPL towards extensive communications based interpretation of derivative works.
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.37
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.
1 In this article, the term open source is also used to cover free software.
2 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.
3 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/>.
5 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.
6 Metzger and Jaeger (2002) being perhaps the most important exception.
7 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/.
8 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.
9 See Stallman (1999).
10 The statement is commented in e.g. Greene (2001).
11 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).
12 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.
14 Litchfield v. Spielberg, 736 F.2d 1352 (9th Cir. 1984). See also Lemley, Menell, Merges and Samuelson (2000), p. 208-209.
15 It was held in United States v. Manzer, 69 F.3d 222 (8th 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 (5th Cir. 1988) where the quality of the copying is discussed.
16 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.
17 See Ibcos Computers Ltd v. Barclays Mercantile Highland Finance Ltd (1994) FS 275.
18 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)
19 GPL was held specifically valid in a German court decision by Landgericht München I on 19th May 2004. The decision can be found at <http://www.jbb.de/urteil_lg_muenchen_gpl.pdf> and it is commented by e.g. Höppner (2004). See also Guadamuz (2004).
20 Computer Associates International, Inc. v. Altai, Inc., United States Court of Appeals, Second Circuit. June 22, 1992.
21 See Ravicher (2002).
22 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.
23 Later professor Randall Davis published an article on the issue coauthored with law professors. See Samuelson, Davis, Kapor and Reichman (1994).
24 See e.g. Stallman (2005) for one of the latest public opinions.
25 This is explained in detail in e.g. GPL FAQ. See note 11 above.
26 See Metzger and Jaeger (2002), pp. 44-45.
27 Progress Software Corp. v. MySQL AB, 195 F. Supp. 2d 328, 329 (D. Mass.).
28 See GPL FAQ, note 11 above.
29 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.
31 Message by Linus Torvalds to kernel-discuss, 4th December 2003.
32 Message by Linus Torvalds to gnu.misc.discuss, 17th December 1995.
33 Message by Linus Torvalds to kernel-discuss, 3rd December 2003.
34 As noted in section 2.2 above, there is an economic rationale for their interpretation.
35 See McMillan (2003).
37 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.
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/>.