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.

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, are patentable.
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.

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.” ^[1] The copyright owner’s exclusive rights are listed in 17 U.S.C. 106.

[T]he owner of copyright under this title has the exclusive rights to do and to authorize any of the following:

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...” ^[3] Software involves expression in a literal sense and thus falls under copyrights.
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.

Standing:
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.^[4] In order to bring an infringement action, the plaintiff must be the legal or beneficial owner of exclusive rights under copyright.^[5] Since 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.^[6] It will probably be prohibitively costly as well as difficult to ascertain all that have an interest in the project.

Derivative Work:
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.

Copyright Infringement:
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 independently?
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 programs.^[7] The argument was that even though the “quantitative amount of what has been copied is minor, it still can be qualitatively significant.”^[8]
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.

Licenses:
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:

Implied Warranties:
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 Trade.

UCC 2-315: Implied Warranty: Fitness for Particular Purpose.
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 such purpose.

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 upheld.

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 evolving)
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.” ^[9]
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.” ^[10] The following cases all discuss the enforceability of shrink-wrap/click-wrap licenses:
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 (7^th Cir. 1996).
M.A. Mortenson Co. v. Timberline Software Corp., 970 P.2d 803 (Wash. Ct. App. 1999).
Hotmail Corp. v. Van$ Money Pie, Inc, 47 U.S.P.Q.2d 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 analysis.

Adverse Possession/Abandonment:
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 possess it.
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.

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 liability...
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.

Remedies:

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 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:

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 enforced.

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 (7^th Cir. 1996); Compuserve, Inc. v. Patterson, 89 F.3d 1257 (6^th 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.

C. COPYRIGHT INFRINGEMENT

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 Source Software

by Brian S. Boyer

What 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 publicly.)

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 ways:

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).

Federal 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.