Munich Intellectual Property Law Center (MIPLC) Master Thesis (2011/12)

Munich Intellectual Property Law Center (MIPLC)
Master Thesis (2011/12)
Legal Protection of Software

- Copyright, Patent and Open Source -
Challenges for Business in a Mixed Environment
Yuko, Matsuya
MIPLC Class of 2012
Suggested Citation:
Matsuya, Yuko;
Legal Protection of Software
- Copyright, Patent and Open Source -
Challenges for Business in a Mixed Environment
MIPLC Master Thesis (2011/12)
http://www.miplc.de/research/
Available at SSRN: http://ssrn.com/abstract=2244216
Electronic
Electroniccopy
copyavailable
availableat:
at:https://ssrn.com/abstract=2244216
http://ssrn.com/abstract=2244216
II
Table of Contents
Table of Contents ................................................................................................................. II

Abstract.............................................................................................................................. IV
Acronyms and Abbreviations .............................................................................................. V
I. Introduction....................................................................................................................... 1
II. Legal basis for software protection ................................................................................. 3
A. Copyright ....................................................................................................................... 3
1. EU .............................................................................................................................. 3
a) Scope of protection ................................................................................................... 4
b) Exclusive rights ........................................................................................................ 5
c) Exceptions of exclusive rights ................................................................................... 6
d) Exhaustion ................................................................................................................ 6
2. US .............................................................................................................................. 8
a) Scope of protection ................................................................................................... 8
b) Exclusive rights ........................................................................................................ 9
c) Limitations of exclusive rights ................................................................................ 10
d) First sale doctrine.................................................................................................... 11
3. Japan......................................................................................................................... 12
a) Scope of protection ................................................................................................. 13
b) Exclusive rights ...................................................................................................... 13
c) Exceptions of exclusive rights ................................................................................. 15
d) Exhaustion .............................................................................................................. 16
B. Patent ........................................................................................................................... 17
1. EU ............................................................................................................................ 19
a) Statutory basis ......................................................................................................... 19
b) Technicality issue.................................................................................................... 19
c) Other requirements for patentability ........................................................................ 21
2. US ............................................................................................................................ 22
b) Case law development on patent eligibility ............................................................. 22
3. Japan......................................................................................................................... 25
b) Statutory "invention" .............................................................................................. 26
III. Open source licenses..................................................................................................... 28
A. History of open source licenses .................................................................................... 28
B. Mechanism of open source licenses .............................................................................. 30
1. Open Source Definition............................................................................................. 30
2. Copyleft .................................................................................................................... 32
C. Major open source licenses........................................................................................... 34
1. GNU General Public License (GPL) ......................................................................... 34
2. GNU Lesser General Public License (LGPL) ............................................................ 37
3. Mozilla Public License (MPL) .................................................................................. 38
4. Apache License ......................................................................................................... 38
D. Legal issues around open source licenses ..................................................................... 39
1. Enforceability: contractual covenant or license condition? ........................................ 39
2. Jurisdiction and applicable law.................................................................................. 41
Electronic
Electroniccopy
copyavailable
availableat:
at:https://ssrn.com/abstract=2244216
http://ssrn.com/abstract=2244216
III
3. Relationship with national laws ................................................................................. 42

4. Conflict with exhaustion or first sale doctrine? .......................................................... 43
IV. Business models involving software ............................................................................. 45
A. Proprietary software business model (primary market) ................................................. 45
B. OSS business models (secondary market) ..................................................................... 46
1. Example sources of revenue ...................................................................................... 46
a) Services in relation to OSS...................................................................................... 46
b) Hardware accompanying OSS................................................................................. 47
c) Software related to OSS .......................................................................................... 47
2. Dual-licensing ........................................................................................................... 48
C. Possible problems and conflicts .................................................................................... 48
1. Copyright infringement risk in OSS business ............................................................ 48
2. Patent infringement risk in OSS business .................................................................. 49
3. "Contamination" of proprietary software by OSS ...................................................... 52
a) Mixing OSS and proprietary source codes............................................................... 53
b) Static and dynamic linking with OSS ...................................................................... 54
c) Software that runs on OSS operating system ........................................................... 56
d) Software created using OSS as a development tool ................................................. 56
e) Distributing proprietary software together with OSS ............................................... 57
4. Violation of open source license terms ...................................................................... 57
V. Possible best practices .................................................................................................... 60
A. Proprietary or open source?.......................................................................................... 60
B. Just copyright or also patent protection? ....................................................................... 61
C. Which open source license?.......................................................................................... 62
D. What to consider in a mixed environment..................................................................... 63
1. Compliance with open source licenses ...................................................................... 63
2. Avoiding "contamination" of proprietary software ..................................................... 64
VI. Conclusion .................................................................................................................... 65
List of Works Cited............................................................................................................. 66
Electronic copy available at: https://ssrn.com/abstract=2244216

IV
Abstract
This thesis aims to provide clues on how software developers could use and
distribute proprietary software and open source software to run their
business smoothly.
Proprietary software is protected by copyright and/or patent that confers the

rightholders exclusive rights for the use of their software. The developers of
proprietary software use their exclusive rights to secure profits in their
businesses. Open source licenses are built upon the existing copyright
system to ensure the freedom of use, modification and redistribution of
software for the recipients of the software.
In this thesis, first, legal basis for software protection available in the
European Union (EU), the United States (US) and Japan will be described.
Next, the history and characteristics as well as legal issues of open source
licenses will be discussed. Further considerations will cover possible legal
problems arise around proprietary software and OSS business models.
Based on these discussions, possible best practices will be suggested for
software developers to protect their software.

V
Acronyms and Abbreviations
CJEU = Court of Justice of European Union

EPC = European Patent Convention
EPO = European Patent Office
EU = European Union
FSF = Free Software Foundation
GPL = General Public License
IT = Information Technology
JCA = Copyright Act of Japan
JPA = Patent Act of Japan
JPO = Japan Patent Office
LGPL = Lesser General Public License
MIT = Massachusetts Institute of Technology
MPL = Mozilla Public License
OSI = Open Source Initiative
OSS = Open Source Software
RAM = Random Access Memory
ROM = Read Only Memory
SFLC = Software Freedom Law Center
TRIPS = Trade-Related Aspects of Intellectual Property Rights
US = United States
USPTO = United States Patent and Trademark Office
WCT = WIPO Copyright Treaty
WIPO = World Intellectual Property Organization
WTO = World Trade Organization

1
I. Introduction
Copyright and patent provide legal protection for software. Rightholders for
proprietary software protected by copyright and/or patent enjoy exclusive
rights for the use of their software thereby securing profits in their
businesses. On the other hand, open source licenses offer another
mechanism for software use and development. Open source licenses use the
copyright to ensure the freedom of the use, modification and redistribution
of software for the recipients of the software.1 Software licensed under an
open source license is called open source software (OSS). Some in the open
source community are against the idea of proprietary software, especially
software patents.2 For proprietary software developers, handling of OSS can
seem troublesome and some proprietary developers in the past even adopted
"'Just Say No' policies" against OSS.3 Nevertheless, the speed of technology
advancement in the software industries and the growing popularity of OSS
make it unrealistic for proprietary developers to simply bypass the open
source community.4
What would be the legal issues in software business when OSS and
proprietary software coexist? How could OSS developers make profit when
they give the users freedom to use and redistribute their software? How
could software developers use OSS without undermining the value of their
proprietary software? This thesis aims to provide clues on how software
developers could use and distribute proprietary software and OSS to run
their business smoothly.
In this thesis, legal basis for software protection available in the European
Union (EU), the United States (US) and Japan will be described first in
Chapter II. In Chapter III, the history and characteristics as well as legal
1
See infra Parts III.A-B.
2
See, e.g., infra Parts III.A, III.C.1.
3
Karen Faulds Copenhaver, Managing Compliance with Open Source Software Licenses
Compliance programs for open source software aren't about fear--they're about building a
better business, 54 No. 3 PRAC. LAW. 21, 22 (2008).
4
See, e.g., Id. at 21-22.

2
issues of open source licenses will be discussed. Chapter IV will discuss

possible legal problems arise around proprietary software and OSS business
models. Based on the discussions in Chapter II to IV, Chapter V will suggest
possible best practices for software developers to protect their software.
Chapter VI will conclude the thesis. In this thesis, the term "software" and
the term "computer programs" are used interchangeably unless otherwise
noted.

3
II. Legal basis for software protection
The EU, the US and Japan all provide possibility to protect software under
copyright law and, to some extent, under patent law.
A. Copyright
Being members of the World Trade Organization, the EU, the US and Japan
protect computer programs as literary works under the Berne Convention5
according to Article 10(1) of TRIPS.6 WIPO Copyright Treaty (WCT)7 also
sets forth that computer programs are protected as literary works within the
meaning of the Berne Convention.8 As stipulated in Article 5(2) of the Berne
Convention, a computer program may enjoy copyright protection without
any formality in any of the three jurisdictions discussed here.
1. EU
Copyright protection of computer programs in the EU has been harmonised

since the adoption of Council Directive 91/250/EEC of 14 May 1991 on the
legal protection of computer programs. This Directive was later replaced by
Directive 2009/24/EC of the European Parliament and of the Council of 23
April 2009 on the legal protection of computer programs (hereinafter, the
"Directive"). 9 Article 1(1) of the Directive makes it clear that computer
programs are protected by copyright as literary works within the meaning of
the Berne Convention.
5
Berne Convention for the Protection of Literary and Artistic Works, Paris Act on July 24,
1971, as amended on September 28, 1979 (Berne Convention).
6
Article 10(1) of the Agreement on Trade-Related Aspects of Intellectual Property Rights
(TRIPS) ("Computer programs, whether in source or object code, shall be protected as
literary works under the Berne Convention (1971).").
7
WIPO Copyright Treaty adopted in Geneva on December 20, 1996 (WCT). The EU, the US
and Japan are contracting parties of the WCT.
8
Article 4 of WCT.
9
The substantive parts of recitals and articles of the Directive 2009/24/EC are kept intact
from those of the Council Directive 91/250/EEC except for minor changes in numberings
of paragraphs in Articles 2 and 4. As such, discussions of cases in the time of the Council
Directive 91/250/EEC also apply to the current Directive 2009/24/EC.

4
a) Scope of protection
The Directive states what is included in the term "computer programs"

instead of defining the term. For instance, Article 1(1) of the Directive states
that the "computer programs" include "preparatory design material." 10
Further, the "computer programs" may include any type of codes such as
source code 11 or object code 12 as well as programs in any type of
embodiments, for example, on a tangible medium (e.g. CD or DVD) or
embedded in hardware.13
A computer program shall be protected if it is original in the sense that it is

the author's own intellectual creation. 14 The creativity requirement is
considered to be met if a computer program "has not been copied and
displays some minimal level of individuality."15
The protection shall apply to "the expression in any form of a computer

program" and not to "ideas and principles which underlie any element of a
computer program, including those which underlie its interfaces." 16 The
Court of Justice of the European Union (hereinafter, "CJEU") ruled that, in
Case C-393/09, 17 a graphical user interface may not be regarded as an
"expression" of a computer program within the meaning of Article 1(2) of
the Directive thus may not be protected by copyright as a computer
10
See Recital 7 of the Directive; CONCISE EUROPEAN COPYRIGHT LAW 216 (Thomas Dreier
& P. Bernt Hugenholtz eds., 2006).
11
A form of computer programs written in a human readable programming language such
as JAVA, C or C++.
12
Another form of computer programs written in a machine readable code: a sequence of
"0" and "1". A source code has to be translated (compiled) into an object code in order for
a computer to execute the program.
13
CONCISE EUROPEAN COPYRIGHT LAW, supra note 10, at 216.
14
Article 1(3) of the Directive.
15
16
17
CJEU, Case C-393/09, Bezpečnostní softwarová asociace – Svaz softwarové ochrany v.
Ministerstvo kultury (2010).

5
program.18 Another decision by the CJEU for Case C-406/1019 found that
the functionality of computer programs may not be considered as the
expressions of a computer program, thus is outside the scope of copyright
protection under the Directive.20
b) Exclusive rights
The exclusive rights conferred to a rightholder for a computer program

under the Directive are (i) the reproduction right, (ii) the right of translation,
adaptation, arrangement and any other alteration and (iii) the distribution
right.21
The reproduction right set forth in Article 4(1)(a) of the Directive can cover
any copying that may occur during the processing of a computer program on
a computer.22 For example, when running a computer program, the program
must be copied from an external storage device (e.g. hard disk) to a
temporary memory (e.g. RAM (random access memory)) of the computer.
Further, communication of a computer program through a network (e.g. the
Internet) is also impossible without copying the program.
The alterations in Article 4(1)(b) of the Directive may include translation of

a computer program written in one programming language to another as
well as conversion of a source code to an object code and vice versa. 23
Article 4(1)(b) of the Directive further confers the rightholder of a computer
program the right to authorise the reproduction of the results of the
alterations.
18
Case C-393/09 para. 59 (note, however, that the CJEU left a room for copyright
protection for a graphic user interface in case the graphic user interface is "its author's own
intellectual creation.")
19
CJEU, Case C-406/10, SAS Institute Inc. v. World Programming Ltd (2012).
20
Case C-406/10 para. 35-39.
21
Article 4(1) of the Directive
22
Article 4(1)(a) of the Directive. For more detailed explanation, see CONCISE EUROPEAN
COPYRIGHT LAW, supra note 10, at 220-222.
23

6
A typical form of distribution envisaged by the distribution right stipulated

in Article 4(1)(c) of the Directive is distribution of a computer program
embodied in a tangible medium.24 Pure electronic distribution of a computer
program involving no tangible medium might also be considered within the
scope of the distribution right.25 Nevertheless, electronic distribution can be
covered by reproduction right since copying is inevitable for electronic
distribution of a computer program.
c) Exceptions of exclusive rights
Exceptions for the reproduction and alteration rights are prescribed in

Article 5 of the Directive. Reproductions and alterations necessary for the
use of a computer program by a lawful acquirer of the program may be
made without the authorisation of the rightholder.26 Making a back-up copy
may also be exempted from the reproduction right.27 A user having the right
to use a computer program may "reverse engineer" the program to identify
the underlying ideas and principles of the program.28
Decompilation of a computer program which involves reproduction and

translation of the program may be allowed in case it is indispensable to
achieve interoperability of another computer program created independent
of the computer program at issue.29
d) Exhaustion
The distribution right of a computer program exhausts within the EU by the

"first sale in the Community of a copy of a program by the rightholder or
24
25
Infra Part II.A.1.(d). But see Id (states an interpretation that electronic distribution
would not be covered by the distribution right).
26
27
28
29
Article 6 of the Directive.

7
with his consent."30 The exhaustion occurs only when a computer program
is "sold" but does not occur when a computer program is merely
"licensed." 31 In case of a sale of a tangible medium storing a computer
program, it is clear that the computer program is "sold" and the distribution
right exhausts. 32 Nowadays, however, provision of computer programs is
often made electronically through the Internet. A user can, in return for a
payment, download a computer program on his/her computer from a website
of the developer and, by agreeing to the license terms, can start using the
program.33 This type of provision of a computer program may be considered
as a "license" rather than a "sale" but the distinction is not always clear.
Regarding the license/sale distinction, the CJEU has recently issued a

decision for Case C-128/11 saying that download of a computer program
through the Internet may constitute a "first sale" within the meaning of
Article 4(2) of the Directive and thus may exhaust the distribution right.34
The CJEU interprets the term "sale" in Article 4(2) of the Directive broadly
to include "all forms of product marketing characterised by the grant of a
right to use a copy of a computer program, for an unlimited period, in return
for payment of a fee."35 By this interpretation of the term "sale," the CJEU
aims to prevent suppliers from "circumventing" the rule of exhaustion by
merely calling the contract a "license" rather than a "sale."36 It is notable
that the CJEU considered the exhaustion doctrine to be applicable to
intangible copies of a computer program. The CJEU found that, "from an
economic point of view, the sale of a computer program on CD-ROM or
DVD and the sale of a program by downloading from the internet are
similar" 37 and pointed out that Article 4(2) of the Directive "makes no
distinction according to the tangible or intangible form of the copy in
30
Article 4(2) of the Directive. See also CONCISE EUROPEAN COPYRIGHT LAW, supra note
10, at 224-25.
31
Thomas Dreier, The Council Directive of 14 May 1991 on the Legal Protection of
Computer Programs, 13(9) E.I.P.R. 319, 321-22 (1990)
32
Id. at 322.
33
See infra Part IV.A.
34
C-128/11, UsedSoft GmbH v. Oracle International Corp. (2012).
35
Id. at para. 49.
36
Id.
37
Id. at para. 61.

8
question."38
2. US
The US Copyright Act 39 was amended in 1980 to introduce statutory

copyright protection for computer programs.40 As a result, 17 U.S.C. §101
now provides a definition for a "computer program" as "a set of statements
or instructions to be used directly or indirectly in a computer in order to
bring about a certain result." Moreover, exceptions of the exclusive rights
for computer programs are prescribed in 17 U.S.C. §117.
A computer program enjoys copyright protection as a literary work if it is

original and fixed in any tangible medium of expression. 41 The originality
standard for protection requires the work to be independently created and to
demonstrate a minimal amount of creative authorship. 42 A computer
program created electronically and stored in a storage device upon its
completion may meet the fixation requirement.
The US Copyright Act protects the expression of a computer program but

not ideas of the program43 like in the EU and Japan. It is established in the
US that both source code and object code are copyrightable expressions.44 A
widely accepted test of the idea/expression dichotomy for computer
programs in the US is the abstraction-filtration-comparison test established
in Computer Associates International, Inc. v. Altai, Inc.45 The test includes
38
Id. at para. 55.
39
Copyright Act of 1976, 17 U.S.C. §§ 101-1332 (2011).
40
PL 96–517, DECEMBER 12, 1980, 94 Stat 3015 Sec. 10.
41
17 U.S.C §102 (a)
42
MARSHALL A. LEAFFER, UNDERSTANDING COPYRIGHT LAW 56, 57 (5th ed. 2010).
43
17 U.S.C. §102 (b) (prohibits copyright protection to extend to "any idea, procedure,
process, system, method of operation, concept, principle, or discovery").
44
Apple Computer, Inc. v. Franklin Computer Corp. 714 F.2d 1240, 1246-1249 (3d Cir.
1983); See also Deborah F. Buckman, Copyright Protection of Computer Programs, 180
A.L.R. FED. 1 §5[a], 5[b] (2002).
45
Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992)

9
three steps as its name suggests: abstraction, filtration and comparison. The
abstraction step involves dissecting the structure of the computer program at
issue and isolating each level of abstraction. 46 In the filtration step, the
structural components at each level of abstraction are examined and the
elements (a) dictated by efficiency, (b) dictated by external factors and (c)
taken from the public domain are filtered out. 47 What is left after the
filtration step would be a protectable expression.48 The comparison step is
made in order to determine infringement. The results of the filtration step
for programs of the rightholder and of the alleged infringer are compared to
determine the similarities of those programs.49
b) Exclusive rights
Among the six exclusive rights listed in 17 U.S.C. §106, rights of

reproduction, adaptation and distribution are the most relevant for a
computer program.
The reproduction right covers reproduction of the copyrighted work in

copies.50 The definition of the term "copies" in 17 U.S.C. §10151 suggests
that the "reproduction" requires fixation. The fixation requirement can be
met in an ordinary processing of a computer program by a computer. Even a
computer program copied to a RAM of a computer from a hard disk may
constitute a creation of a fixed copy of the program.52
The adaptation right is the right to do and to authorise preparing derivative

works based upon the copyrighted work.53 A "derivative work" is defined in
17 U.S.C. §101 as "a work based upon one or more preexisting works, such
46
Id. at 707.
47
Id. at 707-10.
48
Id. at 710.
49
Id. at 710-11.
50
17 U.S.C. §106(1).
51
17 U.S.C. §101 (defines the term "copies" as "material objects . . . in which a work is
fixed . . .").
52
MAI Systems Corp. v. Peak Computer, Inc., 991 F.2d 511, 518-19 (9th Cir. 1993).
53
17 U.S.C. §106(2).

10
as a translation . . . or any other form in which a work may be recast,

transformed, or adapted." 17 U.S.C. §101 further states that a derivative
work consists of editorial revisions, annotations, elaborations, or other
modifications, and represents an original work of authorship as a whole.
This definition suggests that a result of debugging or upgrading a computer
program may be regarded as a derivative work of the original program.
The right of distribution enables the copyright owner to exclude others from
distributing "copies . . . of the copyrighted work to the public by sale or
other transfer of ownership, or by rental, lease, or lending." 54 The
distribution right may cover both electronic and non-electronic distribution
of computer programs.55
c) Limitations of exclusive rights
The fair use doctrine56 provides general limitations of exclusive rights under
the US Copyright Act. 17 U.S.C. §107 prescribes the factors to consider
when determining whether an act qualifies as a fair use.
The US Copyright Act provides limitations specific to computer programs

in 17 U.S.C. §117. First, the owner of a copy of a computer program may
make another copy or adaptation of the program as an essential step in using
the computer program in conjunction with a machine and the other copy is
used in no other manner. 57 Second, the owner of a copy of a computer
program may make another copy or adaptation of the program for archival
purposes.58 Third, making a copy of a computer program may be allowed
for purposes of machine maintenance or repair.59
54
17 U.S.C. §106(3).
55
LEAFFER, supra note 42, at 326-27.
56
17 U.S.C. §107.
57
17 U.S.C. §117(a)(1).
58
17 U.S.C. §117(a)(2) (The owner of the copy of the program must, however, destroy the
all archival copies in case he/she ceases to be the owner of the copy of the program).
59
17 U.S.C. §117(c). This limitation was introduced in 1998 in response to the decision of
MAI, 991 F.2d where a maintenance service company was held liable for copyright
infringement by copying a copyrighted program onto a RAM of a computer during the
maintenance operation. See LEAFFER, supra note 42, at 322-24.

11
d) First sale doctrine
The first sale doctrine set forth in 17 U.S.C. §109 serves as a limitation of
the distribution right. The owner of a particular, lawfully made copy of a
computer program, or any person authorised by such owner is allowed to
sell or otherwise dispose of the possession of that copy without the authority
of the copyright owner. 60 The first sale doctrine corresponds to the
exhaustion in the EU.
The first sale doctrine only applies to a sale and not to a lease of a
copyrighted work. 61 In order to avoid the first sale doctrine, software
developers often choose to "license" rather than to "sell" their programs.62
Since the first sale doctrine enables redistribution only by the "owner" of a
copy of a copyrighted work,63 the key issue for the application of the first
sale doctrine is the ownership of a copy of a computer program. While a
"sale" of a computer program transfers the ownership of a copy of the
program to the recipient of the copy, a "license" keeps such ownership to the
distributor.
The license/sale distinction for computer programs has been controversial in

the US. In the 1990s, the US courts simply relied on the characterisation of
the transaction as a "license" by the copyright owner. 64 Later cases show
diverse approaches and outcomes.65
60
17 U.S.C. §109(a).
61
17 U.S.C. §109(d).
62
Christian H. Nadan, Software Licensing in the 21st Century: Are Software "Licenses"
Really Sales, and How Will the Software Industry Respond?, 32 AIPLA Q. J. 555, 559-60,
567 (2004)
63
17 U.S.C. §109(a).
64
See, e.g., MAI, 991 F.2d, at 518 n.5; Nadan, supra note 62, at 590-91; Brian W. Carver,
Why License Agreements Do Not Control Copy Ownership: First Sales and Essential
Copies, 25 BERKELEY TECH. L.J. 1887, 1899-1904 (2010).
65
Adobe Systems Inc. v. One Stop Micro, Inc., 84 F.Supp.2d 1086 (N.D.Cal. 2000) and
Adobe Systems Inc. v. Stargate Software Inc., 216 F.Supp.2d 1051 (N.D.Cal. 2002)
considered the distribution of the software by Adobe as a license by identifying languages
in the distribution agreement that indicated Adobe's intention to "license" the software and
to restrict redistribution. In contrast, SoftMan Products Company, LLC, v. Adobe Systems
Inc., 171 F.Supp.2d 1075 (C.D.Cal. 2001) focused more on "the economic realities of the

12
In 2010, the Ninth Circuit of the US Court of Appeals established, in Vernor

v. Autodesk, Inc., 66 criteria for determining the "license or sale" issue in
provision of software copies. The court ruled that "a software user is a
licensee rather than an owner of a copy where the copyright owner (1)
specifies that the user is granted a license; (2) significantly restricts the
user's ability to transfer the software; and (3) imposes notable use
restrictions."67 These criteria in Vernor were applied in two later cases by
the Ninth Circuit.68
The Vernor case dealt with distribution of physical copies of computer

programs. Whether the first sale doctrine applies to online distribution of
software is still unclear.69 The US Copyright Office has expressed a negative
view on application of the first sale doctrine to digitally transmitted
copyrighted work.70
3. Japan
In 1985, the reform of the Copyright Act of Japan (hereinafter "JCA") 71

introduced provisions in the JCA for protecting computer programs. 72 A
definition of a "computer program" was added as "an expression of a
combination of instructions to cause a computer to function in order to be
exchange" than the languages of the distribution agreement and concluded that a
transaction is a sale if the transaction "involves a single payment giving the buyer an
unlimited period in which it has a right to possession."
66
Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010).
67
Id. at 1111.
68
See MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010);
UMG Recordings, Inc. v. Augusto, 628 F.3d 1175 (9th Cir. 2011).
69
See generally Aaron Perzanowski & Jason Schultz, Digital Exhaustion, 58 UCLA L. REV. 889
(2011).
70
THE UNITED STATES COPYRIGHT OFFICE, EXECUTIVE SUMMARY DIGITAL MILLENNIUM COPYRIGHT ACT
§104 STUDY, III B.1. A. (August 2001), available at
http://www.copyright.gov/reports/studies/dmca/dmca_executive.html (accessed 4
August 2012) ("The tangible nature of a copy is a defining element of the first sale doctrine
and critical to its rationale").
71
CHOSAKUKENHŌ [Copyright Act (of Japan)], Act No. 48 of 6 May 1970, English
translation is available at http://www.japaneselawtranslation.go.jp/?re=02 (accessed 2
August 2012).
72
NOBUHIRO NAKAYAMA, CHOSAKUKENHŌ [Copyright Law] 96 (2007) [中山信弘, 著作権法
(2007)].

13
able to obtain a certain result" in Article 2(1)(x)-2 JCA and "computer

program works" was introduced as one of the examples of copyrightable
"work" in Article 10(1)(ix) JCA.
The "computer program works" of Article 2(1)(x)-2 JCA must, in order to

be copyrightable, express thoughts or sentiments in a creative way.73 It is
considered that most computer programs would meet the creativity
requirement except for very simple programs that would be identical no
matter who the creator is.74
Similarly to the EU and the US, copyright protection for a computer

program under the JCA covers the "expression"75 but not ideas underlying a
computer program. Article 10(3) JCA states that copyright protection for
computer program works shall not extend to any computer programming
language, rule or algorithm used for creating such works. Source codes and
object codes of a computer program may be considered as copyrightable
work since the codes are concrete expressions of the instructions for a
computer. Functions of a computer program, on the other hand, may not be
protected because the functions are regarded as ideas underlying the
computer program.
b) Exclusive rights
Article 17(1) JCA confers moral rights and copyrights to an author. The
moral rights include the right to make the work public, 76 the right to
determine the indication of the author's name 77 and the right to maintain
73
Article 2(1)(i) JCA.
74
KATO MORIYUKI, CHOSAKUKENHŌ CHIKUJŌ KŌGI [COPYRIGHT LAW CLAUSE-BY-
CLAUSE LECTURE] 120 (new 3rd ed. 2000) [加戸守行, 著作権法逐条講義, (三訂新版
2000)].
75
Articles 2(1)(i) and (x)-2 JCA.
76
Article 18(1) JCA.
77
Article 19(1) JCA.

14
integrity.78 The moral rights are regarded as the author's personal rights and
as exclusive to the author thus cannot be transferred.79 Among these moral
rights, the integrity right may be of the most relevance for a computer
program work because computer programs are subject to changes for
debugging and upgrades. As discussed later, the JCA provides exception for
integrity rights in certain cases of alterations of computer programs.
The copyrights are the economic aspect of the rights of the author. A
copyright is transferable in whole or in part.80 The JCA lists different types
of copyrights from Article 21 to 28. Among these, the most relevant for
computer programs are the right of reproduction, 81 the right of public
transmission, 82 the right of ownership transfer, 83 the right of translation,
adaptation, etc.84 and the right of the original author in the exploitation of a
derivative work.85
The "reproduction" must be in a "tangible form by means of printing,

photography, photocopy, sound or visual recording or other methods" under
the JCA.86 The reproduction does not necessarily be the exact copy of the
work.87 Automatic conversion of a source code of a computer program into
an object code is considered to be a reproduction.88
The public transmission right covers the provision of a computer program

through the Internet and the "making available" within the meaning of
78
Article 20(1) JCA.
79
Article 59 JCA.
80
Article 61(1) JCA.
81
Article 21 JCA.
82
Article 23 JCA.
83
This right may be considered as a form of a "distribution right" in the EU and the US. The
JCA distinguishes the "distribution right" for cinematographic work (which basically does
not exhaust by first sale) and that for other works (which can exhaust). The term
"distribution right" in the JCA is used only for cinematographic works and for other works
the term "the right of ownership transfer" is used. See Articles 26 and 26-2 JCA.
84
Article 27 JCA.
85
Article 28 JCA.
86
Article 2(1)(xv) JCA provides the definition of the term "reproduction."
87
NAKAYAMA, supra note 72, at 211.
88
Id.

15
Article 8 WCT.89 Thus, the upload of a computer program to a web server

may constitute infringement of the public transmission right.
The right of ownership transfer corresponds to the distribution right of

Article 6 WCT. 90 The right of ownership transfer covers the ownership
transfer of "the originals or reproductions" 91 and is considered to be
applicable only to tangible objects.92
The right of translation, adaptation, etc. is a right to "translate, arrange

musically or transform, or dramatize, cinematize, or otherwise adapt" a
copyrighted work.93 This right is regarded as a right to create a derivative
work.94
The right of the original author in the exploitation of a derivative work

secures for the author of the original work the right to authorise acts that
would infringe the copryrights of the derivative work. 95 The economic
exploitation of a derivative work requires authorisation from both authors of
the original work and of the derivative work.
c) Exceptions of exclusive rights
The JCA provides exceptions of the exclusive rights related to computer

program works. For example, as an exception to the integrity right, Article
20(2)(iii) JCA allows necessary alterations of a computer program work for
debugging and for change of hardware to execute the program.96
Exceptions of the reproduction and adaptation rights are prescribed in
89
FUMIO SAKKA, SHŌKAI CHOSAKUKENHŌ [DISCUSSION COPYRIGHT LAW] 270 (4th ed.
2010) [作花文雄, 詳解著作権法, (第４版 2010)].
90
Id. at 279.
91
Article 26-2(1) JCA.
92
SAKKA, supra note 89, at 279.
93
Article 27 JCA.
94
SAKKA, supra note 89, at 286.
95
Article 28 JCA. See also SAKKA, supra note 89, at 288-89.
96
SAKKA, supra note 89, at 244-45.

16
Articles 47-3, 47-4 and 47-8 JCA. Article 47-3(1) allows reproductions or
alterations by a lawful owner of a copy of a computer program work "if and
to the extent deemed necessary for" the owner's own use of the work. This
exception enables the owner of the copy to make back-up copies of the
program and alter the program for achieving compatibility with certain
hardware. 97 Such reproductions should not be preserved, however, if the
owner ceases to be the lawful owner of the copy.98
Articles 47-4 and 47-8 stipulates the exclusion of temporary reproductions

from the scope of the reproduction right. Article 47-4 involves temporary
reproductions made in case of maintenance and repair of a device with a
built-in memory. For instance, a computer program stored in a memory of a
device may be reproduced as a back-up before starting the maintenance or
repair of the device.99 Article 47-8 exempts temporary reproductions made
in a computer when using a computer program work. This exception covers
reproductions of a computer program into a RAM from a hard disk.
d) Exhaustion
The right of ownership transfer exhausts by ownership transfer with a

consent of the rightholder.100 A sale of a computer program work stored in a
tangible medium exhausts the ownership transfer right with regards to that
medium. So far there is no case law in Japan concerning the exhaustion of
the ownership transfer right of software for online sale, comparable to the
CJEU Case C-128/11. Such a case, however, would likely be dealt with the
public transmission right which does not exhaust under the JCA. The
exhaustion doctrine then would not be applied to online sale of software.
Article 26-2(2) JCA providing the exhaustion doctrine is considered to be a

mandatory provision, which makes contracts against Article 26-2(2) to be
97
Id. at 390.
98
99
SAKKA, supra note 89, at 391-92.
100

17
void. 101 Thus, an attempt to limit further sale of a software copy by

contractual agreement between the seller and the purchaser of the copy
might fail. Like in the US, software developers in Japan also characterise the
sale of software copies in tangible media as "license" rather than "sale."
Japanese courts have not decided on the license/sale distinction for software.
B. Patent
Patent right is an exclusive right to work a patented invention in return for a

disclosure of the invention to the public. Contrary to copyright protection
for which no formality is required, patent protection is given only after
examination by the relevant authority.
Copyright protection for a computer program covers only the expression

and not the underlying idea of the program. The borderline between the
expression and the idea may be controversial but no lawyer would find this
statement incorrect for describing the current legal framework. This
statement, however, can sound nonsense to an IT engineer. The most
difficult and fun part of programming for an engineer is to create a
102
sophisticated algorithm which enables fast, streamlined processing.
Writing source code based on an algorithm requires much less creativity
than designing the algorithm. Moreover, what gives value to a computer
program for users is the functions achieved by the program. 103 The
difference in expressions counts little if two programs offer the same
functions. Patent laws can complement this weakness of copyright
protection since patent protection covers inventions, ideas that can be
embodied in products and/or processes.
Unlike copyright law, there is no international legal basis shared across the
globe regarding patent protection for software. Big discussions have been
101
KATO, supra note 74 at 192.
102
See, e.g., Daniel J.M. Attridge, Challenging claims! Patenting computer programs in
Europe and the USA, 2001(1) I.P.Q. 22, 25 (2001).
103
Id.

18
made in the EU, the US and Japan whether or not to allow software patents
and to what extent if allowed.104 Although it is possible at the moment to
obtain patent protection for software in the three jurisdictions focused here,
the scope of allowability and protection varies by jurisdiction.
The attitude toward software patents is not internationally harmonised but

the structures of patent laws in different countries are similar. For instance,
the main procedure to obtain grant of a patent is the same in the EU, the US
and Japan.105 Once a patent is granted, the patentee is conferred an exclusive
right to prevent others from making, using, offering for sale, or selling
products of the invention or importing such products for these purposes
within the territory of the respective jurisdiction. 106 The judgement on
infringement is made based on the "all elements rule" where all elements of
the patented claim should be present in alleged infringing product in order
to prove infringement.
Patent laws in the EU, the US and Japan all require, for an invention to be
patented, that the invention is patent eligible subject matter, industrially
applicable, novel and involves inventive step (or non-obviousness in the US
term). The variety in the attitude toward software patents in different
jurisdictions can be seen most in the evaluation of the patent requirements.
Thus in this section, issues of patent requirements for software related
inventions in the three jurisdictions will be described.
104
For discussions in the US and the EU, see, e.g., MIKKO VÄLIMÄKI, THE RISE OF OPEN
SOURCE LICENSING 82-86, 94-101 (2005). For discussions in Japan, see, e.g., SAKKA, supra
note 89, at 726-29.
105
The general procedure is as follows: filing of a patent application including patent
claims and specification, examination by the Patent Office, rejection or grant of patent for
the application. See, e.g., European Patent Office (EPO), How to apply for a European
patent, at http://www.epo.org/applying/basics.html?hp=stagea (accessed 1 August 2012);
United States Patent and Trademark Office (USPTO), Process for Obtaining a Utility Patent,
at http://www.uspto.gov/patents/process/index.jsp (accessed 1 August 2012); Japan
Patent Office (JPO), Procedures for Obtaining a Patent Right, at
http://www.jpo.go.jp/cgi/linke.cgi?url=/tetuzuki_e/t_gaiyo_e/pa_right.htm (accessed 1
August 2012).
106
See Article 28 of TRIPS (at least the acts listed in this Article constitute patent
infringement in the EU, the US and Japan).

19
1. EU
The European Patent Convention (EPC)107 provides a centralised system of

granting patent rights within the Member States of the European Patent
Organisation. 108 While each Member State has its national patent law and
Patent Office, patent applications according to the EPC must be filed to and
examined by the European Patent Office (EPO). The granting of European
patents is centralised at the EPO but the enforcement of a European patent is
to be dealt with, according to Article 64(2) EPC, by national law in the
courts of respective Member States. Here, the practice at the EPO
concerning the grant of "computer-implemented inventions" 109 will be
described.
a) Statutory basis
Article 52(1) EPC states that "European patents shall be granted for any
inventions, in all fields of technology, provided that they are new, involve an
inventive step and are susceptible of industrial application."
The EPC does not define the term "invention" but stipulates what is
excluded from the patentable "invention" in Articles 52(2) and 52(3) EPC.
Articles 52(2)(c) and 52(3) EPC exclude programs for computers "as such"
from patentable subject matter.
b) Technicality issue
107
Convention on the Grant of European Patents (EPC) of 5 October 1973 as revised by the
Act revising Article 63 EPC of 17 December 1991 and the Act revising the EPC of 29
November 2000.
108
Consists of 38 Member States that are contracting states of the EPC. See EPO, Member
states of the European Patent Organisation, at http://www.epo.org/about-
us/organisation/member-states.html (accessed 1 August 2012).
109
Guidelines for Examination in the European Patent Office G-II 3.6 (status: 20 June 2012)
[hereinafter "EPO Guidelines"] available at http://www.epo.org/law-practice/legal-
texts/html/guidelines/e/g_ii_3_6.htm (accessed 2 August 2012).

20
In order to avoid the exclusion from patentable inventions based on Articles

52(2)(c) and 52(3) EPC, a program for computers must have a technical
character. 110 In other words, a program for computers having a technical
character is considered as patentable inventions within the meaning of
Article 52 EPC.111
When is a program for computers or other form of a computer-implemented

invention considered to have a technical character? The Boards of Appeal of
the EPO have developed case law on this question. In the case T 1173/97,
the Board ruled that a computer program has a technical character if the
program can, when it is run on a computer, bring about a "further technical
effect" going beyond the normal physical interactions between program
(software) and computer (hardware).112 The normal physical effects are, for
example, electrical currents occur in a computer while executing a computer
program.113 This "further technical effect" may be known in the prior art.114
Decisions for cases T 258/03115 and T 424/03116 show that claim categories
make little difference in assessing the technical character of a claimed
invention. The development of these case law was confirmed by the
Enlarged Board of Appeal in its decision G 03/08 issued on 12 May 2010 in
response to a referral by the President of the EPO concerning the
patentability of programs for computers.117
To sum up, mere recitation of some technical means (e.g. hardware) in a

patent claim can avoid the exclusion from the patentable subject matter
110
Id. at G-II 1 (states that "an 'invention' within the meaning of Art. 52(1) must be of both
a concrete and a technical character."). See also T 1173/97, Computer program
product/IBM, 1999 OJ EPO 609, point 5.1 (1998); G 03/08, Programs for computers
(2010).
111
EPO Guidelines, supra note 109, at G-II 3.6. See also T 1173/97 at point 5.3.
112
T 1173/97 at point 6, 9.
113
Id. at point 6.2, 6.3.
114
Id. at point 8.
115
T 258/03, Auction method/HITACHI, 2004 OJ EPO 575 (2004) (ruled that "a method
involving technical means" has a technical character).
116
T 424/03, Clipboard formats I/MICROSOFT (2006) (found that "a method
implemented in a computer system" and "a computer-readable medium" to have a
technical character).
117
G 03/08, Programs for computers (2010).

21
under Articles 52(2)(c) and 52(3) EPC and thus makes the claim patent
eligible within the meaning of Article 52(1) EPC.118 The claim category and
prior arts are not considered in assessing the technical character. 119 A
claimed invention with a mixture of technical and non-technical features
may still be considered as patentable subject matter if the invention has a
technical character. 120
Although the patentable subject matter requirement can be cleared by

reciting technical means in a claim, the issue of technicality comes into
place in the assessment of the inventive step under Article 56 EPC. That is,
only technical features in a claimed invention are considered for assessing
the inventive step.121 For instance, in case T 258/03, the Board accepted the
claimed invention as patentable subject matter under Article 52 EPC, but
still found it to be unpatentable because of the lack of inventive step by
denying to consider non-technical features in the assessment of the
inventive step.122 Further, the Board for the case T 641/00 allowed "a mix of
technical and non-technical features to be claimed"123 but pointed out that
"where a feature cannot be considered as contributing to the solution of any
technical problem by providing a technical effect it has no significance for
the purpose of assessing inventive step"124 and considered only the technical
features for the assessment of inventive step.
c) Other requirements for patentability
Other requirements for patentability such as novelty 125 and industrial
118
EPO Guidelines, supra note 109, at G-II 3.6 ("the mere inclusion of a computer, a
computer network, a readable medium carrying a program, etc. in a claim lends technical
character to the claimed subject-matter.").
119
Id. ("The examiner should disregard the claim category and concentrate on its content
in order to determine whether the claimed subject-matter, considered as a whole, has a
technical character." "Technical character should be assessed without regard to the prior
art (see T 1173/97, confirmed by G 3/08).")
120
T 641/00, Two identities/COMVIK, 2003 OJ EPO 352 (2002).
121
EPO Guidelines, supra note 109, at G-VII 5-4.
122
T 258/03, at point 5.7.
123
T 641/00, at point 4.
124
Id. at point 6.
125
Article 54 EPC.

22
applicability126 for a computer-implemented invention are evaluated in the

same way as other types of inventions and particularly no distinction is
made as to whether a specific feature has a technical character or not.
2. US
The US has been the most generous jurisdiction for software patents among
the EU, the US and Japan. Patent law of the US has its root in the
Constitution of the US,127 which indicates that the US as a nation places
high value on inventive activities.
a) Statutory basis
Statutory invention under the US Patent Act 128 should be "any new and
useful process, machine, manufacture, or composition of matter, or any new
and useful improvement thereof."129 As this language of the statute does not
tell much about patentability of software-related inventions, substantial
evaluations have been made by the courts.
b) Case law development on patent eligibility
The US case law on patent eligibility of software-related invention has a

tortuous history. In 1970s, the US Supreme Court decided on two cases,
Gottschalk v. Benson130 and Parker v. Flook,131 in which the Court denied
patent protection for mathematical formula performed in a computer. In
these two cases, the Court rejected the patent eligibility of the inventions at
issue to avoid patenting an algorithm itself.132 Benson further set out criteria
for process inventions to be patent eligible: "a process patent must either be
126
Article 57 EPC.
127
U.S. CONST. art. I, § 8, cl. 8.
128
The United States Patent Act, 35 U.S.C. §§ 1-318 (2007).
129
35 U.S.C. §101.
130
Gottschalk v. Benson, 409 U.S. 63 (1972).
131
Parker v. Flook, 437 U.S. 584 (1978).
132
Benson, 409 U.S., at 71-72; Flook, 437 U.S., at 590.

23
tied to a particular machine or apparatus or must operate to change articles

or materials to a ‘different state or thing.’"133
Following these two decisions, the US Supreme Court accepted granting a

patent to a specific application of a mathematical algorithm in Diamond v.
Diehr 134 in 1981. Although the claimed method included steps performed
using a mathematical equation and a computer, 135 the Court found this
invention patent eligible because it involves "the transformation of an article,
in this case raw, uncured synthetic rubber, into a different state or thing"136
and the protection sought was not for a mathematic formula but for a
process of curing synthetic rubber.137 Further, Diehr confirmed that "laws of
nature, natural phenomena, and abstract ideas" are excluded from patent
eligible subject matter under 35 U.S.C. §101.138
After Diehr, the US courts moved toward looser requirements for software
patents139 and in 1998, the Federal Circuit decided on State Street Bank &
Trust Co. v. Signature Financial Group, Inc140 in which the Federal Circuit
ruled that an invention is patent eligible if the invention produces "a useful,
concrete and tangible result." 141 This standard does not even require a
recitation to a machine in the claim for the claimed invention to be patent
eligible. The State Street Bank decision opened the way to generous granting
of software-related patents by the USPTO. 142 Until the Federal Circuit
decided on In re Bilski143 in 2008, almost no limits were posed on software
133
Benson, 409 U.S., at 71.
134
Diamond v. Diehr, 450 U.S. 175 (1981).
135
Id. at 185.
136
Id. at 184. See also supra note 133 and accompanying text.
137
Diehr, 450 U.S., at 187.
138
Id. at 185.
139
For discussions on the case law development after Diehr until 1998, see Julie E. Cohen
& Mark A. Lemley, Patent Scope and Innovation in the Software Industry, 89 CAL. L. REV. 1,
9-11 (2001).
140
State Street Bank & Trust Co. v. Signature Financial Group, Inc, 149 F.3d 1368 (Fed. Cir.
1998).
141
Id. at 1373.
142
Cohen & Lemley, supra note 139, at 11-13.
143
In re Bilski, 545 F.3d 943 (Fed. Cir. 2008)

24
patents with respect to patent eligibility.144
The Federal Circuit abandoned, in In re Bilski, the "useful, concrete and

tangible result" inquiry adopted in State Street Bank.145 Instead the Federal
Circuit endorsed, as a sole test, the "machine-or-transformation test"
established by the Supreme Court decisions including Benson, Flook and
Diehr. 146 Under the machine-or-transformation test, a claimed process is
patent eligible "if: (1) it is tied to a particular machine or apparatus, or (2) it
transforms a particular article into a different state or thing."147 The case
went up to the Supreme Court. The Supreme Court agreed to the Federal
Circuit that the claimed process in In re Bilski is not patent eligible but
based on a different reasoning: the claimed process is an abstract idea.148
The Supreme Court rejected to use the machine-or-transformation test as the
sole test while acknowledging this test as "a useful and important clue" for
determining patent eligibility.149
The Supreme Court decision of Bilski gives little guidance for the practical
question on what should be deemed a patent eligible invention. After all, "no
one understands what makes an idea 'abstract,' and hence ineligible for
patent protection."150 Relying on the comment by the Supreme Court that
the machine-or-transformation test being "a useful and important clue" for
the determination of patent eligibility, the US practitioners including
USPTO Examiners continue to use the machine-or-transformation test.151
144
Mark A. Lemley, Michael Risch, Ted Sichelman & R. Polk Wagner, Life After Bilski, 63
STAN. L. REV. 1315, 1318 (2011) ("For a decade after 1998, patentable subject matter was
effectively a dead letter.").
145
In re Bilski, 545 F.3d, at 959-60.
146
In re Bilski, 545 F.3d, at 959-61.
147
In re Bilski, 545 F.3d, at 954.
148
Bilski v. Kappos, 130 S.Ct. 3218, 3229-30 (2010).
149
Id. at 3227.
150
Lemley, Risch, Sichelman & Wagner, supra note 144, at 1316.
151
Id. See also USPTO, Interim Guidance for Determining Subject Matter Eligibility for
Process Claims in View of Bilski v. Kappos, 75 Fed. Reg. 43922, 43925 (July 27, 2010)
(The guidance for the USPTO Examiners clearly relies on the machine-or-transformation
test).

25
In order to be granted patent, a claimed invention has to meet requirements

of novelty, 152 non-obviousness153 and written description.154 Assessment of
these requirements for software-related inventions is made in a same way as
for other types of inventions. Unlike in the practice at the EPO, no
technicality issue arises in the US when assessing the non-obviousness or
inventive step.
3. Japan
While the EU and the US take very different approaches for the patentability
of software-related inventions, Japan takes yet another approach which will
be described in this section.
a) Statutory basis
The Patent Act of Japan (hereinafter "JPA")155 provides a definition of the

term "invention" as "highly advanced creation of technical ideas utilizing
the laws of nature" in Article 2(1). Under the JPA, an invention of a
computer program is considered as an invention of a product.156 Note that it
is allowed by the statute to claim a "program" by itself in Japan.157
Article 29 JPA stipulates three requirements for patent protection: industrial

applicability, 158 novelty 159 and inventive step. 160 In order to be granted a
patent, an invention must fall within the definition of statutory "invention"
152
35 U.S.C. §102.
153
35 U.S.C. §103.
154
35 U.S.C. §112.
155
TOKKYOHŌ [Patent Act (of Japan)], Act No. 121 of 13 April 1959, English translation
available at http://www.japaneselawtranslation.go.jp/?re=02 (accessed 2 August 2012).
156
Article 2(3)(i) JPA (stating that the term "product" includes a "computer program, etc.").
See also Article 2(4) (defines a "computer program" as "a set of instructions given to an
electronic computer which are combined in order to produce a specific result").
157
Id.
158
Article 29(1), main paragraph, JPA.
159
Article 29(1)(i)-(iii) JPA.
160
Article 29(2) JPA.

26
under Article 2(1) JPA as well as meet the requirements set forth in Article
29 JPA.
b) Statutory "invention"
The phrase "utilizing the laws of nature" in the definition of statutory

invention under Article 2(1) JPA is the key to determine patent eligibility
under the Japanese approach. In general, this phrase is interpreted to exclude
mere mental activities, pure academic theorems, artificial arrangements, etc.
from statutory inventions.161 Further, a law of nature in itself (e.g. the law of
gravity) is not deemed to be a statutory invention because a law of nature in
itself does not use the laws of nature.162 The courts in Japan have also relied
on the criteria of "utilizing the laws of nature" for determining whether an
invention is statutory.163
For software related inventions, the criterium of "utilizing the laws of

nature" is a challenge to patent eligibility. Since software is after all just a
set of instructions for a computer, software is not intuitively understood as
using the laws of nature. Reflecting the particularity of software, the
Examination Guidelines for Patent and Utility Model in Japan issued by the
JPO include a dedicated chapter for the examination of "computer software-
related inventions." 164 According to the JPO Guidelines, whether the
“information processing by software is concretely realized by using
hardware resources” is to be assessed in determining patent eligibility of
software related inventions.165 Practical meaning of this assessment method
is difficult to figure out. It is understood that mere recitation of hardware
161
NOBUHIRO NAKAYAMA, TOKKYOHŌ [PATENT LAW] 94 (2010) [中山信弘, 特許法
(2010)].
162
Id. at 95.
163
See, e.g., Tōkyō Kōtō Saibansho [Tokyo High Ct.] 28 February 1950, Sho 23 (na) No. 5;
Tōkyō Kōtō Saibansho [Tokyo High Ct.] 14 November 1953, Sho 26 (na) No. 12 (methods
for creating codes for telegrams were denied to be statutory inventions because those
methods did not utilise the laws of nature). See also Tōkyō Kōtō Saibansho [Tokyo High
Ct.] 25 December 1956, Sho 31(na) No. 12 (ruled that a method to show advertisement
boards on a power pole is not utilising the laws of nature and thus not patent eligible.)
164
JPO, Examination Guidelines for Patent and Utility Model in Japan, Part VII, Chapter 1
Computer Software-Related Inventions (2011) [hereinafter "JPO Guidelines"].
165
Id. at VII-1 2.2.1(1).

27
elements such as CPU and memory in a claim is not enough for the claimed
invention to be deemed statutory. 166 The claim should recite "how" the
hardware elements are used in the processing instructed by the software. In
practice, the claim language should clearly specify (i) which hardware
element performs what processing, (ii) what are the input and output of each
processing and (iii) the content of each processing.
Recent cases decided by the Intellectual Property High Court show that an
invention involving a non-patentable element such as human mental
activities may be deemed statutory if the invention "as a whole" provides a
technical means by utilising the laws of nature.167
The assessment of novelty 168 and inventive step 169 for software related
invention in Japan is not different from that for other types of invention. No
distinction is made between technical and non-technical features in a
claimed invention when assessing inventive step as it is in the practice at the
EPO.
166
E.g., Chitekizaisan Kōtō Saibansho [IP High Ct.] 29 February 2008, Hei 19 (ke) No.
10239 (denied patent eligibility on a method for generating shortened representation of a
bit string even though the claim recited arithmetic device, finding that the method is just a
mathematical algorithm which does not utilise the laws of nature).
167
Chitekizaisan Kōtō Saibansho [IP High Ct.] 24 June 2007, Hei 19 (ke) No. 10369 (ruled
that, even when an invention includes human mental activities, if the essence of the
invention as a whole provides a technical means to assist or substitute the mental activities,
the invention should not be excluded from statutory inventions); Chitekizaisan Kōtō
Saibansho [IP High Ct.] 31 October 2007, Hei 19 (ke) No. 10056 (found a method for using
a medical bag with a cutting line to be a statutory invention); Chitekizaisan Kōtō Saibansho
[IP High Ct.] 26 August 2008, Hei 20 (ke) No. 10001 (stated that if, when considering the
contents of a claimed invention as a whole, an invention involves a creation of a technical
idea utilising the laws of nature as its main technical means to solve a certain problem, then
the invention should be deemed statutory); See also NAKAYAMA, supra note 161, at 100-01.
168
Article 29(1)(i)-(iii) JPA.
169
Article 29(2) JPA.

28
III. Open source licenses
A. History of open source licenses
The idea of open source originates from the free software movement started
by Richard Stallman in 1983 as the start of the GNU Project. 170 When
Stallman worked at the Artificial Intelligence Laboratory of the
Massachusetts Institute of Technology in 1970s, it was common practice for
computer programmers to share source codes and develop software in a
171
collaborative manner. By the 1980s, however, most software was
172
copyrighted, which motivated Stallman to start the free software
movement in order to secure the free, cooperative style of software
development. Stallman left the MIT in 1984 and started working on the
GNU Project, a development project of UNIX compatible, free operating
system which he named "GNU."173 The term GNU is a "recursive acronym"
for "GNU's Not Unix."174 The Free Software Foundation (FSF) was founded
in 1985 to support the development of the GNU Project.175
Free software means that "the users have the freedom to run, copy, distribute,
study, change and improve the software" according to the definition by the
FSF.176 The FSF considers a computer program to be "free software" if the
users of the program have the freedom to: (i) run the program, for any
purpose (freedom 0), (ii) study how the program works, and change it so it
does what the user wishes (freedom 1), (iii) redistribute copies (freedom 2)
and (iv) distribute copies of the users' modified versions to others (freedom
170
Richard Stallman, The GNU Project, at http://www.gnu.org/gnu/thegnuproject.html
(accessed 4 August 2012); FSF, Overview of the GNU System, at
http://www.gnu.org/gnu/gnu-history.html (accessed 4 August 2012).
171
Id.
172
Note that the US Copyright Act reform to include protection of computer programs was
in 1980. See supra note 40 and accompanying text.
173
FSF, supra, note 170. See also, Linux.org, What is Linux, at
http://www.linux.org/article/view/what-is-linux (accessed 10 August 2012).
174
FSF, supra, note 170.
175
Id.
176
FSF, The Free Software Definition, at http://www.gnu.org/philosophy/free-sw.html
(accessed 4 August 2012).

29
3).177 The term "free" refers to the "freedom" instead of "free of charge."178
For implementing the philosophy of the free software, the FSF has created
the GNU General Public License (GPL) which secures the above four
freedoms for the users of the programs and modifications thereof.179
In the meantime, Linus Torvalds, at the time a student at the University of

Helsinki, was working on the development of the Linux operating system.
Torvalds adopted the development style for the Linux to take into account
"users' comments and suggestions for improvements,"180 which accords with
the philosophy of the FSF. By 1991, Torvalds had completed the kernel181 of
his operating system and the GNU Project had developed other components
except for the kernel. 182 Torvalds and Stallman decided to combine the
Linux kernel and the GNU system into a complete operating system,
GNU/Linux system.183 Since then, the Linux has been distributed under the
GPL. As the number of users of the Linux has grown, the GPL and the idea
of free software movement have gained more recognition.
Although the FSF has repeatedly emphasised that the term "free" of the
"free software" refers to "freedom" and not to price,184 it is difficult, if not
impossible, to completely avoid misunderstanding the term. Moreover, the
strong philosophy of the FSF that all source codes should be "free" can
make businesses involving proprietary software to stay away from the free
software. Eric Raymond, one of the founders of the Open Source Initiative
(OSI), and his collaborators aimed to "dump the moralizing and
confrontational attitude that had been associated with 'free software' in the
past and sell the idea strictly on the same pragmatic, business-case grounds"
177
Id.
178
Id. (stating that free software is a "matter of liberty, not price.").
179
See, infra Chapter III.C.1.
180
Linux.org, supra note 173. See also, Eric Raymond, The Cathedral and the Bazaar (1997),
at http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html
181
Kernel is a basic component of an operating system that manages interactions between
hardware (such as CPU and memory) and software. See also Linux.org, supra note 173.
182
Id. See also, FSF, supra, note 170.
183
Id.
184
FSF, supra note 176.

30
and invented a new term "open source" in 1997.185 The OSI was founded in
1998 to promote the new "open source" activities.186
The substantial idea of "free" promoted by the FSF and that of "open
source" promoted by the OSI are almost the same. 187 The OSI, however,
takes more a generous stance to the needs of proprietary software
developers.
In this thesis, the term "open source" refers to both "free" defined by the
FSF and "open source" defined by the OSI, unless otherwise specified.
B. Mechanism of open source licenses
1. Open Source Definition
An open source license is a form of copyright license for computer

programs.188 The creator of a computer program retains his/her copyright on
the program and licenses others to use the program according to the terms
defined in the open source license.189 A software copyright license is called
"open source license" if the license complies with the ten criteria set forth in
the "Open Source Definition"190 issued by the OSI. The ten criteria are as
follows:
1. Free Redistribution
The license shall not restrict any party from selling or giving away
the software as a component of an aggregate software distribution
185
Open Source Initiative, History of OSI, at http://opensource.org/history/ (accessed 4
August 2012).
186
Id.
187
FSF, Categories of free and non-free software, at
http://www.gnu.org/philosophy/categories.en.html (Acessed 4 August 2012). ("[N]early
all free software is open source, and nearly all open source software is free.")
188
See, e.g., Alan Stern & A. Clifford Allen, Open Source Licensing, 985 PLI/PAT 321, 334
(2009).
189
Id.
190
OSI, The Open Source Definition, at http://www.opensource.org/docs/osd (accessed 4
August 2012).

31
containing programs from several different sources. The license shall

not require a royalty or other fee for such sale.
2. Source Code
The program must include source code, and must allow distribution
in source code as well as compiled form. Where some form of a
product is not distributed with source code, 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. The source code must be the preferred form
in which a programmer would modify the program. Deliberately
obfuscated source code is not allowed. Intermediate forms such as
the output of a preprocessor or translator are not allowed.
3. Derived Works
The license must allow modifications and derived works, and must
allow them to be distributed under the same terms as the license of
the original software.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in
modified form only if the license allows the distribution of "patch
files" with the source code for the purpose of modifying the program
at build time. The license must explicitly permit distribution of
software built from modified source code. The license may require
derived works to carry a different name or version number from the
original software.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of
persons.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program
in a specific field of endeavor. For example, it may not restrict the
program from being used in a business, or from being used for
genetic research.
7. Distribution of License

32
The rights attached to the program must apply to all to whom the
program is redistributed without the need for execution of an
additional license by those parties.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's
being part of a particular software distribution. If the program is
extracted from that distribution and used or distributed within the
terms of the program's license, all parties to whom the program is
redistributed should have the same rights as those that are granted in
conjunction with the original software distribution.
9. License Must Not Restrict Other Software
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.
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual
technology or style of interface. 191
As can be seen from the above Open Source Definition, the core feature of
open source licenses is that they must allow access to the source code of the
licensed program. Further, open source licenses must allow redistribution of
the licensed program, modifications to the licensed program and distribution
of the modifications without any royalty fees. Nevertheless, under an open
source license, it is possible to charge a fee in return to distribution of OSS.
What is prohibited for a licensor of OSS is to demand royalty payment to a
licensee, a recipient of the OSS, when the licensee chooses to redistribute
(either with or without charging a fee) the OSS or its modifications.
2. Copyleft
Some open source licenses require redistribution of the licensed software or
191
Id.

33
its modifications under the same license terms as the licensed software.192
This feature of open source licenses is called "copyleft."193 The concept of
"copyleft" was created by Richard Stallman and the FSF explains this
concept as "a general method for making a program (or other work) free,
and requiring all modified and extended versions of the program to be free
as well."194
"Copyleft" is a mechanism to secure the right or freedom for users of

redistributed software. A first-hand recipient of OSS certainly has the
freedom to use and modify the source code of the OSS.195 When the OSS or
its modification is redistributed from the first-hand recipient, whether or not
the OSS is licensed under a copyleft license makes a difference for the users
of the redistributed software. In case of the OSS is licensed under non-
copyleft license, redistribution can be made under proprietary license
without disclosing the source code, which means the user of the
redistributed software no longer has the freedom to access the source code.
In contrast, if the OSS is licensed under a copyleft license, redistribution
should be made under the same copyleft license terms. That is, the user of
the redistributed software would have the same freedom to access the source
code as the first-hand recipient of the OSS.
The copyleft effect of an open source license can be problematic for

developers of proprietary software. 196 If OSS with a copyleft license and
proprietary software are combined to create new software, the developer
may be required to disclose the source code of the new software as a whole,
including the source code of the proprietary software. Since the copyleft
effect of an open source license makes redistributed software to be licensed
under the same open source license terms as the original OSS, copyleft
192
The most famous open source license of this type is the GPL.
193
FSF, What is Copyleft, at http://www.gnu.org/copyleft/copyleft.en.html (accessed 4
August 2012).
194
Id.
195
See supra note 191 and accompanying text.
196
See infra Part IV.C.3.

34
licenses are referred to as "viral" or "contaminating."197 As described in the

next section, not all open source licenses have the copyleft effect.
C. Major open source licenses
This section will provide an overview of major open source licenses. Open
source licenses may be classified based on how strong their copyleft effects
are.
1. GNU General Public License (GPL)
The GPL is one of the most famous open source licenses. Because the GPL
was created by the FSF in order to implement the "copyleft" concept,198 the
GPL is famous for its strong copyleft effect. Currently, the latest version of
the GPL is version 3 (GPLv3) published on 29 June 2007.199
The preamble of the GPLv3 clearly states that its license terms are built
upon existing copyright system: the developers "(1) assert copyright on the
software, and (2) offer you this License giving you legal permission to copy,
distribute and/or modify it."200 When the licensee violates the terms of the
GPL, the rights granted by the GPL will be automatically terminated, which
may make the licensee to be an infringer of the copyright on the software.201
The copyleft effect of the GPL applies to the redistribution of verbatim

copies of the GPLed program 202 and programs based on the GPLed
program.203 Redistribution of GPLed program and programs based on the
197
Stern & Allen, supra note 188, at 343.
198
FSF, supra note 193. ("Copyleft is a general concept, and you can't use a general
concept directly; you can only use a specific implementation of the concept.")
199
GNU GENERAL PUBLIC LICENSE VERSION 3 (GPLv3), at http://www.gnu.org/licenses/gpl-
3.0.txt (accessed 4 August 2012). For discussions on differences between GPLv3 and the
previous version GPLv2, see Stern & Allen, supra note 188, at 350-52, 354-56.
200
GPLv3, preamble.
201
Id. at section 8.
202
Id. at section 4.
203
Id. at section 5.

35
GPLed program must accompany the source code or at least an access to the
source code and must be licensed under the GPL.204 A program is based on
the GPLed program, if the program is copied from GPLed program (but not
an exact copy) or if the program is adapted all or part of GPLed program in
a fashion requiring copyright permission. 205 However, the output from
running a GPLed program will not be covered by the GPL if the output does
not contain GPLed program nor programs based on GPLed program. 206
Programs simply stored in a same storage medium together with GPLed
programs which, however, are not combined with GPLed programs are also
out of scope of the copyleft effect.207
To protect the developers and the authors of the GPLed programs, GPL
clearly states that there is no warranty for the software.208 The GPL does
allow, however, the licensor to provide warranty protection for a fee.209
The preamble of the GPLv3 denies software patents in aggressive terms:
[E]very program is threatened constantly by software patents. States

should not allow patents to restrict development and use of software
on general-purpose computers, but in those that do, we wish to avoid
the special danger that patents applied to a free program could make
it effectively proprietary. To prevent this, the GPL assures that
patents cannot be used to render the program non-free.210
Section 11 of the GPLv3 serves to achieve the above goal specified in the
preamble. The patent terms set forth in Section 11 were added to the GPL
when the GPLv3 was drafted. Under Section 11 of the GPLv3, the licensor
("contributor") grants the licensee "a non-exclusive, worldwide, royalty-free
204
Id. at sections 4-6.
205
Id. at section 0.
206
Id. at section 2, the third sentence of the first paragraph.
207
Id. at section 5, second paragraph.
208
Id. at preamble, sections 15-17.
209
Id. at section 4.
210
Id. at preamble.

36
patent license under the contributor's essential patent claims, to make, use,
sell, offer for sale, import and otherwise run, modify and propagate the
contents of its contributor version." The contributor's "essential patent
claims" include all patent claims "owned or controlled by the
contributor."211 The term "control" is defined to include the right to grant
patent sublicenses in a manner consistent with the requirements of
GPLv3. 212 The essential patent claims encompass claims both already
acquired at the time of licensing and acquired afterward. 213 It should be
noted that the essential patent claims do not include claims "that would be
infringed only as a consequence of further modification of the contributor
version."214
In case the contributor distributes a program under the GPLv3, knowing that
the program includes a patent protected program, the contributor must take
an action to enable the downstream recipients to have the right to access and
use the source code under the terms of the GPLv3 without being accused of
patent infringement.215
The sixth and seventh paragraphs of Section 11 of the GPLv3 were

introduced to deal with an agreement made between Microsoft and Novell
(provider of Linux system) in 2006 not to sue each other's customers for
patent infringement. 216 The sixth paragraph of Section 11 of the GPLv3
stipulates that a patent license granted with respect to a GPLed program to
some of the parties receiving the GPLed program automatically extends to
all recipients of the GPLed program and programs based on it. Under the
agreement between Microsoft and Novell, Microsoft agreed to grant patent
licenses to Linux users who are customers of Novell. Such a grant of patent
211
Id. at section 11, second paragraph.
212
Id.
213
Id.
214
Id.
215
Id. at section 11, fifth paragraph.
216
Rowan Wilson, GPL v3 - What's New?, OSS Watch (2007), at http://www.oss-
watch.ac.uk/resources/gpl3final.xml#body.1_div.6 (accessed 4 August 2012); Brett Smith,
A Quick Guide to GPLv3, at http://www.gnu.org/licenses/quick-guide-gplv3.html (accessed
4 August 2012).

37
licenses would extend to all Linux users under the sixth paragraph of
Section 11 of the GPLv3. The seventh paragraph of Section 11 of the
GPLv3 attempts to discourage distributors of GPLed programs to enter into
an agreement such as the one made between Microsoft and Novell.217 Under
the seventh paragraph of Section 11 of the GPLv3, a party to such an
agreement may not distribute GPLed programs.218
The licensor of GPLed software "may not initiate litigation (including a

cross-claim or counterclaim in a lawsuit) alleging that any patent claim is
infringed by making, using, selling, offering for sale, or importing" the
software in whole or a part.219
2. GNU Lesser General Public License (LGPL)
The GNU Lesser General Public License (LGPL)220 is also published by the
FSF. The LGPL is a license used for library programs that are linked to
other programs. Currently, the latest version of the LGPL, LGPLv3,221 was
published on 29 June 2007, the same day as the publication of the GPLv3.222
The LGPLv3 stipulates additional permissions supplementing the GPLv3.223

The copyleft effect of the LGPLv3 applies only to the library programs
licensed under the LGPLv3 and not to other programs that are linked to
these library programs. The recipient of a library program under the
LGPLv3 may distribute "Combined Work" created by linking or combining
LGPLed library and other programs under license terms different from the
LGPLv3, provided that the part of the Combined Work that corresponds to
217
HEATHER J. MEEKER, THE OPEN SOURCE ALTERNATIVE: UNDERSTANDING RISKS AND
LEVERAGING OPPORTUNITIES 255 (2008).
218
GPLv3, section 11, seventh paragraph.
219
GPLv3, section 10, 3rd paragraph.
220
FSF, GNU Lesser General Public License, at http://www.gnu.org/copyleft/lesser.html
221
GNU LESSER GENERAL PUBLIC LICENSE VERSION 3 (LGPLv3), at
http://www.gnu.org/licenses/lgpl-3.0.txt (accessed 4 August 2012).
222
Id.
223
Id. at preamble.

38
the LGPLed library is kept LGPLed.224
3. Mozilla Public License (MPL)
The Mozilla Public License (MPL) 225 is created and managed by the
Mozilla Foundation. The MPL is used as a license for the Firefox web
browser and the Thunderbird email application.
The MPL has a "file-level" copyleft effect. 226 When distributing a work
created by combining a non-MPL program file and an MPLed program file,
only the source code of the MPLed program file must be disclosed. 227
Source codes of the non-MPL program files can be kept undisclosed.
The MPL includes a patent license clause in which the creator

("contributor") of an MPLed program grants the licensee a world-wide,
royalty-free, non-exclusive license under patent claims of the contributor to
make, use, sell, offer for sale, have made, import, and otherwise transfer the
MPLed program distributed by the contributor.228 Here, the "patent claims
of the contributor" means any patent claim(s), including without limitation,
method, process, and apparatus claims, in any patent that the contributor has
the right to authorise the actions that would be infringing without the license
granted in the patent license clause with respect to the MPLed program.229
4. Apache License
224
See LGPLv3, section 4 (The distributor must provide source code corresponding to the
LGPLed library but does not have to provide source code corresponding to other programs
linked to the LGPLed library).
225
MOZILLA PUBLIC LICENSE VERSION 2.0 (MPL 2.0), at http://www.mozilla.org/MPL/2.0/
226
MPL 2.0 FAQ, Q1, Q11, at http://www.mozilla.org/MPL/2.0/FAQ.html (accessed 4
August 2012).
227
MPL 2.0, section 3.3.
228
Id. at section 2.1.b.
229
Id. at section 1.11.

39
The Apache License230 is one of the Berkeley Software Distribution (BSD)

style licenses. The Apache License has no copyleft effect. As long as
conditions on attribution and notices of information specified in Section 4 of
the Apache License 2.0 are met, redistribution of the covered program and
its modifications can be made under any license terms of the distributor's
choice, even without disclosing the source code. That is, software licensed
under the Apache License can be turned into proprietary software without
violating the terms of the Apache License. A non-copyleft license like the
Apache License is called a permissive license. The Apache License also
includes a patent license clause in Section 3.
D. Legal issues around open source licenses
1. Enforceability: contractual covenant or license condition?
Enforceability of open source licenses had been unclear before German

courts started deciding on the GPL enforceability in 2004 231 and the US
Federal Circuit decided the landmark case of Jacobsen v. Katzer 232 in
2008. 233 The question was whether a breach of an open source license
should be treated simply as a breach of contract or as a breach of a copyright
license that may constitute copyright infringement. 234 Injunctive relief
would be available if a breach of an open source license is considered to
constitute copyright infringement, but not if it is considered to be a mere
breach of contract. Case law suggests that, at least in Germany and the US,
230
APACHE LICENSE, VERSION 2.0 (Apache License 2.0), at http://www.apache.org/licenses/
231
LG München I [District Court of Munich I] 19 May 2004, Case No. 21 O 6123/04,
GRUR-RR 2004, 350 [English translation: IIC 2005, 36(6), 733]; See also the website of
gpl-violations.org, at http://gpl-violations.org/ (accessed 10 August 2012) (for summaries
of court decisions concerning the enforcement of the GPL in Germany).
232
Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008)
233
See Brian W. Carver, Share and Share Alike: Understanding and Enforcing Open Source
and Free Software Licenses, 20 BERKELEY TECH. L.J. 443, 464 (2005); Robert W. Gomulkiewicz,
Enforcement of Open Source Software Licenses: The MDY Trio's Inconvenient
Complications, 14 YALE J. L. & TECH. 106, 115 (2011).
234
Jonathan Moskin, Howard Wettan & Adam Turkel, The Little License That Could:
Dangers of Using Open-Source Code After Jacobsen v. Katzer, 15(7) INTELLECTUAL
PROPERTY STRATEGIST 1, 3-4 (2009). See also Gomulkiewicz, supra note 233, at 124-37.

40
open source licenses are enforceable and a breach of open source license
may amount to copyright infringement.
The first court decision in the world on the enforceability of the GPL came
out from the District Court of Munich in Germany.235 The case was brought
up by a German software developer, Harald Welte, who wrote the software
at issue licensed under the GPL. 236 Harald Welte is the founder of gpl-
violations.org, an organisation advocating compliance with the GPL.237 The
defendant of the case distributed the software at issue in the form of object
code, without providing access to the source code and without an indication
that the software at issue was provided under the GPL, which clearly
violated the GPL terms.238 The Munich District Court ruled that the GPL
"can by no means be regarded as a waiver of copyright and copyright
claims" 239 and granted preliminary injunction against the defendant. 240
Following this case, gpl-violations.org has successfully enforced the GPL in
Germany.241 The German courts appear to have an established view that the
GPL is enforceable.
The US landmark case, Jacobsen v. Katzer, was decided by the Federal

Circuit in 2008. Jacobsen was a copyright holder of software called
DecoderPro for programming the decoder chips that control model trains. 242
Jacobsen made the DecoderPro available to the public free of charge
through the Internet under the Artistic License,243 one of the OSI certified
open source licenses. The Artistic License requires the licensee to duplicate
235
LG München I, IIC 2005, 36(6), 733; See also Thomas Hoeren, The first-ever ruling on
the legal validity of the GPL - A Critique of the case, at
http://www.oii.ox.ac.uk/resources/feedback/OIIFB_GPL3_20040903.pdf (accessed 3
August 2012).
236
See gpl-violations.org website, supra note 231.
237
Id.
238
LG München I, IIC 2005, 36(6), 733, at 734.
239
Id. at 735.
240
Id.
241
See gpl-violations.org website, supra note 231; See also Jennifer Buchanan O'Neill &
Christopher J. Gaspar, What Can Decisions by European Courts Teach Us about the Future
of Open-Source Litigation in the United States, 38 AIPLA Q.J. 437, 444-50 (2010).
242
Jacobsen, 535 F.3d, at 1375-76.
243
ARTISTIC LICENSE, at http://opensource.org/licenses/artistic-license.php (accessed 20
August 2012).

41
all of the original copyright notices and associated disclaimers when

distributing the licensed software and to indicate the changes made to the
original licensed software when distributing a modification thereof. 244
Katzer copied and modified portions of DecoderPro software in creating his
software Decoder Commander which was distributed without complying
with the Artistic License terms. 245 The Federal Circuit found that the
language of the Artistic License clearly sets the conditions for the granted
rights to copy, modify and distribute and determined that the terms of the
Artistic License are enforceable copyright conditions.246 The ruling of the
Jacobsen case demonstrates that a breach of an open source license may
lead to copyright infringement for software licensed under that license.
2. Jurisdiction and applicable law
The easy flow of information in the digital age implies a high likeliness of
international disputes to arise. Software distribution can easily cross
national borders with the use of the Internet. Further, the development of
OSS can be made in a collaboration of programmers located in different
countries by communicating through the Internet. As such, international
disputes on OSS may involve rightholders in different countries against a
user of the OSS in yet another country. Jurisdiction and applicable law in
case of international disputes on OSS may be a tricky question. When the
open source license at issue is silent on the choice of jurisdiction and
applicable law, whether a court accepts jurisdiction for the suit would
depend on the judgement of the court. The applicable law would be
determined according to the conflict of law rules in the jurisdiction of the
court.247 Among the major open source licenses described in Part III.C, the
244
Id.
245
Jacobsen, 535 F.3d, at 1379.
246
Id. at 1381-83.
247
Anna Haapanen, GPL embedded in devices - 10 most important questions for device
manufacturers' consideration, 33(4) E.I.P.R. 245, 250-51 (2011) (discusses the applicable
law and jurisdiction in connection with international disputes concerning GPLed software).
For general discussions on jurisdiction and conflict of law issues on intellectual property
litigations, see, e.g., Graeme B. Dinwoodie, International Intellectual Property Litigation:
a Vehicle for Resurgent Comparativist Thought?, 49 AM. J. COMP. L. 429 (2001); Benedetta

42
MPL includes a clause clearly stating the choice of jurisdiction and

applicable law.248
3. Relationship with national laws
Most of the major open source licenses are drafted in consideration of the
US law. Hence, when an open source license is dealt with under a national
law of a country other than the US, some considerations on potential
differences between that national law and the US law may be required.
For example, terminology according to the US Copyright Act used in an

open source license may cause problems when a copyright law outside the
US is applied to interpret the terms of the open source license. Specifically,
the scope of the term "derivative work(s)" used in the GPL version 2
(GPLv2) 249 and the Apache License 250 can be different in the US and in
other jurisdictions. For instance, the definitions of the term "derivative
work" in the US Copyright Act and in the JCA are not identical251 and the
Directive for computer programs in the EU does not use the term "derivative
work."252 Another term commonly used in open source licenses which might
Ubertazzi, Intellectual Property Rights and Exclusive (Subject Matter) Jurisdiction:

Between Private and Public International Law, 15 MARQ. INTELL. PROP. L. REV. 357
(2011).
248
MPL 2.0, Section 8 ("Any litigation relating to this License may be brought only in the
courts of a jurisdiction where the defendant maintains its principal place of business and
such litigation shall be governed by laws of that jurisdiction, without reference to its
conflict-of-law provisions. Nothing in this Section shall prevent a party’s ability to bring
cross-claims or counter-claims.").
249
GNU GENERAL PUBLIC LICENSE VERSION 2 (GPLV2), section 0, at
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html (accessed 22 August 2012) ("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.").
250
Apache License 2.0, section 1 ("'Derivative Works' shall mean any work, whether in
Source or Object form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications represent, as a whole,
an original work of authorship. For the purposes of this License, Derivative Works shall not
include works that remain separable from, or merely link (or bind by name) to the
interfaces of, the Work and Derivative Works thereof.").
251
See 17 U.S.C. §101; Article 2(1)(xi) JCA.
252
Article 4(1)(b) of the Directive prescribes one of the restricted acts as "the translation,
adaptation, arrangement and any other alteration of a computer program."

43
cause interpretation problems is "distribution." While the term "distribution"

under the US Copyright Act may cover electronic and non-electronic
distribution of computer programs, 253 the "distribution" right under the
Directive in the EU might apply only to non-electronic distribution. 254
Further, under the JCA, the term "distribution" refers to the distribution of
cinematographic works and not to the distribution of computer programs.255
Moreover, some concepts in copyright law of a specific country do not exist

under the US Copyright Act. For example, under the JCA, the author of a
computer program has the integrity right256 whereas under the US Copyright
Act, no such right as integrity right exists for computer programs. Although
there is an exception for integrity right on computer program works in
Article 2(2)(iii) JCA, 257 modifications allowed in an open source license
might fall outside the scope of the exception.258
The GPLv3 addresses the US-centric terminology problems of the

GPLv2.259
4. Conflict with exhaustion or first sale doctrine?
The decision of the CJEU Case C-128/11260 on online provision of software

may have an impact on the OSS mechanism. According to this decision, the
"licensing" of software that allows the use of the software without time limit
in return for a payment can be considered as a "sale" of the software.
Considering that open source licenses by definition cannot limit the use of
253
254
255
256
Article 20 JCA. See also, supra Part II.A.3.(b).
257
See supra Part II.A.3.(c); note 96 and accompanying text.
258
See SOFTWARE INFORMATION CENTER, ŌPUN SOFUTOUEA NO HŌTEKISHOMONDAI NI KANSURU
CHOSA CHOSA H ŌKOKUSHO [SURVEY REPORT OF A SURVEY CONCERNING LEGAL ISSUES OF OPEN
SOFTWARE], 59, 62, 87-88 (revised ed. 2005) [(財)ソフトウェア情報センター, オープン
ソフトウェアの法的諸問題に関する調査調査報告書, (平成 17 年 2 月改訂)]
(suggests a model license agreement for OSS developed in Japan which includes a clause
stating non-enforcement of the integrity right).
259
See, e.g., Stern & Allen, supra, note 188, at 354-55.
260
See supra Part II.A.1.(d).

44
the licensed software to a certain period of time, distribution of OSS in

return for a payment possibly meets the criteria set out in the Case C-128/11
to be deemed as a "sale." Then the exhaustion doctrine may apply to the
OSS.
Turning to the US, it is argued that the "sale or license" distinction ruled in
the recent US case of Vernor may be incompatible with the open source
licensing mechanism.261 In order for a transaction of software provision to
be deemed a license and thus avoid the first sale doctrine, the Vernor criteria
require the licensor to significantly restrict the user's ability to transfer the
software and to impose notable use restrictions.262 Restricting redistribution
and the use of the software is, however, against the philosophy of the open
source licenses.263 According to the Vernor criteria, provision of OSS can be
deemed a "sale" that invokes the first sale doctrine.
If the exhaustion or first sale doctrine applies to the distribution of OSS, it is

not clear whether the recipients of the OSS have the obligation to comply
with the conditions of redistribution set forth in the open source license. To
put it differently, there is an unanswered question whether a licensor of the
OSS can control the conditions of redistribution when the copyright on the
OSS exhausts by the first sale.
261
See generally Gomulkiewicz, supra note 233. See also supra Part II.A.2(d).
262
263

45
IV. Business models involving software
Business models involving software may be generally classified into two

types based on the source of revenue: one from the software itself and the
other from products or services associated with the software. The former
model distributes the proprietary software and the latter model distributes
OSS.
A. Proprietary software business model (primary market)
The proprietary software business model makes revenues on a primary

market in the sense that the developed software itself is the source of
revenue. In the proprietary software business model, the software developer
obtains revenue by selling or licensing the developed software protected by
copyright and/or patent. Proprietary software is usually distributed in the
form of object code and the source code is not disclosed. As discussed
above, software developers choose to license software rather than to sell
software in order to avoid the exhaustion or first sale doctrine.264
A license of proprietary software often takes the form of shrink-wrap or

click-wrap.265 A shrink-wrap license comes with the package of software,
either contained right under the shrink-wrap or inside the package, and
states that the user is accepting the license terms by opening the package or
by the further use of the software. 266 A click-wrap license is seen in online
provision of software through the Internet. The user must click a button to
show acceptance of the license terms in order to complete download or
267
installation of the software. Although some doubts exist on the
enforceability of the shrink-wrap and click-wrap licenses, these licenses are
widely used and some courts have recognised them as enforceable. 268
264
265
E.g., MELVIN F. JAGER, LICENSING LAW HANDBOOK, §9:1 (2011-2012 ed.).
266
Id.
267
Id.
268
Id. See also, Nadan, supra note 62, at 639-43.

46
B. OSS business models (secondary market)
In the OSS business model, revenue is made by selling services and/or

products relating to the developed software instead of selling or licensing
developed software itself. As OSS can be redistributed to anyone, even to
competitors, the business should seek revenue from sources other than the
software itself. This section will describe different types of open source
business models.
1. Example sources of revenue
The sources of revenue for OSS business models can be classified as

follows: (a) services in relation to OSS, (b) hardware comprising OSS and
(c) software related to OSS.269 In any case, OSS business models generate
revenues on a "secondary market" in the sense that additional values on
software rather than software itself are the source of revenue.
a) Services in relation to OSS
The first example is to charge for services of user support and/or

maintenance for OSS.270 Even if the developer provide its OSS for free of
charge, the developer can obtain revenue by charging for services in using
the OSS. For example, companies such as IBM, Red Hat and Novell offer
services to support the use of Linux systems.
Providing a platform for a service related to OSS and then charging for the
use of the platform is another model to obtain revenue from OSS related
services. Google implements this model in "Google Play," a service
269
See Robert W. Gomulkiewicz, Entrepreneurial Open Source Software Hackers: MySQL
and Its Dual Licensing, 9 COMPUTER L. REV. & TECH. J. 203, 205-07 (2004); Matthew
Langham, The business of open source, OSS Watch (2012), at http://www.oss-
watch.ac.uk/resources/businessofopensource.xml (accessed 4 August 2012).
270
Gomulkiewicz, supra note 269, at 205; Langham, supra note 269, at point 2.3.

47
platform for distributing Android applications among other entertainment

contents. 271 Android is an OSS operating system licensed under Apache
License for smartphones and PDAs (Personal Digital Assistants). Registered
developers may sell their Android applications through Google Play. 272
Google charges one-time registration fee and obtains 30 % of the sale of the
applications as transaction fee.273
b) Hardware accompanying OSS
Some companies sell hardware accompanying OSS without charging for the
software.274 IBM is an examplary company adopting this business model as
they sell servers pre-loaded with Linux operating system. 275 A further
example would be the sale of various devices with embedded system using
OSS.276
c) Software related to OSS
This model involves different types of software. Some vendors distribute, in

return for payment, OSS "packages" configured in a way that makes easier
for the user to start using the software.277 For instance, Red Hat offers a
Linux operating system package. Another type of OSS related software that
may be the revenue source is a customised or high-end version of OSS.278
Companies that adopt this business model offer low-end versions of OSS
with limited functions for free of charge and high-end or customised
271
See Google Play website, at https://play.google.com/store (accessed 4 August 2012).
272
See Google Play for Developers: Developer Registrations, at
http://support.google.com/googleplay/android-
developer/bin/answer.py?hl=en&answer=113468 (accessed 4 August 2012).
273
See Google Play for Developers: Transaction Fees, at
http://support.google.com/googleplay/android-
developer/bin/answer.py?hl=en&answer=112622&topic=15867&ctx=topic (accessed 4
August 2012).
274
Gomulkiewicz, supra note 269, at 205.
275
Id.
276
For instance, mobile phones, network tablets, routers and electronic home appliances
etc. For examples of devices with embedded Linux, see elinux.org, Products, at
http://elinux.org/Products (accessed 10 August 2012).
277
Gomulkiewicz, supra note 269, at 206; Langham, supra note 269, at point 2.1.
278
Gomulkiewicz, supra note 269, at 206-07.

48
versions with more functions for a payment. 279 Yet another example is to
distribute OSS operating system for free of charge and charge for the
application software which runs on the operating system.280
2. Dual-licensing
Some vendors distribute software under two or more licenses including an

open source license and a commercial license from which the customers
may choose.281 The model is called dual-licensing when they provide one
open source license and one commercial license. The licensing of a database
management system, MySQL, is a leading example of this scheme.282 The
users of MySQL can choose from a commercial license and the GPL. 283
C. Possible problems and conflicts
1. Copyright infringement risk in OSS business
Reproduction, modification or distribution of copyrighted software without

authorisation of the rightholder constitutes copyright infringement
regardless of the intention to infringe the copyright.284 A possible situation
of copyright infringement by OSS vendors would be that some components
of copyrighted software is re-used, either inadvertently or intentionally, in
developing OSS. Since re-use of source codes of already developed
software is a common practice in software development, the OSS vendors
should be aware of copyright infringement risk in their OSS.285 Further, it
should be noted that copyright infringement by OSS can be easier to detect
279
Id.
280
Id. at 206.
281
Id. at 208-10; Elena Blanco, Dual-licensing as a business model, OSS Watch (2006) at
http://www.oss-watch.ac.uk/resources/duallicence2.xml (accessed 4 August 2012).
282
See generally, Nicholas Taylor, Open Source Dual Licensing as a Business Model: How a
Flexible IP Strategy Helped Create the World's Most Popular Open Source Database
Company, 37 AIPLA Q.J. 321 (2009).
283
Id.
284
See, e.g., supra Parts II.A.1.(b), II.A.2.(b), II.A.3.(b).
285
Kat McCabe, Working with Open Source: Software Compliance Management, in
ADVANCED LICENSING A GREEMENTS 2008, 6 (Joseph Yang & Ira J. Levy 2008).

49
and to prove compared to infringement by proprietary software because the

source code is available for OSS but not for proprietary software.
Software that is developed independently of copyrighted software will not

cause copyright infringement because the development of the software
involves no reproduction and modification of the copyrighted software. This
is true even if the developed software is similar to the copyrighted software.
A series of lawsuits brought up in the US by the SCO Group, Inc. (SCO)

against Linux vendors demonstrate the copyright infringement risk for the
open source community. SCO claimed the copyright ownership of the UNIX
system and sued a number of Linux vendors including IBM, Red Hat,
Novell, AutoZone and Daimler-Chrysler.286 The first suit by SCO was filed
against IBM in 2003 with an allegation that IBM had incorporated SCO's
proprietary software into the Linux operating system offered by IBM.287 The
copyright infringement claims by SCO resulted unsuccessful when a jury
verdict in 2010 denied the copyright ownership of SCO for the UNIX
system. 288 Nevertheless the SCO litigations raised awareness among the
open source community of copyright infringement risk in their activities.
2. Patent infringement risk in OSS business
Making, using, offering for sale, or selling products which falls within the
scope of a patented invention constitute patent infringement. 289 A possible
plaintiff of patent infringement against OSS vendors would be a patent
holder outside the distribution chain of the OSS since patent clauses in open
286
Groklaw, SCO Litigation - From Soup to Nuts, at
http://www.groklaw.net/staticpages/index.php?page=20080803065719599 (accessed 29
August 2012).
287
Id. See also, Groklaw, SCO v. IBM Timeline, at
http://www.groklaw.net/staticpages/index.php?page=20031016162215566 (accessed 29
August 2012).
288
The SCO Group, Inc. v. Novell, Inc., 721 F.Supp.2d 1050, 1072 (D. Utah, Central Division,
2010).
289

50
source licenses 290 would prevent distributors of OSS to sue the OSS
recipients for patent infringement.
Unlike copyright infringement, software developed independently of

patented software may cause patent infringement if the developed software
falls within the scope of patented invention. This is true even when no
copying of existing software occurred. Because independently developed
software can cause patent infringement, patent infringement may seem more
likely to occur than copyright infringement in using OSS. Further, similarly
to copyright infringement cases discussed above, patent infringement by
OSS can also be easier to be discovered and proven than that in the case of
patent infringement by proprietary software, because of the availability of
the source code of the OSS. Believing the vulnerability of the OSS against
patent infringement claims, 291 the open source community is strongly
against software patents.292
Most of the open source licenses include clauses for disclaimer of warranty
and limitation of liabilities, 293 which may protect the OSS distributors from
damage claims by the downstream OSS users sued in a patent infringement
case. Yet a patent infringement claim against an OSS vendor can have a
huge negative impact on its business. 294 For example, if the patent
infringement claim against the OSS vendor is known to the public, the
vendor might lose their customers and/or investors that wish to avoid
problems.295
290
See, e.g., GPLv3, section 11; MPL 2.0, section 2.1.b; Apache License 2.0, section 3.
291
See, e.g., MEEKER, supra note 217, at 96-98 (explaining arguments for the proposition
that the OSS is particularly vulnerable to patent infringement).
292
See, e.g., supra note 210 and accompanying text; Red Hat Inc., Statement of Position and Our Promise on
Software Patents
, at http://www.redhat.com/legal/patent_policy.html (accessed 1 August 2012)
("Red Hat has consistently taken the position that software patents generally impede
innovation in software development and that software patents are inconsistent with open
source/free software.").
293
See, e.g., GPLv3, sections 15, 16; MPL 2.0, sections 6, 7; Apache License 2.0, sections 7,
8.
294
Paul H. Arne, Patent Risks in Open Source Licensing, in Joseph Yang and Ira J. Levy,
Advanced Licensing Agreements 2008, 9, 10 (Practising Law Institute 2008).
295
Id.

51
Microsoft has successfully been enforcing its patents against Linux

distributors. 296 In 2009, Microsoft sued TomTom, a manufacturer of car
navigation systems, for patent infringement alleging that the Linux kernel is
infringing a number of patents of Microsoft.297 TomTom in response raised a
countersuit of patent infringement against Microsoft but the cases were
quickly settled.298 The agreement for settlement included payment of license
fees for patents of Microsoft by TomTom and a grant for Microsoft to work
patents of the countersuit by TomTom.299 Microsoft and TomTom consider
their agreement to be "fully compliant with TomTom’s obligations under the
[GPLv2]." 300 Similar patent infringement claims by Microsoft have led
other electronics companies to engage into patent licensing agreements with
Microsoft in order to secure their businesses involving the Linux.301 These
agreements were designed to conform to the GPLv2, but they could be
exactly the agreements that section 11 of the GPLv3 attempts to avoid.302
Except for the aforementioned claims raised by Microsoft, patent

infringement claims against OSS developers cannot be seen to occur as
often as one might expect.303 Public relations problems with bringing suits
against open source projects may be the reason for this lack of enforcement
296
See, e.g., Heather J. Meeker, Open Source and the Age of Enforcement, 4 HASTINGS
SCI. & TECH. L.J. 267, 280-81 (2012).
297
Complaint, Microsoft Corp. v. TomTom, N.V., No. 09-cv-00247 (W.D. Wash. Feb. 25,
2009), available at http://www.groklaw.net/pdf/tomtomComplaint.pdf (accessed 6
September 2012).
298
Microsoft Corporation, Microsoft and TomTom Settle Patent Infringement Cases (30
March 2009) at http://www.microsoft.com/en-us/news/press/2009/mar09/03-
30MSTomTomPR.aspx
299
Id.
300
Id.
301
These companies include: I-O Data, Amazon, Novell, Brother International Corp, Fuji
Xerox Co. Ltd, Kyocera Mita Corp., LG Electronics and Samsung Electronics Co. See, e.g.,
Sean Kerner, Microsoft's Linux Patent Scare Trumps SCO, InternetNews.com (4 March
2010), at http://www.internetnews.com/skerner/2010/03/microsofts-linux-patent-
scare.html
302
See supra Part III.C.1. See also Meeker, supra note 296, at 280-81.
303
See, e.g., MEEKER, supra note 217, at 93. Besides, the IP claim of the SCO v. IBM case
in the US was a copyright infringement rather than a patent infringement.

52
of patents.304 In addition to the public relations concerns, especially large

proprietary vendors may refrain from bringing a lawsuit against developers
and/or users of OSS, because of the following reasons: some large
proprietary vendors are themselves involved in OSS business; 305 suing a
customer for patent infringement would negatively affect their business;306
and some large proprietary vendors may have antitrust considerations. 307
Moreover, a patent right is not an absolute, solid right: it can be invalidated
when the patented invention is proved not to meet the patent requirements
of the country where the protection is sought. Reflecting these situations,
"ignorance of the whole patents race" may be suggested as a "reasonable
strategy" particularly for smaller companies that have little resources
available for taking measures to deal with the patent infringement risk.308
Actual tendencies of the IT industry to ignore patents are also pointed out.309
3. "Contamination" of proprietary software by OSS
A copyleft license (e.g. GPL) may "contaminate" proprietary software when

the proprietary software is combined with OSS in a manner that the
resulting software is considered as a modification or a derived work under
the license terms.310 The "contaminated" software must be licensed under
the same terms of the copyleft license for the OSS, i.e., the source code of
the new software must be disclosed. Proprietary software developers hope to
avoid such a result. This section will discuss how proprietary software could
be "contaminated" by OSS. In which situation proprietary software is
"contaminated" depends on the terms of the open source license for the OSS.
304
MEEKER, supra note 217, at 93, 94 (referring that SCO "gained great notoriety for
making perceived threats against open source" by initiating the series of litigations against
Linux operating system vendors).
305
Arne, supra, note 294 at 3, 4. This does not apply to Microsoft in their patent
enforcement against the Linux because Microsoft does not distribute the Linux.
306
Id. at 4.
307
Id.
308
VÄLIMÄKI, supra note 104, at 172.
309
See generally, Mark A. Lemley, Ignoring Patents, 2008 MICH. ST. L. REV. 19 (2008).
310

53
It should be noted that the problem of "contamination" arises only when the
new software is distributed to third parties. 311 Thus, as long as the new
software created by combing proprietary software with OSS is used
internally, i.e., within one organisation, the source code of the new software
can be kept undisclosed without violating the open source license terms.312
a) Mixing OSS and proprietary source codes
Suppose some components of OSS and proprietary source codes are mixed
to create a source code of new software. Such new software would be a
derivative work or an alteration of the original OSS and proprietary software
313
under a copyright law. This form of combination would likely
"contaminate" the proprietary software in most copyleft licenses.
The GPLv3 requires the "modified version" of GPLed software to be

distributed under the terms of the GPLv3.314 The modified version is a result
of copying or adapting "all or part of the work in a fashion requiring
copyright permission, other than the making of an exact copy."315 The new
software in the above example fits into the scope of the "modified version"
of the GPLv3 and thus has to be licensed under the GPLv3.
The "file-level" copyleft effect of the MPL 316 applies only to the source
code file(s) of the new software containing a part of the original MPLed
code or its modifications. Thus, if the OSS and proprietary source codes are
mixed into one file to create the new software, the new software is
"contaminated." By contrast, in case the source codes of the OSS and
311
Copyleft provisions of open source licenses apply when covered programs or their
modifications are distributed. See, e.g., GPLv3, sections 4, 5; MPL 2.0, section 3.1.
312
See, e.g., FSF, Frequently Asked Questions about the GNU Licenses, at
http://www.gnu.org/licenses/gpl-faq.en.html#InternalDistribution (accessed 30 August
2012) (stating that "making and using multiple copies within one organization or
company" is not a "distribution").
313
See supra Parts II.A.1.(b), II.A.2.(b), II.A.3.(b). See also, supra notes 251, 252 and
accompanying text.
314
GPLv3, section 5.
315
Id. at section 0.
316
See supra notes 226, 227 and accompanying text.

54
proprietary software are separated in different files and the new software is
created by linking those files, the source code files of the proprietary
software can be kept undisclosed when distributing the new software.317 The
details of linking will be discussed in the next part.
b) Static and dynamic linking with OSS
"Linking" in computer programming means to combine different computer

programs to create an executable form of software. Linking can be made in
two manners: static and dynamic. Static linking creates, from source codes
of different computer programs, one object code either during or after
compilation. The resulting object code includes the contents of every
function that the software is supposed to achieve. In dynamic linking, on the
other hand, object codes of different programs are created separately and
function calls from one program to another are made at runtime.
Linking proprietary software with OSS may occur when proprietary

software uses some functions of OSS.318 In static linking, one object code
will be created, including compiled proprietary source code and parts of
compiled OSS source code corresponding to the functions called by the
proprietary software. In dynamic linking, the object codes of the proprietary
software and OSS are created separately and the proprietary software makes
function calls to the OSS during runtime. Whether linking with OSS
"contaminates" proprietary software is an unsettled issue. It of course
depends on the terms of the particular open source license. Some argue that
it may also depend on whether the linking is made statically or
dynamically.319
317
MPL 2.0, section 3.3. See also supra note 226 and accompanying text.
318
See, e.g., Stern & Allen, supra note 188, at 344.
319
Id. at 344-45 (considering dynamic linking less likely to be "contaminating" than static
linking under the GPLv2). But see Linus Torvalds, GPL only modules, linux-kernel mailing
list (2006) at https://lkml.org/lkml/2006/12/17/79 (accessed 3 September 2012)
(explaining that "'static' vs 'dynamic'" does not matter but whether the linked programs
are "independent" of each other does matter when determining if linking of programs
cause a derived work).

55
According to the definition of the "modified version" under the GPLv3,320

static linking with GPLed program would certainly "contaminate" the
proprietary software, because the resulting object code will be a mixture of
GPLed object code and proprietary object code, which may be considered as
a derivative work of the GPLed program and of the proprietary program
under a copyright law. Whether dynamic linking with GPLed program
would be "contaminating," is less clear since the GPLed object code and
proprietary object code are kept separate and interact just at runtime. The
FSF appears to consider that both static and dynamic linking with the GPL
would "contaminate" the proprietary software.321 The GPL has, however, a
so-called "system library exception" in which it exempts from the copyleft
effect the source codes of system libraries normally included in an operating
system. 322 The system libraries can be kept proprietary even if they are
linked with GPLed software.323
The LGPLv3 allows proprietary software that is linked with a LGPLed

library program to be kept proprietary.324 The language of LGPLv3 terms
does not distinguish static and dynamic linking. 325
In case of the MPL, the proprietary software will not be "contaminated" as

long as the source code files of the MPLed software and proprietary
software are separated, regardless of whether the linking is made statically
or dynamically.326
320
321
See, e.g., FSF, supra note 312 (does not distinguish static and dynamic
linking for explaining the case of linking proprietary program with GPLed
program. Further, the following statements are found: "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, which must be treated as an
extension of both the main program and the plug-ins. This means that combination of
the GPL-covered plug-in with the non-free main program would violate the GPL.").
322
GPLv3, section 1. See also FSF, supra note 312 ("What legal issues come
up if I use GPL-incompatible libraries with GPL software?").
323
Id.
324
See supra Part III.C.2.
325
See generally LGPLv3.
326

56
c) Software that runs on OSS operating system
Proprietary software that runs on an OSS operating system (e.g. Linux) is

unlikely to be "contaminated" if the proprietary software uses the functions
of the operating system through standard interfaces.327
d) Software created using OSS as a development tool
Some OSS may function as a development tool for creating other software.
Does the copyleft effect of the open source license cover software created
using the OSS? This question was one of the issues in the US case,
Computer Associates International v. Quest Software, Inc. 328 The plaintiff
claimed copyright for their software created by using modified GPLed
program. 329 The court found that the "output" of the modified GPLed
program, i.e., source code created by using the modified GPLed program,
was not subject to the restrictions of the GPL and thus copyright claim for
such source code was valid.330
The GPLv3 which was published after the Quest Software decision includes
an exception of the coplyleft effect for the "output from running a covered
work."331 If software created by running GPLed software does not contain
GPLed software and its modification, the resulting software is out of the
copyleft scope.332
Under the MPL, source codes created using MPLed software need not be
disclosed under the MPL as long as the resulting source code file does not
327
See Linus Torvalds, linux/kernel/COPYING, The Linux Kernel Archives, at
http://www.kernel.org/pub/linux/kernel/COPYING (accessed 23 August 2012) (stating
that GPLv2 does not cover "user programs that use kernel services by normal system
calls"). See also Stern & Allen, supra note 188, at 344-45, 351.
328
Computer Associates International v. Quest Software, Inc., 333 F.Supp.2d 688 (N.D. Ill.
2004).
329
Id. at 697-98.
330
Id. at 698.
331
GPLv3, section 2.
332
Id.

57
contain MPLed source codes.333
e) Distributing proprietary software together with OSS
Merely distributing independent proprietary software together with OSS

would not "contaminate" the proprietary software. For example, storing
separate proprietary software and OSS on one medium and distributing the
medium would not be "contaminating." 334 In the GPLv3, this type of
combination of proprietary software and OSS is called an "aggregate" and
the GPLv3 does not apply to such proprietary software.335 MPLed software
also would not "contaminate" independent proprietary software in such form
of distribution since the files of proprietary software and OSS are
separate.336
4. Violation of open source license terms
A typical violation of open source license terms is distributing

"contaminated" software without complying with the open source license
terms (e.g. without providing the source code or without an appropriate
license notice). The US Jacobsen case and the German case No. 21 O
6123/04 involved this type of violations. 337 Another example of the violation
is to restrict the use of OSS in a way not allowed by the open source license
terms. For example, one of the lawsuits raised in Germany by the gpl-
violations.org related to restrictions on making modifications of GPLed
software posed by the distributor of the software, which violates the GPL
terms.338
333
334
Item 9 of the Open Source Definition prohibits an open source license to restrict other
software distributed with OSS. See supra Part III.B.1.
335
GPLv3, section 5, second paragraph.
336
337
See supra Part III.D.1.
338
See, e.g., gpl-violations.org, Court rejects AVM's claims opposing third party
modifications of GPL software, at http://gpl-violations.org/news/20111110-avm-
cybits.html (accessed 4 September 2012).

58
A violation of open source license terms constitutes copyright infringement

of the OSS.339 Proprietary software developers fear that they may have to
disclose their proprietary source code "contaminated" by the OSS when the
open source license is enforced. 340 The enforcement of an open source
license, however, is in essence a copyright enforcement. Since remedies for
copyright infringement do not include disclosure of the infringing work, the
infringer who violated open source license terms would not be forced to
disclose their source code in the framework of copyright law. The
enforcement of the source code disclosure term of an open source license
would depend on the interpretation of the term in light of the applicable
contract law by the court.
In addition to the Jacobsen case and suits raised by gpl-violations.org,

notable cases of open source violation were brought up by the Software
Freedom Law Center (SFLC).341 For instance, the SFLC, representing the
FSF, filed a lawsuit against Cisco Systems, Inc. in 2008 for violations of the
GPL.342 The case was settled within a year after Cisco agreed to comply
with the GPL and to financially contribute to the FSF.343
The SFLC represented BusyBox software developers in a series of lawsuits

between 2007 and 2009. BusyBox provides standard UNIX functions in a
single small executable which is suitable in use for embedded systems.
BusyBox is licensed under GPLv2. The defendants in all the BusyBox cases
violated the GPL by redistributing the software without providing the source
code. In 2007, the SFLC filed four lawsuits in a row, respective defendant of
which are Monsoon Multimedia, Inc., Xterasys Corporation, High-Gain
339
See supra Part.III.D.1.
340
Moskin, Wettan & Turkel, supra note 234, at 3.
341
The SFLC is an organisation that provides legal services for open source licensing and
enforcement. See SFLC website, http://www.softwarefreedom.org/ (accessed 6
September 2012).
342
SFLC, News: SFLC Files Lawsuit against Cisco on Behalf of the FSF (11 December 2008),
at http://www.softwarefreedom.org/news/2008/dec/11/cisco-lawsuit/
343
Brett Smith, FSF Settles Suit Against Cisco (20 May 2009), at
http://www.fsf.org/news/2009-05-cisco-settlement.html

59
Antennas, LLC. and Verizon Communications, Inc.344 These four cases were
settled quickly with each defendant agreeing to publish the source code for
the BusyBox software and to pay an undisclosed amount to the plaintiff.345
The lawsuits filed in 2008 also settled in a similar manner. 346 In 2009, the
SFLC filed yet another suit regarding BusyBox against fourteen defendants
including Best Buy and Samsung.347
The "advocates" of open source licenses such as the FSF, the SFLC and the
gpl-violations.org are interested primarily in compliance rather than
injunction.348 Thus, claims from the "advocates" are relatively easy to deal
with. 349 In fact, most of the SFLC cases introduced above were settled
quickly outside the court. Another kind of claimants, however, the
"strategists," are also said to be interested in open source license
enforcement.350 The "strategists" may use open source claims as a tool to
weaken their competitors.351 Hence the "strategists" are more interested in
injunction and damages than compliance, which makes their claims more
complicated to handle than those of the "advocates."352
344
SFLC, SFLC News: 2007, at http://www.softwarefreedom.org/news/2007/ (accessed 6
September 2012).
345
Eric Boehm, Open source licensing suits settle in short order, The Lawyers Weekly (30
May 2008), at http://www.lawyersweekly.ca/index.php?section=article&articleid=691
346
September 2012).
347
SFLC, Best Buy, Samsung, Westinghouse, And Eleven Other Brands Named In SFLC
Lawsuit (14 December 2009), at
http://www.softwarefreedom.org/news/2009/dec/14/busybox-gpl-lawsuit/
348
Meeker, supra note 296 at 290.
349
Id. at 290.
350
Id. at 286-90.
351
Id. at 287-88.
352
Id. at 287-90.

60
V. Possible best practices
Preceding chapters have presented legal tools available for protecting

software and their business implications. What is the best way for software
developers to protect their software after all? Considering the diversity of
the developers, there will be no single best option that applies to everyone.
This Chapter will explore the clues for the developers to determine their
strategy that suits best for their business.
A. Proprietary or open source?
The choice between proprietary software and OSS for distribution depends
on the specific business model adopted by the developer. If the core
business value of the developer is on the software itself, the software should
be kept proprietary. In contrast, if the business strength of the developer lies
in the secondary market, distributing their software as OSS would be an
option. Distributed OSS can be improved by any recipient of the OSS and
licensed back to the user community including the distributor. 353 This
collaborative nature of OSS development would save the time and cost for
the developers to improve the released OSS.354
In either case of distributing proprietary software or OSS, using OSS as a

development tool would be beneficial for the developers to save the
development cost. The code re-use of OSS components in the software to be
distributed may also be made in both proprietary software and OSS
businesses. When incorporating OSS components into proprietary software,
however, special consideration should be given to the "contamination"
issue.355
353
Especially if the OSS is distributed under a copyleft license, the improved software will
also be distributed as OSS.
354
See, e.g., Stern & Allen, supra note 188, at 335.
355
See supra Part IV.C.3; infra Part V.D.1.

61
B. Just copyright or also patent protection?
When a developer chooses to keep his/her software proprietary, the next

question would be whether to obtain patent protection for the software.
Since copyright for software arises automatically, the consideration may be
focused on whether or not to obtain patent protection.
The advantage of patents over copyright is that patent protection is stronger

than copyright protection. Patent can protect the functions and underlying
ideas of software whereas copyright does not. Further, with patent
protection, the rightholder can exclude others from working an invention
that has been created independently of the patented invention if the
independently created invention falls within the scope of the patent. In
contrast, copyright owner cannot enjoin independently created software
being similar to the copyrighted software.
The disadvantage of patent protection would be that patent procurement is

much more expensive than copyright. Copyright can be obtained
automatically with the creation of software but obtaining patent requires
examination by Patent Offices. Because there is little international
harmonisation on patentability of software patents,356 different prosecution
approaches for each country/region are required.
It would be worth obtaining patent protection for an innovative processing

idea which makes software unique and gives competitive value to the
software. Because such an idea is likely to be preserved in after different
version upgrades of software, copyright protection for a specific expression
of the software might not be enough.
Defensive use of patents should also be considered. Obtaining patents would

result in a better legal position of a developer when being face with a patent
infringement claim, because the developer could use his/her patents in
356
See supra Part II.B.

62
cross-licensing negotiations with the claimant. Even just filing patent

applications and have them published by the Patent Offices can be a defence.
Published patent applications become prior art to reject patent having a later
filing or priority date for the same or similar inventions by others on
grounds of lack of novelty and/or inventive step. Red Hat, a major Linux
operating system distributor, strategically uses patents for defence
purposes.357
C. Which open source license?
When a developer decides to use and/or distribute OSS, the developer

should choose which license(s) to adopt for inbound and/or outbound
software.
Proprietary software distributors need to choose an open source license just

for inbound software. A non-copyleft license such as Apache License is the
most recommendable in order to avoid any "contamination" issues. 358 A
weak copyleft license like the LGPL or the MPL could also be safely
combined with the proprietary software without "contamination". 359 In
contrast, the strong copyleft effect of the GPL can potentially be
cumbersome for proprietary software developers.360
OSS distributors need to choose open source license(s) for both inbound and
outbound software. The choice for the outbound software would depend on
how the developer wishes the software to be used by the recipients. If the
developer is sympathetic to the "free software" philosophy of the FSF, the
GPL would be an option. If the developer wishes to gain popularity for
his/her software among proprietary software developers, a weak copyleft or
a non-copyleft license is preferable. Choosing the same license as the
357 Red Hat Inc.

, supra note 292.
358
See generally Geoffrey P. Vickers & Kelly L. Frey, Sr., When Android Calls -- Open Source
Frontiers in Smartphones, 7 No. 2 ABA SCITECH LAW. 20 (2010).
359
See supra Parts III.C.2-3, IV.C.3.
360
See supra Parts III.C.1, IV.C.3.

63
outbound software for the inbound software would be ideal in order to avoid
violations of the license terms on redistribution. In reality, however, the
developer possibly has various inbound OSS licensed under different
licenses and may distribute outbound OSS under two or more licenses. In
such a situation, compatibility between open source licenses should be taken
into account.
D. What to consider in a mixed environment
Regardless of the business model, a software developer may have to deal

with both proprietary software and OSS. This section will discuss issues to
be considered in a mixed environment: specifically, issues when proprietary
software developer handles OSS.
1. Compliance with open source licenses
Developers using OSS should comply with the terms of the relevant open
source license. Non-compliance may cause disputes with the licensor of the
inbound OSS.361 The disputes would likely result in a settlement including
assurance of the compliance and a damage payment by the licensee or a
court decision against the licensee. 362 As such, it can be too expensive to be
ignorant of consequences of non-compliance with open source license
terms.363
How to ensure compliance with open source license terms? It is crucial to

understand the terms of each open source license relevant for each inbound
OSS component. Compliance becomes an issue when the developer
(re)distributes OSS or modifications thereof. The use and modification of
OSS will not be restricted by an open source license, when no distribution
occurs. Terms for (re)distribution to be noted include: the scope of the
361
See supra Parts III.D.1, IV.C.4.
362
Id.
363
Meeker, supra note 296, at 289-90. See also Ibrahim Haddad, Free and Open Source
Software Compliance: The Basics You Must Know, 1036 PLI/PAT 17, 29-30 (2011).

64
copyleft effect, required notices (e.g. attribution, license and copyright) and
the form of provision of corresponding source code when distributing the
object code. The developer should keep track on which inbound OSS
components subject to which license are specifically incorporated into
which outbound software.
The conditions for distribution of the outbound software depend on the open
source license terms for the OSS components incorporated into the
outbound software. If the outbound software is proprietary, the developer
should make sure that the outbound software is not "contaminated" in light
of the relevant open source license terms.364 In case the outbound software
is OSS, the open source license terms for the outbound software should be
compatible with the terms for the inbound OSS incorporated into the
outbound software.365 That is, the license terms for the outbound software
should not include any restrictions or conditions that are not allowed to be
included under the license terms applicable to the inbound OSS.
2. Avoiding "contamination" of proprietary software
Proprietary software distributors should avoid "contamination" of their

outbound software by OSS with a copyleft license, in order to be in a
position to keep their proprietary source codes undisclosed. 366 The safest
practice would be to use only OSS components with a non-copyleft license
to incorporate into the outbound software. OSS components with a strong
copyleft license should be kept separate from proprietary codes under
development. Especially with GPLed software, the developer should avoid
mixing367 and/or linking368 the codes. Regarding OSS with a weak copyleft
license, it is important to check the manner of combination that would and
would not "contaminate" the proprietary software under the license terms.
364
See supra Part IV.C.3.
365
See, e.g., Smith, supra note 216 (explaining compatibility issues on the GPL).
366
See supra Part IV.C.3.
367
See supra Part IV.C.3.(a).
368
See supra Part IV.C.3.(b).

65
VI. Conclusion
We have seen different legal means of software protection: copyright, patent

and open source. Copyright and patent provide rightholders with exclusive
rights to control the use and distribution of the software. Open source
licenses are built upon the copyright system to secure the freedom of the use
of the software. The underlying philosophies for proprietary software and
OSS are in the opposite to each other. The two types of software seem to be
irreconcilable, but co-exist at the same time, a situation which all software
developers must deal with. Although some legal issues in connection with
open source remain unresolved, 369 the court decisions in the US and
Germany indicate that open source licenses are indeed enforceable as
copyright licenses.370
The conflicts and problems in the coexistence of proprietary software and

OSS are also shown in this thesis.371 IP infringement risk in OSS does exist
and some OSS developers might feel proprietary software business models
threatening and unjust.372 The OSS developers, however, can take advantage
of the existence of the "unjust" model by differentiating themselves from
proprietary developers so as to appeal to the consumers. The legal
uncertainties on OSS might make proprietary software developers hesitant
to use OSS. With due care on compliance and "contamination," however,
they can reduce the risk in the use of OSS and benefit from it. The
coexistence is not impossible and provides diversity in business models,
which gives more options for developers and consumers.
369
See supra Parts III.D, IV.C.
370
See supra Parts III.D.1, IV.C.4.
371
See supra Part IV.C.
372
Note for example the philosophy of the FSF that all software should be "free."

66
List of Works Cited
Cases
[US]
Adobe Systems Inc. v. One Stop Micro, Inc., 84 F.Supp.2d 1086 (N.D.Cal. 2000)
Adobe Systems Inc. v. Stargate Software Inc., 216 F.Supp.2d 1051 (N.D.Cal. 2002)
Apple Computer, Inc. v. Franklin Computer Corp. 714 F.2d 1240 (3d Cir. 1983)
Bilski v. Kappos, 130 S.Ct. 3218 (2010)
Computer Associates International, Inc. v. Altai, Inc. 982 F.2d 693 (2d Cir. 1992)
Computer Associates International v. Quest Software, Inc., 333 F.Supp.2d 688 (N.D. Ill.
2004)
Diamond v. Diehr, 450 U.S. 175 (1981)
Gottschalk v. Benson, 409 U.S. 63 (1972)
In re Bilski, 545 F.3d 943 (Fed. Cir. 2008)
Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008)
MAI Systems Corp. v. Peak Computer, Inc., 991 F.2d 511 (9th Cir. 1993)
MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010)
Microsoft Corp. v. TomTom, N.V., Complaints, No. 09-cv-00247 (W.D. Wash. Feb. 25,
2009), available at http://www.groklaw.net/pdf/tomtomComplaint.pdf (accessed 6
September 2012)
Parker v. Flook, 437 U.S. 584 (1978)
The SCO Group, Inc. v. Novell, Inc., 721 F.Supp.2d 1050 (D. Utah 2010)
SoftMan Products Company, LLC, v. Adobe Systems Inc., 171 F.Supp.2d 1075
(C.D.Cal. 2001)
State Street Bank & Trust Co. v. Signature Financial Group, Inc, 149 F.3d 1368 (Fed.
Cir. 1998)
UMG Recordings, Inc. v. Augusto, 628 F.3d 1175 (9th Cir. 2011)
Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010)

67
[CJEU]
Case C-393/09, Bezpečnostní softwarová asociace – Svaz softwarové ochrany v.

Ministerstvo kultury (2010)
Case C-406/10, SAS Institute Inc. v. World Programming Ltd (2012)
Case C-128/11, UsedSoft GmbH v. Oracle International Corp. (2012)
[EPO]
T 1173/97, Computer program product/IBM, 1999 OJ EPO 609 (1998)
T 641/00, Two identities/COMVIK, 2003 OJ EPO 352 (2002)
T 258/03, Auction method/HITACHI, 2004 OJ EPO 575 (2004)
T 424/03, Clipboard formats I/MICROSOFT (2006)
G 03/08, Programs for computers (2010)
[Germany]
LG München I [District Court of Munich I] 19 May 2004, Case No. 21 O 6123/04,

GRUR-RR 2004, 350 [English translation: IIC 2005, 36(6), 733]
[Japan]
Tōkyō Kōtō Saibansho [Tokyo High Ct.] 28 February 1950, Sho 23 (na) No. 5
Tōkyō Kōtō Saibansho [Tokyo High Ct.] 14 November 1953, Sho 26 (na) No. 12
Tōkyō Kōtō Saibansho [Tokyo High Ct.] 25 December 1956, Sho 31(na) No. 12
Chitekizaisan Kōtō Saibansho [IP High Ct.] 24 June 2007, Hei 19 (ke) No. 10369
Chitekizaisan Kōtō Saibansho [IP High Ct.] 31 October 2007, Hei 19 (ke) No. 10056
Chitekizaisan Kōtō Saibansho [IP High Ct.] 29 February 2008, Hei 19 (ke) No. 10239
Chitekizaisan Kōtō Saibansho [IP High Ct.] 26 August 2008, Hei 20 (ke) No. 10001
Books
FUMIO SAKKA, SHŌKAI CHOSAKUKENHŌ [DISCUSSION COPYRIGHT LAW] (4th ed. 2010)
[作花文雄, 詳解著作権法, (第４版 2010)]
HEATHER J. MEEKER, THE OPEN SOURCE ALTERNATIVE: UNDERSTANDING RISKS AND

68
LEVERAGING OPPORTUNITIES (2008)
Kat McCabe, Working with Open Source: Software Compliance Management, in

ADVANCED LICENSING AGREEMENTS 2008 (Joseph Yang & Ira J. Levy,
Practising Law Institute 2008)
KATO MORIYUKI, CHOSAKUKENHŌ CHIKUJŌ KŌGI [COPYRIGHT LAW CLAUSE-BY-

CLAUSE LECTURE] (new 3rd ed. 2000) [加戸守行, 著作権法逐条講義 , ( 三訂新版
2000)]
MARSHALL A. LEAFFER, UNDERSTANDING COPYRIGHT LAW (5 th ed. 2010)
MELVIN F. JAGER, LICENSING LAW HANDBOOK (2011-2012 ed.)
MIKKO VÄLIMÄKI, THE RISE OF OPEN SOURCE LICENSING (2005)
NOBUHIRO NAKAYAMA, CHOSAKUKENHŌ [COPYRIGHT LAW] (2007) [中山信弘, 著作
権法 (2007)]
NOBUHIRO NAKAYAMA, TOKKYOHŌ [PATENT LAW] (2010) [中山信弘, 特許法 (2010)]
Paul H. Arne, Patent Risks in Open Source Licensing, in ADVANCED LICENSING

AGREEMENTS 2008 (Joseph Yang and Ira J. Levy, Practising Law Institute
2008)
CONCISE EUROPEAN COPYRIGHT LAW (Thomas Dreier & P. Bernt Hugenholtz eds.,
2006)
Journal articles
Aaron Perzanowski & Jason Schultz, Digital Exhaustion, 58 UCLA L. REV. 889 (2011)
Alan Stern & A. Clifford Allen, Open Source Licensing, 985 PLI/PAT 321 (2009)
Anna Haapanen, GPL embedded in devices - 10 most important questions for device
manufacturers' consideration, 33(4) E.I.P.R. 245 (2011)
Benedetta Ubertazzi, Intellectual Property Rights and Exclusive (Subject Matter)

Jurisdiction: Between Private and Public International Law, 15 MARQ. INTELL.
PROP. L. REV. 357 (2011)
Brian W. Carver, Why License Agreements Do Not Control Copy Ownership: First Sales
and Essential Copies, 25 BERKELEY TECH. L.J. 1887 (2010)
Brian W. Carver, Share and Share Alike: Understanding and Enforcing Open Source
and Free Software Licenses, 20 BERKELEY TECH. L.J. 443 (2005)

69
Christian H. Nadan, Software Licensing in the 21st Century: Are software "Licenses"
Really Sales, and How Will the Software Industry Respond?, 32 AIPLA Q. J.
555 (2004)
Daniel J.M. Attridge, Challenging claims! Patenting computer programs in Europe and
the USA, 2001(1) I.P.Q. 22 (2001).
Deborah F. Buckman, Copyright Protection of Computer Programs, 180 A.L.R. FED. 1

(2002)
Geoffrey P. Vickers & Kelly L. Frey, Sr., When Android Calls -- Open Source Frontiers
in Smartphones, 7 No. 2 ABA SCITECH LAW. 20 (2010)
Graeme B. Dinwoodie, International Intellectual Property Litigation: a Vehicle for

Resurgent Comparativist Thought?, 49 AM. J. COMP. L. 429 (2001)
Heather J. Meeker, Open Source and the Age of Enforcement, 4 HASTINGS SCI. & TECH.
L.J. 267 (2012)
Ibrahim Haddad, Free and Open Source Software Compliance: The Basics You Must
Know, 1036 PLI/PAT 17 (2011)
Jennifer Buchanan O'Neill & Christopher J. Gaspar, What Can Decisions by European
Courts Teach Us about the Future of Open-Source Litigation in the United
States, 38 AIPLA Q.J. 437 (2010)
Jonathan Moskin, Howard Wettan & Adam Turkel, The Little License That Could:
Dangers of Using Open-Source Code After Jacobsen v. Katzer, 15(7)
INTELLECTUAL PROPERTY STRATEGIST 1 (2009)
Julie E. Cohen & Mark A. Lemley, Patent Scope and Innovation in the Software
Industry, 89 CAL. L. REV. 1 (2001)
Karen Faulds Copenhaver, Managing Compliance with Open Source Software Licenses
Compliance programs for open source software aren't about fear--they're about
building a better business, 54 No. 3 PRAC. LAW. 21 (2008)
Mark A. Lemley, Ignoring Patents, 2008 MICH. ST. L. REV. 19 (2008)
Mark A. Lemley, Michael Risch, Ted Sichelman & R. Polk Wagner, Life After Bilski, 63
STAN. L. REV. 1315 (2011)
Nicholas Taylor, Open Source Dual Licensing as a Business Model: How a Flexible IP
Strategy Helped Create the World's Most Popular Open Source Database
Company, 37 AIPLA Q.J. 321 (2009)
Robert W. Gomulkiewicz, Entrepreneurial Open Source Software Hackers: MySQL and

Its Dual Licensing, 9 COMPUTER L. REV. & TECH. J. 203 (2004)

70
Robert W. Gomulkiewicz, Enforcement of Open Source Software Licenses: The MDY

Trio's Inconvenient Complications, 14 YALE J.L. & TECH. 106 (2011)
Thomas Dreier, The Council Directive of 14 May 1991 on the Legal Protection of
Computer Programs, 13(9) E.I.P.R. 319 (1990)
Articles and other supplementary materials with explicit author
Brett Smith, A Quick Guide to GPLv3, FSF, at

http://www.gnu.org/licenses/quick-guide-gplv3.html (accessed 4 August 2012)
Brett Smith, FSF Settles Suit Against Cisco (20 May 2009), at
http://www.fsf.org/news/2009-05-cisco-settlement.html
Elena Blanco, Dual-licensing as a business model, OSS Watch (2006) at

http://www.oss-watch.ac.uk/resources/duallicence2.xml (accessed 4 August 2012)
Eric Boehm, Open source licensing suits settle in short order, The Lawyers Weekly (30
May 2008), at
http://www.lawyersweekly.ca/index.php?section=article&articleid=691
Eric Raymond, The Cathedral and the Bazaar (1997), at

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html
(accessed 10 August 2012)
Linus Torvalds, GPL only modules, linux-kernel mailing list (2006) at

https://lkml.org/lkml/2006/12/17/79 (accessed 3 September 2012)
Linus Torvalds, linux/kernel/COPYING, The Linux Kernel Archives, at

http://www.kernel.org/pub/linux/kernel/COPYING (accessed 23 August 2012)
Matthew Langham, The business of open source, OSS Watch (2009), at

http://www.oss-watch.ac.uk/resources/businessofopensource.xml (accessed 4 August
2012)
Richard Stallman, The GNU Project, at http://www.gnu.org/gnu/thegnuproject.html

Rowan Wilson, GPL v3 - What's New?, OSS Watch (2007), at

http://www.oss-watch.ac.uk/resources/gpl3final.xml#body.1_div.6 (accessed 4 August
2012)
Sean Kerner, Microsoft's Linux Patent Scare Trumps SCO, InternetNews.com (4 March
2010), at
http://www.internetnews.com/skerner/2010/03/microsofts-linux-patent-scare.ht ml
Thomas Hoeren, The first-ever ruling on the legal validity of the GPL - A Critique of the
case, at
http://www.oii.ox.ac.uk/resources/feedback/OIIFB_GPL3_20040903.pdf

71
Articles and other supplementary materials without explicit author
elinux.org, Products, at http://elinux.org/Products (accessed 10 August 2012)
European Patent Office (EPO), How to apply for a European patent, at

http://www.epo.org/applying/basics.html?hp=stagea (accessed 1 August 2012)
EPO, Member states of the European Patent Organisation, at

http://www.epo.org/about-us/organisation/member-states.html (accessed 1 August
2012)
Free Software Foundation (FSF), Categories of free and non-free software, at

http://www.gnu.org/philosophy/categories.en.html (Acessed 4 August 2012)
FSF, The Free Software Definition, at http://www.gnu.org/philosophy/free-sw.html

FSF, Frequently Asked Questions about the GNU Licenses, at

http://www.gnu.org/licenses/gpl-faq.en.html#InternalDistribution (accessed 30 August
2012)
FSF, GNU Lesser General Public License, at http://www.gnu.org/copyleft/lesser.html

FSF, Overview of the GNU System, at http://www.gnu.org/gnu/gnu-history.html

FSF, What is Copyleft, at http://www.gnu.org/copyleft/copyleft.en.html (accessed 4 August

2012)
Groklaw, SCO Litigation - From Soup to Nuts, at

http://www.groklaw.net/staticpages/index.php?page=20080803065719599
Groklaw, SCO v. IBM Timeline, at

http://www.groklaw.net/staticpages/index.php?page=20031016162215566
Google Play for Developers: Developer Registrations, at

http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en
&answer=113468 (accessed 4 August 2012)
Google Play for Developers: Transaction Fees, at

http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en
&answer=112622&topic=15867&ctx=topic (accessed 4 August 2012)
Google Play website, at https://play.google.com/store (accessed 4 August 2012)

72
gpl-violations.org, Court rejects AVM's claims opposing third party modifications of

GPL software, at http://gpl-violations.org/news/20111110-avm-cybits.html
(accessed 4 September 2012)
gpl-violations.org website, at http://gpl-violations.org/ (accessed 10 August 2012)
Japan Patent Office (JPO), Procedures for Obtaining a Patent Right, at

http://www.jpo.go.jp/cgi/linke.cgi?url=/tetuzuki_e/t_gaiyo_e/pa_right.htm
Linux.org, What is Linux, at http://www.linux.org/article/view/what-is-linux (accessed

10 August 2012)
Microsoft Corporation, Microsoft and TomTom Settle Patent Infringement Cases (30
March 2009) at
http://www.microsoft.com/en-us/news/press/2009/mar09/03-30MSTomTomPR. aspx
MPL 2.0 FAQ, at http://www.mozilla.org/MPL/2.0/FAQ.html (accessed 4 August 2012)
OSI, History of OSI, at http://opensource.org/history/ (accessed 4 August 2012)
OSI, The Open Source Definition, at http://www.opensource.org/docs/osd (accessed 4

August 2012)
Red Hat Inc. Statement of Position and Our Promise on Software Patents
, , at
http://www.redhat.com/legal/patent_policy.html (accessed 1 August 2012)
Software Freedom Law Center (SFLC), Best Buy, Samsung, Westinghouse, And Eleven
Other Brands Named In SFLC Lawsuit (14 December 2009), at
http://www.softwarefreedom.org/news/2009/dec/14/busybox-gpl-lawsuit/
SFLC, News: SFLC Files Lawsuit against Cisco on Behalf of the FSF (11 December
2008), at http://www.softwarefreedom.org/news/2008/dec/11/cisco-lawsuit/

September 2012)

September 2012)
SFLC website, http://www.softwarefreedom.org/ (accessed 6 September 2012)
SOFTWARE INFORMATION CENTER, ŌPUN SOFUTOUEA NO HŌTEKISHOMONDAI NI

KANSURU CHOSA CHOSA HŌKOKUSHO [SURVEY REPORT OF A SURVEY
CONCERNING LEGAL ISSUES OF OPEN SOFTWARE], (revised ed. 2005) [(財)ソ
フトウェア情報センター, オープンソフトウェアの法的諸問題に関する
調査調査報告書, (平成 17 年 2 月改訂)]

73
THE UNITED STATES COPYRIGHT OFFICE, EXECUTIVE SUMMARY DIGITAL MILLENNIUM

COPYRIGHT ACT §104 STUDY (August 2001), at
http://www.copyright.gov/reports/studies/dmca/dmca_executive.html (accessed 4
August 2012)
United States Patent and Trademark Office (USPTO), Process for Obtaining a Utility
Patent, at http://www.uspto.gov/patents/process/index.jsp (accessed 1 August 2012)
Statutes and official guidelines
Agreement on Trade-Related Aspects of Intellectual Property Rights (TRIPS)
Berne Convention for the Protection of Literary and Artistic Works, Paris Act on July 24,
1971, as amended on September 28, 1979 (Berne Convention)
CHOSAKUKENHŌ [Copyright Act (of Japan)], Act No. 48 of 6 May 1970, English
translation is available at http://www.japaneselawtranslation.go.jp/?re=02
Convention on the Grant of European Patents (EPC) applicable since 13 December

2007
Council Directive 91/250/EEC of 14 May 1991 on the legal protection of computer

programs
Directive 2009/24/EC of the European Parliament and of the Council of 23 April 2009
on the legal protection of computer programs
Examination Guideline for Patent and Utility Model in Japan, Part VII Examination
Guidelines for Inventions in Specific Fields, Chapter 1 Computer Software-Related
Inventions (October 2011)
Guidelines for Examination in the European Patent Office (status 20 June 2012)
Interim Guidance for Determining Subject Matter Eligibility for Process Claims in View
of Bilski v. Kappos, 75 Fed. Reg. 43922 (July 27, 2010)
PL 96–517, DECEMBER 12, 1980, 94 Stat 3015
TOKKYOHŌ [Patent Act (of Japan)], Act No. 121 of 13 April 1959, English translation is
available at http://www.japaneselawtranslation.go.jp/?re=02 (accessed 2 August
2012)
The United States Copyright Act of 1976, 17 U.S.C. §§ 101-1332 (2011)
The United States Patent Act, 35 U.S.C. §§ 1-318 (2007)
U.S. CONST. art. I, § 8, cl. 8

74
WIPO Copyright Treaty adopted in Geneva on December 20, 1996 (WCT)
Open source licenses
APACHE LICENSE, VERSION 2.0 (Apache License 2.0), at

http://www.apache.org/licenses/ (accessed 4 August 2012)
ARTISTIC LICENSE, at http://opensource.org/licenses/artistic-license.php (accessed 20 August

2012)
GNU GENERAL PUBLIC LICENSE VERSION 2 (GPLV2), at

http://www.gnu.org/licenses/old-licenses/gpl-2.0.html (accessed 22 August 2012)
GNU GENERAL PUBLIC LICENSE VERSION 3 (GPLv3), at

http://www.gnu.org/licenses/gpl-3.0.txt (accessed 4 August 2012)
GNU LESSER GENERAL PUBLIC LICENSE VERSION 3 (LGPLv3), at

http://www.gnu.org/licenses/lgpl-3.0.txt (accessed 4 August 2012)
MOZILLA PUBLIC LICENSE VERSION 2.0 (MPL 2.0), at http://www.mozilla.org/MPL/2.0/


Munich Intellectual Property Law Center (MIPLC) Master Thesis (2011/12)

Uploaded by

Copyright:

Available Formats

You might also like

Munich Intellectual Property Law Center (MIPLC) Master Thesis (2011/12)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Munich Intellectual Property Law Center (MIPLC) Master Thesis (2011/12)

Uploaded by

Copyright:

Available Formats

Munich Intellectual Property Law Center (MIPLC)

Master Thesis (2011/12)

Legal Protection of Software

Table of Contents ................................................................................................................. II

3. Relationship with national laws ................................................................................. 42

Electronic copy available at: https://ssrn.com/abstract=2244216

Proprietary software is protected by copyright and/or patent that confers the

Electronic copy available at: https://ssrn.com/abstract=2244216

Acronyms and Abbreviations

CJEU = Court of Justice of European Union

Electronic copy available at: https://ssrn.com/abstract=2244216

Electronic copy available at: https://ssrn.com/abstract=2244216

issues of open source licenses will be discussed. Chapter IV will discuss

Electronic copy available at: https://ssrn.com/abstract=2244216

II. Legal basis for software protection

Copyright protection of computer programs in the EU has been harmonised

Electronic copy available at: https://ssrn.com/abstract=2244216

The Directive states what is included in the term "computer programs"

A computer program shall be protected if it is original in the sense that it is

The protection shall apply to "the expression in any form of a computer

Electronic copy available at: https://ssrn.com/abstract=2244216

The exclusive rights conferred to a rightholder for a computer program

The alterations in Article 4(1)(b) of the Directive may include translation of

Electronic copy available at: https://ssrn.com/abstract=2244216

A typical form of distribution envisaged by the distribution right stipulated

c) Exceptions of exclusive rights

Exceptions for the reproduction and alteration rights are prescribed in

Decompilation of a computer program which involves reproduction and

The distribution right of a computer program exhausts within the EU by the

Electronic copy available at: https://ssrn.com/abstract=2244216

Regarding the license/sale distinction, the CJEU has recently issued a

Electronic copy available at: https://ssrn.com/abstract=2244216

The US Copyright Act 39 was amended in 1980 to introduce statutory

A computer program enjoys copyright protection as a literary work if it is

The US Copyright Act protects the expression of a computer program but

Electronic copy available at: https://ssrn.com/abstract=2244216

Among the six exclusive rights listed in 17 U.S.C. §106, rights of

The reproduction right covers reproduction of the copyrighted work in

The adaptation right is the right to do and to authorise preparing derivative

Electronic copy available at: https://ssrn.com/abstract=2244216

as a translation . . . or any other form in which a work may be recast,

c) Limitations of exclusive rights

The US Copyright Act provides limitations specific to computer programs

Electronic copy available at: https://ssrn.com/abstract=2244216

d) First sale doctrine

The license/sale distinction for computer programs has been controversial in

Electronic copy available at: https://ssrn.com/abstract=2244216

In 2010, the Ninth Circuit of the US Court of Appeals established, in Vernor

The Vernor case dealt with distribution of physical copies of computer

In 1985, the reform of the Copyright Act of Japan (hereinafter "JCA") 71

Electronic copy available at: https://ssrn.com/abstract=2244216

able to obtain a certain result" in Article 2(1)(x)-2 JCA and "computer

The "computer program works" of Article 2(1)(x)-2 JCA must, in order to

Similarly to the EU and the US, copyright protection for a computer

Electronic copy available at: https://ssrn.com/abstract=2244216

The "reproduction" must be in a "tangible form by means of printing,

The public transmission right covers the provision of a computer program

Electronic copy available at: https://ssrn.com/abstract=2244216