Changeset - e8a8778ae5ec
[Not reviewed]
0 1 0
Bradley Kuhn (bkuhn) - 10 years ago 2014-03-19 16:39:40
bkuhn@ebb.org
All uses of \S should really have a ~ to avoid bad line breaks.
1 file changed with 7 insertions and 7 deletions:
0 comments (0 inline, 0 general)
gpl-lgpl.tex
Show inline comments
...
 
@@ -1320,63 +1320,63 @@ The Ninth Circuit has adopted the analytic dissection test to determine
 
whether one program is a derivative work of another. Apple Computer,
 
Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The analytic
 
dissection test first considers whether there are substantial similarities
 
in both the ideas and expressions of the two works at issue. Once the
 
similar features are identified, analytic dissection is used to determine
 
whether any of those similar features are protected by copyright. This
 
step is the same as the filtration step in the AFC test. After identifying
 
the copyrightable similar features of the works, the court then decides
 
whether those features are entitled to ``broad'' or ``thin''
 
protection. ``Thin'' protection is given to non-copyrightable facts or
 
ideas that are combined in a way that affords copyright protection only
 
from their alignment and presentation, while ``broad'' protection is given
 
to copyrightable expression itself. Depending on the degree of protection
 
afforded, the court then sets the appropriate standard for a subjective
 
comparison of the works to determine whether, as a whole, they are
 
sufficiently similar to support a finding that one is a derivative work of
 
the other. ``Thin'' protection requires the second work be virtually
 
identical in order to be held a derivative work of an original, while
 
``broad'' protection requires only a ``substantial similarity.''
 

	
 
\section{No Protection for ``Methods of Operation''}
 

	
 
The First Circuit has taken the position that the AFC test is inapplicable 
 
when the works in question relate to unprotectable elements set forth in 
 
\S 102(b).  Their approach results in a much narrower definition
 
\S~102(b).  Their approach results in a much narrower definition
 
of derivative work for software in comparison to other circuits. Specifically, 
 
the
 
First Circuit holds that ``method of operation,'' as used in \S 102(b) of
 
First Circuit holds that ``method of operation,'' as used in \S~102(b) of
 
the Copyright Act, refers to the means by which users operate
 
computers. Lotus Development Corp. v. Borland Int’l., Inc., 49 F.3d 807
 
(1st Cir. 1995).  In Lotus, the court held that a menu command
 
hierarchy for a computer program was uncopyrightable because it did not
 
merely explain and present the program’s functional capabilities to the
 
user, but also served as a method by which the program was operated and
 
controlled. As a result, under the First Circuit’s test, literal copying
 
of a menu command hierarchy, or any other ``method of operation,'' cannot
 
form the basis for a determination that one work is a derivative of
 
another.  As a result, courts in the First Circuit that apply the AFC test
 
do so only after applying a broad interpretation of \S 102(b) to filter out
 
do so only after applying a broad interpretation of \S~102(b) to filter out
 
unprotected elements. E.g., Real View, LLC v. 20-20 Technologies, Inc., 
 
683 F. Supp.2d 147, 154 (D. Mass. 2010).
 

	
 

	
 
\section{No Test Yet Adopted}
 

	
 
Several circuits, most notably the Fourth and Seventh, have yet to
 
declare their definition of derivative work and whether or not the
 
AFC, Analytic Dissection, or some other test best fits their
 
interpretation of copyright law. Therefore, uncertainty exists with
 
respect to determining the extent to which a software program is a
 
derivative work of another in those circuits. However, one may presume
 
that they would give deference to the AFC test since it is by far the
 
majority rule amongst those circuits that have a standard for defining
 
a software derivative work.
 

	
 
\section{Cases Applying Software Derivative Work Analysis}
 

	
 
In the preeminent case regarding the definition of a derivative work for
 
software, Computer Associates v. Altai, the plaintiff alleged that its
 
program, Adapter, which was used to handle the differences in operating
 
system calls and services, was infringed by the defendant's competitive
 
program, Oscar. About 30\% of Oscar was literally the same code as
 
that in Adapter. After the suit began, the defendant rewrote those
...
 
@@ -1392,49 +1392,49 @@ similarity between the two programs' parameter lists and macros. However,
 
following the filtration step of the AFC test, only a handful of the lists
 
and macros were protectable under copyright law because they were either
 
in the public domain or required by functional demands on the
 
program. With respect to the handful of parameter lists and macros that
 
did qualify for copyright protection, after performing the comparison step
 
of the AFC test, it was reasonable for the district court to conclude that
 
they did not warrant a finding of infringement given their relatively minor
 
contribution to the program as a whole. Likewise, the similarity between
 
the organizational charts of the two programs was not substantial enough
 
to support a finding of infringement because they were too simple and
 
obvious to contain any original expression.
 

	
 
In the case of Oracle America v. Google, 872 F. Supp.2d 974 (N.D. Cal. 2012),
 
the Northern District of California District Court examined the question of 
 
whether the application program interfaces (APIs) associated with the Java
 
programming language are entitled to copyright protection.  While the 
 
court expressly declined to rule whether all APIs are free to use without 
 
license (872 F. Supp.2d 974 at 1002), the court held that the command 
 
structure and taxonomy of the APIs were not protectable under copyright law.
 
Specifically, the court characterized the command structure and taxonomy as
 
both a ``method of operation'' (using an approach not dissimilar to the 
 
First Circuit's analysis in Lotus) and a ``functional requirement for 
 
compatability'' (using Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992) and
 
Sony Computer Ent. v. Connectix, 203 F.3d 596 (9th Cir. 2000) as analogies),
 
and thus unprotectable subject matter under \S 102(b). 
 
and thus unprotectable subject matter under \S~102(b). 
 

	
 
Perhaps not surprisingly, there have been few other cases involving a highly
 
detailed software derivative work analysis. Most often, cases involve
 
clearer basis for decision, including frequent bad faith on the part of
 
the defendant or overaggressiveness on the part of the plaintiff.  
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 

	
 
\chapter{Modified Source and Binary Distribution}
 
\label{source-and-binary}
 

	
 
In this chapter, we discuss the two core sections that define the rights
 
and obligations for those who modify, improve, and/or redistribute GPL'd
 
software. These sections, GPLv2~\S\S2--3, define the central core rights and
 
requirements of GPLv2\@.
 

	
 
\section{GPLv2~\S2: Share and Share Alike}
 

	
 
For many, this is where the ``magic'' happens that defends software
 
freedom upon redistribution.  GPLv2~\S2 is the only place in GPLv2
 
that governs the modification controls of copyright law.  If users
 
modifies a GPLv2'd program, they must follow the terms of GPLv2~\S2 in making
 
those changes.  Thus, this sections ensures that the body of GPL'd software, as it
 
continues and develops, remains Free as in freedom.
...
 
@@ -1905,49 +1905,49 @@ example above, Company \compB{} does not receive a free ride on Company
 
\compA's patent, as Company \compB{} has not licensed-in and then
 
redistributed Company A's advanced Web browser under the GPLv2. If Company
 
\compB{} does do that, however, Company \compA{} still has not lost
 
competitive advantage against Company \compB{}, as Company \compB{} must then,
 
when it re-distributes Company \compA's program, grant an implied license
 
to any of its patents that cover the program. Further, if Company \compB{}
 
relicenses an improved version of Company A's program, it must do so under
 
the GPLv2, meaning that any patents it holds that cover the improved version
 
are impliedly licensed to any licensee. As such, the only way Company
 
\compB{} can benefit from Company \compA's implied patent license, is if it,
 
itself, distributes Company \compA's software program and grants an
 
implied patent license to any of its patents that cover that program.
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
\chapter{Defending Freedom on Many Fronts}
 

	
 
Chapters~\ref{run-and-verbatim} and~\ref{source-and-binary} presented the
 
core freedom-defending provisions of GPLv2\@, which are in GPLv2~\S\S0--3.
 
GPLv2\S\S~4--7 of the GPLv2 are designed to ensure that GPLv2~\S\S0--3 are
 
not infringed, are enforceable, are kept to the confines of copyright law but
 
also  not trumped by other copyright agreements or components of other
 
entirely separate legal systems.  In short, while GPLv2~\S\S0--3 are the parts
 
of the license that defend the freedoms of users and programmers,
 
GPLv2~\S\S4--7 are the parts of the license that keep the playing field clear
 
so that \S\S 0--3 can do their jobs.
 
so that \S\S~0--3 can do their jobs.
 

	
 
\section{GPLv2~\S4: Termination on Violation}
 
\label{GPLv2s4}
 

	
 
GPLv2~\S4 is GPLv2's termination clause.  Upon first examination, it seems
 
strange that a license with the goal of defending users' and programmers'
 
freedoms for perpetuity in an irrevocable way would have such a clause.
 
However, upon further examination, the difference between irrevocability
 
and this termination clause becomes clear.
 

	
 
The GPL is irrevocable in the sense that once a copyright holder grants
 
rights for someone to copy, modify and redistribute the software under terms
 
of the GPL, they cannot later revoke that grant.  Since the GPL has no
 
provision allowing the copyright holder to take such a prerogative, the
 
license is granted as long as the copyright remains in effect.\footnote{In
 
  the USA, due to unfortunate legislation, the length of copyright is nearly
 
  perpetual, even though the Constitution forbids perpetual copyright.} The
 
copyright holders have the right to relicense the same work under different
 
licenses (see Section~\ref{Proprietary Relicensing} of this tutorial), or to
 
stop distributing the GPLv2'd version (assuming GPLv2~\S3(b) was never used),
 
but they may not revoke the rights under GPLv2 already granted.
 

	
 
In fact, when an entity looses their right to copy, modify and distribute
 
GPL'd software, it is because of their \emph{own actions}, not that of the
...
 
@@ -3009,49 +3009,49 @@ relying on a patent license. Many companies enter into blanket patent
 
cross-licensing agreements. With respect to some such agreements, it would
 
not be reasonable to expect a company to know that a particular patent
 
license covered by the agreement, but not specifically mentioned in it,
 
protects the company's distribution of GPL'd code.
 

	
 
% FIXME: does this still fit with the final retaliation provision?
 

	
 
This narrowly-targeted patent retaliation provision is the only form of
 
patent retaliation that GPLv3 imposes by its own force. We believe that it
 
strikes a proper balance between preserving the freedom of a user to run and
 
modify a program, and protecting the rights of other users to run, modify,
 
copy, and distribute code free from threats by patent holders. It is
 
particularly intended to discourage a GPL licensee from securing a patent
 
directed to unreleased modifications of GPL'd code and then suing the
 
original developers or others for making their own equivalent modifications.
 

	
 
Several other free software licenses include significantly broader patent
 
retaliation provisions. In our view, too little is known about the
 
consequences of these forms of patent retaliation. As we explain below,
 
section 7 permits distribution of a GPL'd work that includes added parts
 
covered by terms other than those of the GPL. Such terms may include certain
 
kinds of patent retaliation provisions that are broader than those of section
 
2.
 

	
 
\section{GPLv3~\S12: Familiar as GPLv2 \S 7}
 
\section{GPLv3~\S12: Familiar as GPLv2 \S~7}
 

	
 
% FIXME:  probably mostly still right, needs some updates, though.
 

	
 
The wording in the first sentence of section 12 has been revised
 
slightly to clarify that an agreement, such as a litigation settlement
 
agreement or a patent license agreement, is one of the ways in which
 
conditions may be ``imposed'' on a GPL licensee that may contradict the
 
conditions of the GPL, but which do not excuse the licensee from
 
compliance with those conditions.  This change codifies what has been
 
our interpretation of GPLv2.  
 

	
 
% FIXME:  probably mostly still right, needs some updates, though.
 

	
 
We have removed the limited severability clause of GPLv2 section 7 as a
 
matter of tactical judgment, believing that this is the best way to ensure
 
that all provisions of the GPL will be upheld in court. We have also removed
 
the final sentence of GPLv2 section 7, which we consider to be unnecessary.
 

	
 
\section{GPLv3~\S13: The Great Affero Compromise}
 

	
 
% FIXME
 

	
 
\section{GPLv3~\S14: So, When's GPLv4?}
 
\label{GPlv2s14}
...
 
@@ -3484,49 +3484,49 @@ As it turns out, we have only once had anyone worry about this specific
 
idiosyncrasy, because that particular vendor wanted to ship object code
 
(rather than final binaries) to their customers and was worried about
 
this edge condition. The intent of clarifying this edge condition is
 
primarily to quell the worries of software engineers who understand the
 
level of verbatim code copying that a compiler often does, and to help
 
them understand that the full implications of LGPLv2.1 are the same regardless
 
of the details of the compilation progress.
 

	
 
\section{LGPLv2.1~\S6 \& LGPLv2.1~\S5: Combining the Works}
 
\label{lgpl-section-6}
 
Now that we have established a good working definition of works that
 
``use'' and works that ``are based on'' the library, we will consider the
 
rules for distributing these two different works.
 

	
 
The rules for distributing ``works that use the library'' are covered in
 
LGPLv2.1~\S6\@. LGPLv2.1~\S6 is much like GPLv2~\S3, as it requires the release
 
of source when a binary version of the LGPL'd software is released. Of
 
course, it only requires that source code for the library itself be made
 
available. The work that ``uses'' the library need not be provided in
 
source form. However, there are also conditions in LGPLv2.1~\S6 to make sure
 
that a user who wishes to modify or update the library can do so.
 

	
 
LGPLv2.1~\S6 lists five choices with regard to supplying library source
 
and granting the freedom to modify that library source to users. We
 
will first consider the option given by \S 6(b), which describes the
 
will first consider the option given by \S~6(b), which describes the
 
most common way currently used for LGPLv2.1 compliance on a ``work that
 
uses the library.''
 

	
 
LGPLv2.1~\S6(b) allows the distributor of a ``work that uses the library'' to
 
simply use a dynamically linked, shared library mechanism to link with the
 
library. This is by far the easiest and most straightforward option for
 
distribution. In this case, the executable of the work that uses the
 
library will contain only the ``stub code'' that is put in place by the
 
shared library mechanism, and at runtime the executable will combine with
 
the shared version of the library already resident on the user's computer.
 
If such a mechanism is used, it must allow the user to upgrade and
 
replace the library with interface-compatible versions and still be able
 
to use the ``work that uses the library.''  However, all modern shared
 
library mechanisms function as such, and thus LGPLv2.1~\S6(b) is the simplest
 
option, since it does not even require that the distributor of the ``work
 
2based on the library'' ship copies of the library itself.
 

	
 
LGPLv2.1~\S6(a) is the option to use when, for some reason, a shared library
 
mechanism cannot be used. It requires that the source for the library be
 
included, in the typical GPL fashion, but it also has a requirement beyond
 
that. The user must be able to exercise her freedom to modify the library
 
to its fullest extent, and that means recombining it with the ``work based
 
on the library.''  If the full binary is linked without a shared library
 
mechanism, the user must have available the object code for the ``work
0 comments (0 inline, 0 general)