Legal Research on Open Source Software
Table of Contents
Open Source Relevant Law by
II. Patent Law
III. Copyright Law
IV. Contracts (Open Source Licenses)
V. Property Law
VI. Unfair Competition
Software Research by Monifa Clayton
A. Open Source Software Licenses
B. Contract Liability
D. Tort Liability
Legal Research and Issues on Open
Source Software by Brian S. Boyer
What is Open Source
What is the Original Property
Right of Software?
How Do Federal Property Rights Limit
Federal Preemption of State
Open Source –
Open source is the phenomenon where freelance programmers communicate
and contribute software code to improve on a project. The theory is
that more eyes looking at the code will result in faster discovery
and correction of errors than the traditional closed source code
system. There is no limit on the number of contributors as long as
the project remains open source.
Somehow, this seemingly disjointed system yields a workable
product/solution. The usual framework involves a project controlled
by a person/company with numerous other programmers all contributing
to and improving it. Each may be contributing to just a small part of
the whole project, yet all are working on the same project at the
same time. Issues raised by open source software may encompass many
different bodies of law. Each provides a different framework for
analysis either by a traditional approach or by analogy. The
following sections outline possible relevant law related to open
source software including: patent, copyright, contract, property, and
unfair competition law.
II. Patent Law
Patent law derives from Article I, Section 8, clause 8 of the U.S.
Constitution. It states that Congress shall have the power “ to
promote the progress of science and useful arts, by securing for
limited times to authors and inventors the exclusive right to their
respective writings and discoveries.” This one sentence is key
to the administration of the Federal patent laws. Inherent in its
meaning is the goal to grant a limited monopoly in exchange for
dedication of an invention to the public, thereby promoting the
progress of science.
Patent protection grants to the patent owner the right to exclude
others from making, using, selling, offering for sale, and importing
the claimed invention for a term of twenty years from the earliest
priority filing date. However, in order to ensure that only truly
deserving inventions are entitled to such exclusive rights, Congress
has imposed statutory requirements on patentability. First and
foremost is that patent protection only extends to certain subject
matter. In addition, there are statutory bars of novelty, utility,
and non-obviousness. These are the basic requirements.
Patentable Subject Matter:
Patentable subject matter is “any new and useful process,
machine, manufacture, or composition of matter, or any new and useful
improvement thereof.” 35 U.S.C. 101. In addition, there are
judicially created exceptions to the statutory subject matter
including laws of nature, mathematical algorithms, and methods of
doing business. Gottschalk v. Benson, 409 U.S. 63
(1972). Software is eligible for patent protection by falling into
either the category of a process or machine. However, the
mathematical algorithm exception from Benson has led to
additional requirements of patentability for software. These are
explained by the following cases.
In 1972, the Supreme Court found in Benson that an
algorithm alone, without more, is not patentable. At issue in
Benson was a mathematical algorithm whose sole function
is to convert binary-coded decimals into pure binary numbers. The
claim was found to be too abstract and sweeping as well as being
essentially a law of nature. At the time, Benson seemed
to indicate a trend that all software would be unpatentable, however,
later cases have clarified and narrowed its holding.
For example, in Diamond v. Diehr, the Supreme Court
held an algorithm patentable where it resulted in some physical
change as part of a larger process. Diamond v. Diehr,
450 U.S. 175 (1981). The claimed invention in Diamond
involved a computer using an algorithm to continuously compute the
necessary curing time of rubber. Actual temperature measurements are
constantly fed into the computer which then uses an algorithm to
calculate the precise curing time under the conditions reflected by
the measurements. Once the computed result matches the actual time
that the press has been closed, the computer will trigger opening the
press to yield perfectly cured rubber. Since the algorithm was but
one part of an industrial process that produced a useful, tangible
result, it was deemed patentable. Id.
From the teachings of Benson and Diamond,
the Federal Circuit went a step further in Arrhythmia.
The invention at issue in Arrhythmia involved an
algorithm that made calculations from an electrocardiogram and
subsequently compared the results to a predetermined value.
Arrhythmia Research Technology, Inc. v. Corazonix
Corporation, 958 F. 2d 1053 (1992). Here, although there was
no physical change like a press opening in Diamond, the
algorithm was deemed patentable because the number resulting from the
algorithm was not just an abstract number, but rather a signal
related to a patient’s heart activity. Id. In
fact, it was a measure in microvolts of a specified heart activity,
an indicator of the risk of ventricular tachycardia - a very specific
and useful result. From this line of cases, it now seems that
algorithms which are part of larger processes producing concrete,
tangible results, or which result in specific, useful information,
Although software is patentable subject matter within this framework,
it still has to meet other requirements of patentability such as
novelty, utility, and non-obviousness. Additionally, the term of
protection provided by a patent is around twenty years depending on
the circumstances whereas copyright protection is much longer –
life of the author plus seventy years. Overall it is difficult to
obtain a patent and hence most software protection is in the area of
copyright law. Likewise, the open source community modeled their GPLs
to address the requirements of copyright law.
III. Copyright Law
Copyright law, like patent law, is derived from the same
constitutional mandate as patent law, article I, section 1, clause 8
of the U.S. Constitution. “Copyrights are limited exclusive
rights owned by an author of original expressions that are fixed in a
tangible medium of expression.” 
The copyright owner’s exclusive rights are listed in 17 U.S.C.
[T]he owner of copyright under this title has the exclusive
rights to do and to authorize any of the following:
- to reproduce the copyrighted work in copies or
- to prepare derivative works based upon the copyright
- to distribute copies or phonorecords of the copyright work to
the public by sale or other transfer of ownership, or by rental,
lease, or lending;
- in the case of literary, musical, dramatic, and choreographic
works, pantomimes, and motion pictures and other audiovisual
works, to perform the copyrighted work publicly;
- in the case of literary, musical, dramatic, and choreographic
works, pantomimes, and pictorial, graphic, or sculptural works,
including the individual images of a motion picture or other
audiovisual work, to display the copyrighted work publicly,
- in the case of sound recordings, to perform the copyrighted
work publicly by means of a digital audio transmission. 
Unlike patent law where an inventor must get a patent from the PTO,
creating a copyright is automatic once the expression is fixed. “Copyright
subsists...in original works of authorship fixed in any tangible
medium of expression...” 
Software involves expression in a literal sense and thus falls under
Open source project owners take advantage of copyright laws by
claiming copyrights on their software. They then have the exclusive
right to make copies, distribute copies, and create derivative works.
If they just post the work and invite contributors to improve, copy,
and modify, which in essence is creating a derivative work, the
contributors may be liable for copyright infringement. In order to
abide by the copyright laws and ensure that no contributor to the
project will be liable for copyright infringement, owners issue
licenses with terms allowing such conduct.
17 U.S.C. Section 501 addresses the infringement of copyrights. Also
stated are the standing requirements of a plaintiff to bring an
action for infringement.
In order to bring an infringement action, the plaintiff must be the
legal or beneficial owner of exclusive rights under
open source by definition has many contributors, this could mean a
lot of plaintiffs. The section further states that the court may
require such owner to serve written notice of the action with a copy
of the complaint upon any person shown, by records of the Copyright
Office or otherwise, to have or claim an interest in the copyright,
and shall require that such notice be served upon any person whose
interest is likely to be affected by a decision in the case.
It will probably be prohibitively costly as well as difficult to
ascertain all that have an interest in the project.
17 U.S.C. 101
defines a derivative work as a work based upon
one or more preexisting works, such as a translation, musical
arrangement, dramatization, fictionalization, motion picture version,
sound recording, art reproduction, abridgment, condensation, or any
other form in which a work may be recast, transformed, or adapted. A
work consisting of editorial revisions, annotations, elaborations, or
other modifications which, as a whole, represent an original work of
authorship, is a “derivative work.”
Derivative works are the results of the many modifications made by
the contributing programmers to a project. The right to create a
derivative work is exclusive to the copyright owner, hence a license
is necessary to allow others to work on it. By granting the GPL,
copyright owners of the open source project is allowing for
derivative works conditioned on many terms, one of which is to
require that if there is distribution of any modifications of the
project, they must also distribute the source code for the modified
version as well.
17 U.S.C. Section 501
states that anyone who violates any of
the exclusive rights of the copyright owner as listed in Section 106
is an infringer. So by making a copy, derivative work, or
distribution without the owner’s consent will be an act of
infringement. In the world of software, what is the standard for
finding an infringement? How much of a code must be the same before
there is a presumption that it was copied and not created
Courts have compared source codes side by side to determine
infringement. In Cadence Design System Inc. v. Avant! Corp
the court found likelihood of success on an infringement claim even
though only fifty-six lines of code matched between the
argument was that even though the “quantitative amount of what
has been copied is minor, it still can be qualitatively significant.”
Again, an open source license will protect against suits of
infringement by the owners against the contributing programmers. It
would seem that the open source movement fits nicely into the
copyright scheme of intellectual property protection.
IV. Contracts (Open Source
An indispensable component of the open source movement is the open
source license. Owners of open source software rely on owning the
copyright in the code and then licensing it via a mass-marketing
approach similar to the old shrink-wrap/click-wrap licenses.
Generally, they are non-negotiable, take it or leave it licenses.
The terms of the licenses generally include the following:
- Redistribution – licensee may not restrict any
party from selling or giving away the software as long as the
source code is also distributed.
- Source code required – license will specify that
the program be in source code form so that a programmer may modify
- Derivative works – licensee has the right to
create derivative works and modifications. Licensee also has the
right to distribute those.
- Credit – licensee must continue to give credit to
those who have contributed if they so choose. This may include
prohibitions on using the name of an author to endorse products
derived from the original code if necessary.
- Warranties – open source software does not come
with any. It is the ultimate ‘as is.’ This includes no
warranties for performance as well as any future 3rd
party infringement claims.
- Future Licensing restrictions – the license will
provide that the same terms will also apply to any future license
that the licensee enters into.
The Uniform Commercial Code governs the sales of goods. It implies
warranties of merchantability as well as fitness into contracts.
UCC 2-314: Implied Warranty: Merchantability; Usage of
- Unless excluded or modified, a warranty that the goods shall
be merchantable is implied in a contract for their sale if the
seller is a merchant with respect to goods of that kind....
- Goods to be merchantable must be at least such as
- pass without objection in the trade under the contract
- in the case of fungible goods, are of fair average quality
within the description; and
- are fit for the ordinary purposes for which such goods are
- run, within the variations permitted by the agreement, of even
kind, quality and quantity within each unit and among all units
- are adequately contained, packaged, and labeled as the
agreement may require; and conform to the promise or affirmations
of fact made on the container or label if any.
: Implied Warranty: Fitness for Particular
Where the seller at the time of contracting has reason to know any
particular purpose for which the goods are required and that the
buyer is relying on the seller’s skill or judgment to select or
furnish suitable goods, there is unless excluded or modified under
the next section an implied warranty that the goods shall be fit for
The open source license addresses these sections by disclaiming all
warranties. However, the question still remains as to whether they
are enforceable. Courts may find that the disclaimer is
unconscionable. Also, since these are mass-market licenses where
there is neither negotiation nor ‘meeting of the minds,’
there is danger of a finding of contract of adhesion. On the other
hand, since the term is conspicuous and non-ambiguous, it may be
Enforceability of Open Source Licenses
At present, the closest analogy from contract law to open source
licenses is the shrink-wrap/click-wrap licenses for software.
Shrink-wrap licenses are where the terms are visible through the
shrink-wrap boxes containing the software program. By breaking the
shrink-wrap, the buyer has agreed to the terms for using the software
and a contract is formed. Click-wrap licenses are those usually
encountered when a user downloads a program from the Internet and
must click the “I accept” button on the screen with the
license terms before being given access to the program. Again, a
contract is formed. (The foregoing is generally true, but the
enforceability of software mass-market licenses is still
The enforceability of mass-market licenses was proposed by UCC
Article 2B. However it was abandoned due to resistance but was again
proposed in the Uniform Computer Information Transactions Act
(UCITA). UCITA “upholds the enforceability of mass-market
licenses but requires affirmative manifestation of assent by the
licensee, a right to return for refund the software if there is no
agreement until after payment, and provided that the form license
cannot conflict with expressly negotiated terms.” 
Case law has focused on several factors to evaluate enforceability of
click-wrap licenses. They include “whether the consumer
received adequate notice of the license, whether sufficient
competition in the market existed to equate the relative bargaining
strengths of the transacting parties, and whether the consumer
received adequate time to review the license and return the software.”
cases all discuss the enforceability of shrink-wrap/click-wrap
Caspi v. Microsoft Network
, 732 A.2d 528 (N.J. Super Ct
App. Div. 1999).
Storm Impact, Inc. v. Software of the Month Club
, 13 F.
Supp. 2d 782 (N.D. Ill 1998).
ProCD v. Zeidenberg,
86 F.3d 1447 (7th
M.A. Mortenson Co. v. Timberline Software Corp.,
P.2d 803 (Wash. Ct. App. 1999).
Hotmail Corp. v. Van$ Money Pie, Inc,
1020 (N.D. Cal. 1998).
Overall, the enforceability of the shrink-wrap/click-wrap licenses
has been upheld subject to certain procedural requirements. The fate
of open source licenses remains to be tested while case law on the
shrink-warp/click-warp licenses may serve as a useful framework for
V. Property Law
Ownership of an open source project
includes many rights that can be analogized to traditional property
rights in land. Currently, most of the behavior and procedures in the
open source community is enforced by unspoken custom. However, some
of the customs followed show a remarkable similarity to property
concepts regarding land.
Generally, adverse possession is when one obtains ownership of land
without the permission of the owner. The rationale behind adverse
possession is that use of land is beneficial to the community. Also,
adverse possession rewards and encourages possessors who use land
productively and punishes owners who neglect their land. In the open
source community, if a project is not being worked on and someone
else has an interest in working on it, they may seek to claim it.
This is akin to land standing idle and someone else wanting to
Similar to adverse possession in real property, to claim a project in
the open source community, one must satisfy certain requirements.
First, the prospective owner must give notice that he is interested
in taking over the project. After an unspecified period of time where
there is no other competing claim, the prospective owner may declare
that he is now the owner of the project and is formally assuming
control over it. Adverse possessors follow the same pattern. They
stay on the land and
Due to the similarities in the two worlds, case law discussing
specific factors of adverse possession may be useful in determining
how to resolve competing claims of ownership. For example, when the
issue is whether there was adequate notice, or if the period of time
was sufficiently long to warrant a finding that the original owner is
no longer interested in claiming ownership analogy may be made to
real property situations.
Transfer of Title:
Similar to real property, there is a chain of title in open source
software. When a project changes hands, it is announced to relevant
communities as well as recorded in a file within the software itself.
This is analogous to the act of recording a deed to announce a change
of title in real property.
VI. Unfair Competition
Right of Publicity:
Restatement of Law, Third, Unfair Competition Section 46
states: One who appropriates the commercial value of a person’s
identity by using without consent the person’s name, likeness,
or other indicia of identity for purposes of trade is subject to
This statute may be relevant in a situation where someone runs a
project under the guise of a well-known control person’s name
to attract more contributors. However, the statute is really focused
on the commercial value of a person’s identity. In the open
source community where the benefits of being well-known may not be
directly commercial but rather more reputational, the requirement of
some commercial value may bar such actions.
Restatement of the Law, Third, Unfair
Competition Section 49 states: One who is liable
for an appropriation of the commercial value of another’s
identity...is liable for the pecuniary loss to the other caused by
the appropriation or for the actor’s own pecuniary gain
resulting from the appropriation, whichever is greater.
The monetary relief allowed in this section would not help the
well-known control person who’s name was used without his
permission because there is no pecuniary loss nor gain in the use.
Since the wrongful user is offering the software for free, he is not
gaining any monetary rewards.
Restatement of the Law, Third, Unfair Competition Section 48
provides: If appropriate...injunctive relief may be awarded to
prevent a continuing or threatened appropriation of the commercial
value of another’s identity.
This injunctive relief will help stop any wrongful use of a
well-known control person’s name or other identifying indicia.
However, the control person must prove some sort of ????
Open source issues can potentially touch
on many bodies of existing law. It would seem that the world is
currently adopting this open source development model. Many of the
issues raised in this increasingly popular model fall within
traditional contract or copyright law. In fact, open source software
falls nicely within the existing copyright law framework. However,
when open source is more popular, it may be necessary to have a
formal statutory scheme codifying all the things that are currently
strictly followed as ‘customs’ in the open source
community. The courts will likely be addressing these issues in the
next few years as the model is becoming more accepted and cases make
their way into court. A great resource for further background and
links to information regarding open source is available at the
Anawalt & Elizabeth Enayati Powers, IP Strategy, 1-76 (West
17 U.S.C.A. 106
17 U.S.C.A. 102
17 U.S.C.A. 501
Sys. V. Avant! Corp., 1999 U.S. App. LEXIS 18302 *5.
Ravicher, Facilitating Collaborative Software Development: The
Enforceability of Mass-Market Public Software Licenses, 5 Va. J.L.
& Tech. 11, *54 (Westlaw, 2000).
Source Software Research
by Monifa Clayton
A. OPEN SOURCE SOFTWARE LICENSES
Software programmers do not place open source software in the public
domain. They generally license and copyright the software. This is an
important distinction because it means that there is an individual or
organization that claims legal ownership of the software and is
therefore able to control what is done with the software’s
source code. By licensing and copyrighting open source software,
programmers are able to ensure that the software remains ‘open’
and therefore widely available and modifiable by other programmers.
Without licenses, open source software could be ‘closed’
and turned into a proprietary system.
The characterization of software as ‘open source’ is
controlled by the open source community. In order for software to be
characterized as ‘open source’ by the open source
community it must meet certain principles found in “The Open
Source Definition,” published by the Open Source Initiative,
and in sample licenses published by Free Software Foundation. The
Open Source Definition, which is found at
www.opensource.org.isd.html, requires that open source software
comply with the following criteria:
- Free Distribution. The license may not restrict any
party from selling or giving away the software as a component of
an aggregate software distribution containing programs from
several different sources. The license may not require a royalty
or other fee for such sale.
- Source Code. The program must include source code, and
must allow distribution in source code as well as compiled form.
... 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 output of a
preprocessor or translator are not allowed.
- Derivative Works. The license must allow modification
and derived works, and must allow them to be distributed under the
same terms as the license of the original software.
- 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.
- No Discrimination Against Persons or Groups. The
license must not discriminate against any person or group of
- 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
- Distribution of License. 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
- 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
- License must Not Contaminate 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.
These criteria help promote the open source community’s goals
of free distribution and modification. Several types of licenses have
been created to meet these requirements. Examples of licenses that
meet this open source software criterion include GNU General Public
License, GNU Library General Public License, Mozilla Public License
and Netscape Public License. Although these licenses and other
current open source licenses have not yet been the source of
litigation, several forms of civil liability might be applicable to
open source software. In addition, it has yet to be determined in
court whether or not these licenses and copyright will be legally
B. CONTRACT LIABILITY
Like other forms of software licensing, open source software
licensing uses shrink-wrap licenses and click-wrap licenses in order
to bind end users of the licenses to the terms and conditions of
software licenses. A user agrees to the terms of the license by
opening the shrink-wrap or clicking a consent button. These licenses
are generally called mass-market licenses because they are
standardized, non-negotiated licenses that bind users if they choose
to use the software. Both shrink-wrap and click-wrap licenses have
generally been found to be legally enforceable by the courts for
other types of software licenses. ProCD, Inc. v. Zeidenberg
86 F.3d 1447 (7th
Cir. 1996); Compuserve, Inc. v.
, 89 F.3d 1257 (6th
Cir. 1996). However,
these cases still leave some level of uncertainty as to whether these
licenses can always be created and enforced.
Therefore, the Uniform Computer Information Transaction Act (“UCITA”),
formerly known as Article 2B of the Uniform Commercial Code, has been
proposed to control licenses and add certainty to the enforceability
of mass-market licenses, such as open source software licenses. The
UCITA was drafted by the National Conference of Commissioners on
Uniform State Laws and serves the same function for software
licensing as the Uniform Commercial Code plays for the sale of goods.
It provides clear guidance on the rights and responsibilities of
parties establishing commercial contracts dealing with transactions
covering computer software, Internet and online information,
multimedia interactive products and computer data and databases. The
UCITA allows parties the freedom to contract for the terms they
desire, but also provides a set of default rules on issues that are
not discussed or covered by the contract.
The UCITA validates most of the standard mass-market licensing
practices, including the types of practices found in open source
software licensing. Section 102 of the UCITA defines mass-market
licenses as a “standard form used in a mass-market transaction.”
A mass-market transaction is any transaction that is:
(A) a consumer contract; or
(B) any other transaction with an end-user licensee if:
(i) the transaction is for information or informational rights
directed to the general public as a whole, including consumers, under
substantially the same terms for the same information;
(ii) the licensee acquires the information or informational rights in
a retail transaction under terms and in a quantity consistent with an
ordinary transaction in a retail market; and
(iii) the transaction is not:
(I) a contract for redistribution or for public performance or public
display of a copyrighted work;
(II) a transaction in which the information is customized or
otherwise specially prepared by the licensor for the licensee, other
than minor customization using a capability of the information
intended for that purpose;
(III) a site license; or
(IV) an access contract.
According to this definition, open source software licensing would
qualify as mass-market software transactions and therefore would be
subject to the provisions of the UCITA.
The UCITA also clearly defines when a software license will
constitute a legally enforceable contract. Most relevant to open
source software licensing is when a license will be considered “agreed
to” by the licensee. Section 209(a) of the UCITA provides that “[a]
party adopts the terms of a mass-market license for purposes of
Section 208 only if the party agrees to the license, such as by
manifesting assent, before or during the party's initial performance
or use of or access to the information.” This provision would
recognize assent to standard software licenses through means such as
opening shrink-wrap licenses and clicking the appropriate button on
click-wrap and web-wrap licenses. These types of manifestations of
assent on mass-market software are critical to open source software.
In order for the software to be freely distributed and modifiable,
the terms of the licenses must be enforceable.
The UCITA has not yet been enacted. However, enactment of the UCITA
would provide certainty as to the enforceability of open source
software license, which is currently lacking in the present court
opinions. [Other information about the UCITA, including the
full-text of the UCITA, can be found at www.ucitaonline.com.]
Open source software may also have to meet current Uniform Commercial
Code implied warranties. Open source software generally does not
contain any express warranties and disclaims all implied warranties.
However, it has not yet been determined whether the court will permit
software developers to disclaim all implied warranties, such as the
Uniform Commercial Code’s implied warranties of merchantability
and fitness for a particular purpose.
The implied warranty of merchantability requires that in order for
goods to be merchantable, they must “pass without objection in
the trade under the contract description” and be “fit for
the ordinary purposes for which such goods are used.” The
implied warranty of fitness for a particular purpose requires that “[w]here
the seller at the time of contracting has reason to know any
particular purpose for which the goods are required and that the
buyer is relying on the seller’s skill or judgment to select or
furnish suitable goods,” the goods must be suitable for that
particular use. If a product fails to meet the standards of these
warranties, an open source software distributor may be held liable
for breach of contract. Although disclaimers of these implied
warranties are generally upheld, a disclaimer will not be upheld if
the contract is found to be unconscionable or adhesionary.
Open source software qualifies as copyrightable subject matter under
the federal Copyright Act of 1976, because it will generally meet the
requirements of being an “[o]riginal work of authorship
fixed in any tangible medium of expression” under 17 U.S.C.
§102(a). Copyright protection will allow the copyright owner to
sue any person who infringes the exclusive rights of the copyright
owner. Under 17 U.S.C. §106, copyright owners have five
exclusive rights: (1) the right to reproduce the copyrighted work,
(2) the right to prepare derivative works based upon the copyright
work, (3) the right to distribute copies of the copyrighted work, (4)
the right to publicly perform the copyrighted work, and (5) the right
to publicly display the copyrighted work. However, in order to
qualify as open source software under the definition followed by the
open source community the software license must relinquish most, if
not all, of these rights.
The licenses must give up the exclusive right to distribute, perform,
display and, most importantly, to create derivative rights. It is
critical that open source software remains accessible to the public
to modify and improve the software. Without the relinquishment of
these rights, open source software would be a proprietary system.
However, even without the retention of these exclusive rights,
copyright still serves an important function.
Copyright law allows software programmers to place restrictions
against individuals from establishing proprietary rights on software
that were meant to be open source. Copyright law provides the open
source software developer the most convenient way to ensure that open
source software remain “open.” If the software was placed
in the public domain, instead of being copyrighted, there would be no
legal way to prevent the source code from being “closed.”
Because no open source software licensor has sued a licensee for
copyright infringement, the courts have not yet ruled on the validity
of open source software copyright or on the potential damages that
could be assessed. However, there does not appear to be anything
about open source software copyright that would seem to make it
invalid. If the court were to find an infringement of a valid
copyright, then an infringer could be liable for statutory damages of
as much as $20,000 per infringement or even $100,000 per infringement
for willful infringement.
D. TORT LIABILITY
Open source software licenses also present potential tort liability
for negligence and other forms of product liability. Software can
cause both property damage and economic loss to businesses running
that software. In order to recover for negligence, a party must prove
(1) duty, (2) breach of duty, (3) causation, and (4) damages.
Although causation and damages may be relatively easy to prove, a
plaintiff will probably have a difficult time proving who owed and
breached the duty, and to whom that duty is owed. It is not clear
whether project developers or other developers could be found to owe
a duty to other open source software users.
As the prior discussion pointed stated, open source software has yet
to be litigated. Therefore, it is difficult to determine with any
certainty: (1) whether open source software licenses will be
enforceable, (2) whether open source software copyright will be
valid, or (3) whether open source software licenses will subject
developers to tort liability. It also remains to be seen, whether the
open source community can retain the level of control it currently
has over open source software.
Legal Research on Open
by Brian S. Boyer
is Open Source Software?
“Open-source software” is the concept that an
expressive work can be better utilized and developed by allowing open
access to the source code. The source code may be intellectual
property that is protected by federal copyright laws, should the
author choose to exercise those rights, but the author can forego
this protection either by abstaining from enforcing them or by
offering a license to others. The software community could just allow
this to happen without requiring licensing, but the safest way for
those producing such derivative works from material protectible by
the copyright laws is to obtain a general public license for such
use. Otherwise, any derivative works produced from the source code
could be the subject of an infringement suit.
The open-source concept works after an original version
is released on the market. Software users from all walks of life are
permitted access to the protectible source code and can stress it in
ways that the original developer may not have considered or would not
have had the expertise to consider. Development of a program from
scratch would probably not be successful with open source access.
Linus Torvald used the concept of open-source software to develop
Linux under the philosophy that “enough eyes make all bugs
shallow.” Thus, the concept is based on the premise that sheer
numbers of “eyes” can develop and implement a program
more efficiently. Torvald openly states that he is essentially a lazy
person that likes to take credit for the work of others.
An interesting path of inquiry is what happens to various
property rights that follow from the original software program that
has its own copyright protection. Each development that follows from
the original program is a derivative work. Such derivative work has
its own copyright protection but cannot be copied, distributed, used
to produce additional derivatives, publicly performed or displayed,
without permission of the original copyright owner. Such permission
is provided by contract, and federal copyright law determines the
scope of such contracts.
What is the
Original Property Right of Software?
The computer program may have aspects that are
protectible under patent, copyright, trademark, or trade secret laws,
but copyright law will be used here to illustrate the most prevalent
protection over the computer program. The copyright law protects
computer software as “a set of statements or instructions to be
used directly or indirectly in a computer in order to bring about a
certain result.” 17 USC §101. Copyright protects the
expressive elements of a program, and any literal parts of the
program such as source code and object code are protected. Any “idea”
components are not protected and can be reverse-engineered to serve
as the source of development by other authors. Computer Assoc v.
Altai (2d Cir 1992)(stating non-literal parts of a software
program such as general flow charts, organization of inter-modular
relationships, parameter lists, and macros are also protected, as
long as they are not incident to (merge with) the idea being
expressed.) 17 USC §102(a)(stating literary works are protected,
and that computer programs are a literary work); 17 USC 102(b)(ideas
are not protected). The difficulty is in separating idea from
expression, since computer programs are useful.
By allowing protectible aspects of a software program to
be accessed, modified, and redistributed, the owner of a copyrighted
work is foregoing his exclusive right to reproduce, distribute, and
produce derivative works. 17 USC §106 (listing the copyright
owner’s exclusive rights to reproduce, distribute, prepare
derivative works, perform the work publicly, and display the work
How Do Federal
Property Rights Limit Contract Law?
An open-source software license is a contract, which is
governed and enforced under state law. However, the scope of
provisions that may be controlled by the state is limited by federal
copyright law. 17 USC §301 (state law creating legal or
equitable rights equivalent to any exclusive rights under copyright
law is preempted.) Contract law is limited by copyright law in two
1. State law cannot restrict use of unprotected aspects
of a software program by providing that such use may be a breach of
contract. Computer Assoc v. Altai (2d Cir 1992)(§301 only
preempts those “state rights that may be abridged by an act
which, in and of itself, would infringe one of the exclusive rights
provided by federal copyright law.”)
2. Federal law can place restrictions on contract terms,
for example, by requiring a writing requirement for transference of
exclusive copyrights. 17 USC §204(a).
Preemption of State Law
Until 1978, state law controlled unauthorized copying,
sale, and performance of unpublished works through common-law
copyright law. Now, federal protection attaches as soon as the work
is fixed in a tangible medium of expression. There are essentially
two forms of federal preemption of state law: field preemption and
conflict preemption. Field preemption occurs where the entire body of
law in that particular field is consumed by federal law under
Constitutional and Congressional mandate. An example would be the
fields of patent law and copyright law, which are legislation based
on Art. I, §8, Cl.8 of the Constitution. Conflict preemption
occurs where the application of state law conflicts with the purpose
of federal law. An example would be a state law that attempts to
prohibit public access to unpatentable subject matter. Bonito
Boats v. Thunder Craft Boats (US 1989)(holding that unpatentable
boat hulls cannot be protected under state law that wants to protect
industry, since ideas that do not meet patent standards are open to
public.) The general principle of preemption is that federal law is
supreme over state law under the Supremacy Clause of Art. VI, Cl.2 of
the Constitution. There are two categories of works that may survive
federal copyright law preemption: anything not fixed on tangible
medium, such as oral works, choreography, live broadcasts, etc. that
are not recorded; and, works that violate rights not equal to those
in §106, such as breach of contract, trespass, conversion,
invasion of privacy, etc.
Some state laws contain elements of federal laws that
would otherwise preempt, but also contain extra elements that
preclude such federal preemption. For example, the state unfair
competition laws of passing off and misappropriation are essentially
tort laws that resemble infringement under federal laws but may have
extra elements and be premised on a different state objectives.
Passing-off is essentially promoting the goods or services of another
as your own, and misappropriation is the copying of another’s
work and calling it your own. In both cases, the damage is the
unauthorized use of the goodwill earned by another, and the state
objective is to avoid the likelihood of consumer confusion. Int’l
News Service v. AP (US 1918)(held that INS misappropriated AP’s
news and marketed it as its own.) Thus, the state purpose of
prohibiting misappropriation and passing off is different than the
federal purposes of intellectual property law, which is based on
control over property as an incentive to create rather than consumer
protection. Another state concern may be that a competitor
should not be able to reap where he has not sown. Id. In
essence, states can regulate where Congress decides the subject
matter is outside of the purposes of Art. I, §8, Cl.8, and thus
requires neither federal protection nor freedom from restraint.
Bonito Boats v. Thunder Craft Boats (US 1989). Further,
conflicting state law is not preempted if the regulation does not
impermissibly conflict with federal policy. Id.