United_States_of_America.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<?asciidoc-toc?>
<?asciidoc-numbered?>

<article lang="en">
<articleinfo>
    <date>2017-05-18</date>
</articleinfo>
<section id="chap.usa">
<title>United States of America</title>
<simpara>author:[Webbink,Mark H.]</simpara>
<section id="sec_introductionusa">
<title>Introduction to software protection under United States law</title>
<section id="sec_bodyusa">
<title>Body of law</title>
<simpara>Rights in software in the United States arise from a mixture of federal and state law and the interpretation of those laws by the various courts. Software may be protected by a combination of copyright, patent, trademark, and trade secret law. Further, the licensing of rights in software is subject to contract law, bankruptcy law, antitrust (competition) law, uniform state laws, tax law, export control law, and other specialized federal and state statues.</simpara>
<simpara>Copyright and patent protection of software arises under Section 8, Article 1 of the U.S. Constitution.<footnote><simpara>&#8220;(Congress shall have the power&#8230;) 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.&#8221;</simpara></footnote> The Copyright Act is embodied in Title 17 of the U.S. Code, the statutes that implement the Constitutional directive.<footnote><simpara>17 U.S. Code may be found at <ulink url="http://www.law.cornell.edu/uscode/html/uscode17/usc_sup_01_17.html">http://www.law.cornell.edu/uscode/html/uscode17/usc_sup_01_17.html</ulink>.</simpara></footnote>  The Patent Act is embodied in Title 35 of the U.S.  Code.<footnote><simpara>35 U.S. Code may be found at <ulink url="http://www.law.cornell.edu/uscode/html/uscode35/usc_sup_01_35.html">http://www.law.cornell.edu/uscode/html/uscode35/usc_sup_01_35.html</ulink>.</simpara></footnote>  Both copyright and patent law fall within the exclusive jurisdiction of the U.S. Federal government.</simpara>
<simpara>To the extent the publisher of software claims a trademark applicable to that software, such trademark rights may arise under federal trademark law, state trademark law, or common law rights in trademarks. Federal trademark law is embodied in the Lanham Act, Title 15, Chapter 22 of the U.S. Code.<footnote><simpara>15 U.S. Code Chapter 22 may be found at <ulink url="http://www.law.cornell.edu/uscode/15/usc_sup_01_15_10_22.html">http://www.law.cornell.edu/uscode/15/usc_sup_01_15_10_22.html</ulink>.</simpara></footnote>  State trademark law is generally embodied in state statutes of the various states. In the U.S. rights in a trademark may arise under common law from mere usage.</simpara>
<simpara>Software may also be protected by trade secret law. Trade secrets are most commonly protected under a uniform state law (that is, a law that has been adopted in substantially the same form among a large number of states) like the Uniform Trade Secrets Act.<footnote><simpara>For example, the Uniform Trade Secrets Act as embodied in California state law may be found at <ulink url="http://www.leginfo.ca.gov/cgi-bin/displaycode?section=civ&#038;group=03001-04000&#038;file=3426-3426.11">http://www.leginfo.ca.gov/cgi-bin/displaycode?section=civ&#038;group=03001-04000&#038;file=3426-3426.11</ulink>.</simpara></footnote>  There is a federal statute on trade secrets, as well, but it is less commonly relied upon for contractual protection of software.<footnote><simpara>The Economic Espionage Act of 1996 found at 18 U.S. Code §§1831-1839, <ulink url="http://www.law.cornell.edu/uscode/18/1831.html">http://www.law.cornell.edu/uscode/18/1831.html</ulink>.</simpara></footnote></simpara>
<simpara>Of the remaining areas of law that may govern a software license, none is more important than contract law. Contract law in the U.S. is largely within the purview of state law, and U.S. courts give contracting parties a great deal of deference in determining the contractual terms that will govern their relationship. As a consequence, parties may, within limits, contract away rights and/or protections otherwise granted under copyright, patent, trademark or trade secret law.</simpara>
</section>
<section id="sec_protectionusa">
<title>Copyright protection of software</title>
<simpara>Software is protected by copyright and is equivalent to literary works within the meaning of the Berne Convention for the Protection of Literary and Artistic Works as established by the World Intellectual Property Treaty of 1996.<footnote><simpara>World Intellectual Property Copyright Treaty of 1996 found at <ulink url="http://www.wipo.int/treaties/en/ip/wct/trtdocs_wo033.html#P45_2379">http://www.wipo.int/treaties/en/ip/wct/trtdocs_wo033.html#P45_2379</ulink>.</simpara></footnote>  Software was recommended for formal inclusion under copyright in the U.S. in the final report of the National Commission on New Technological Uses of Copyrighted Works (CONTU)<footnote><simpara>The final report of the National Commission on New Technological Uses of Copyrighted Works found at <ulink url="http://digital-law-online.info/CONTU/contu1.html">http://digital-law-online.info/CONTU/contu1.html</ulink>.</simpara></footnote>, the recommendations of which were incorporated in the Copyright Act of 1976.<footnote><simpara>The U.S. Copyright Act of 1976 found at <ulink url="http://en.wikisource.org/wiki/Copyright_Act_of_1976">http://en.wikisource.org/wiki/Copyright_Act_of_1976</ulink>.</simpara></footnote>  Inclusion of software under copyright was further clarified with amendments to the Copyright Act adopted in 1980 that defined a computer program as &#8220;&#8230;&#160;a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result&#8221; and by limiting the rights in computer programs to assure the right of a lawful possessor to make a back-up or archival copy of the program.<footnote><simpara>Public Law 96-517 found at <ulink url="http://law.copyrightdata.com/amendments.php">http://law.copyrightdata.com/amendments.php</ulink>.</simpara></footnote></simpara>
<simpara>It is important to note that in the U.S. copyright protection of software extends to each of the source code and binary versions of the software. While copyright in software arises automatically when it is &#8220;&#8230;&#160;created and fixed in a tangible form that it is perceptible either directly or with the aid of a machine or device&#8221;<footnote><simpara>17 U.S.C. §102(a).</simpara></footnote>, enforcement of copyright in the U.S. requires registration of the copyright with the U.S.  Copyright Office.<footnote><simpara>17 U.S.C. §411(a).</simpara></footnote></simpara>
</section>
<section id="sec_authorsusa">
<title>Authors/Beneficiaries</title>
<simpara>Section 102 of the U.S. Copyright Act (the &#8220;Act&#8221;) provides copyright protection for &#8220;original works of authorship fixed in any tangible medium of expression.&#8221;<footnote><simpara>17 U.S. Code §102(a).</simpara></footnote> Nothing more is required. Thus, whatever ownership interests exist in the copyright commences with the reduction of the expression to some tangible medium, whether paper or an electronic file.</simpara>
<section id="_the_sole_developer">
<title>The sole developer</title>
<simpara>Section 201(a) of the Act provides that copyright protection in a work &#8220;vests initially in the author or authors of the work.&#8221;<footnote><simpara>17 U.S. Code §201(a).</simpara></footnote> In the case of a sole developer, copyright in the software code will vest with her as the sole owner upon fixation of the code in a tangible medium of expression. That is, once she types and saves the code, fixing it in the computer&#8217;s memory, she now owns the copyright in that code.  Nothing more is required of the developer to own the copyright.</simpara>
</section>
<section id="_works_for_hire">
<title>Works for hire</title>
<simpara>In the case of a developer writing software code within the scope of her employment, the resulting work is known as a &#8220;work made for hire.&#8221; With a work made for hire, &#8220;the employer or other person for whom the work was prepared is considered the author for purposes of [the Act],&#8221; and the owner of the copyright in the work.<footnote><simpara>17 U.S. Code §201(b).</simpara></footnote> The developer and her employer may agree otherwise, where ownership remains with the developer, through an express agreement in a written instrument signed by both parties.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> The intention of the developer and her employer, expressed before the code is written, will dictate who owns the copyright in the resulting work.</simpara>
<simpara>The result changes where the software developer is not an employee.  Software is not a form of copyrightable material that statutorily falls under the list of special order or commissioned works within the scope of works made for hire unless it constitutes a commissioned contribution to a collective work.<footnote><simpara>17 U.S. Code §101.</simpara></footnote>  Thus, the transfer of ownership of software produced outside of the scope of employment must be supported by express contractual language in writing.<footnote><simpara>17 U.S. Code §204.</simpara></footnote></simpara>
</section>
<section id="_joint_ownership">
<title>Joint ownership</title>
<simpara>Section 201(a) of the Act further provides that &#8220;[t]he authors of a joint work are co-owners of copyright in the work.&#8221;<footnote><simpara>17 U.S. Code §201(a).</simpara></footnote> Joint authorship in a work arises when &#8220;a work is prepared by two or more authors <emphasis>with the intention that their contribution be merged into inseparable and interdependent parts of a unitary whole</emphasis> [emphasis added].&#8221;<footnote><simpara>17 U.S. Code §101.</simpara></footnote>  The hallmark of joint authorship is the authors' &#8220;joint laboring in furtherance of a preconcerted common design.&#8221;<footnote><simpara>1-6 Melville B. Nimmer, Nimmer on Copyright §6.03. Nimmer is only available in hard copy from LexisNexis or in electronic form from either the LexisNexis or Westlaw legal research services. Nimmer is widely considered the authoritative treatise on U.S. copyright law.</simpara></footnote>  That is, each contributor must intend for their contributions to be merged; however, it is not necessary that the contributors &#8220;work in physical propinquity, or in concert, nor that the respective contributions made by each joint author must be equal in quantity or quality.&#8221;<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> Furthermore, it is not necessary that the contributors expressly agree, in writing, to create a joint work.<footnote><simpara><emphasis>See, Id.</emphasis></simpara></footnote></simpara>
<simpara>The touchstone of joint authorship is the intention of the joint authors that their contributions be merged at, or before, the moment in time when the contribution of each joint author is created.<footnote><simpara>1-6 Nimmer §§6.02, 6.03.</simpara></footnote> That is, two developers, who intend that the code they contribute to a project be merged into inseparable and interdependent parts of a unitary whole must express that intent before development commences, and each will own an equal and &#8220;undivided ownership in the entire work.&#8221;<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote></simpara>
<simpara>So long as the intent to create a joint work exists prior to the commencement of work, it is even possible for joint authorship to occur &#8220;even though the joint authors do not work together in their common design, do not make their respective contributions during the same period, and indeed even if they are complete strangers to each other.&#8221;<footnote><simpara>1-6 Nimmer §6.03.</simpara></footnote> This situation is common among developers working independently in developing software modules that are to be included in a unified open-source project. The intent and timing of these developers will dictate who owns the copyright in the resulting work.</simpara>
<simpara>The joint authors are the co-owners of a single copyright in the joint work.<footnote><simpara>17 U.S.C. §201(a).</simpara></footnote> However, joint authorship is not the only means by which joint ownership of a work may arise.</simpara>
<blockquote>
<attribution>
1-6 Nimmer §6.01.
</attribution>
<simpara>A joint work will result under any one of the following circumstances: (1) if the work is a product of joint authorship; (2) if the author or copyright proprietor transfers such copyright to more than one person; (3) if the author or copyright proprietor transfers an undivided interest in such copyright to one or more persons, reserving to himself an undivided interest; (4) if upon the death of the author or copyright proprietor, such copyright passes by will or intestacy to more than one person; (5) if the renewal rights under the Copyright Act or the terminated rights under the termination of transfers provisions, vest in a class consisting of more than one person; (6) if the work is subject to state community property laws.</simpara>
</blockquote>
<simpara>Each co-owner of a joint work &#8220;obtains an undivided ownership in the whole of the joint work, including any portion thereof.&#8221;<footnote><simpara>1-6 Nimmer §6.06(A).</simpara></footnote> In other words, each co-owner may use or license the work, without the consent of other co-owners, in any way she may wish.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> Co-owners of a copyright do, however, owe to each other a duty to account for any income derived from their use or license of the work.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote></simpara>
</section>
<section id="_the_derivative_work">
<title>The derivative work</title>
<simpara>The Act also protects derivative works and compilations.<footnote><simpara>17 U.S.C. §103(a).</simpara></footnote> A derivative work is a work based in whole, or in substantial part, upon a pre-existing work that recasts, transforms, or adapts the underlying work in some way.<footnote><simpara>17 U.S.C. §101.</simpara></footnote> For copyright protection to extend to a derivative work, &#8220;the additional matter injected in a prior work, or the manner of rearranging or otherwise transforming a prior work, must constitute more than a minimal contribution.&#8221;<footnote><simpara>1-3 Nimmer § 3.03(A) (citing Feist Publications, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 348, 111 S. Ct. 1282, 113 L. Ed. 2d 358 (1991); Siegel v. Time Warner Inc., 496 F. Supp. 2d 1111, 1151 (C.D. Cal. 2007); Sherry Mfg. Co. v.  Towel King of Fla., Inc., 753 F.2d 1565 (11th Cir. 1985); Montgomery v. Noga, 168 F.3d 1282, 1290 n.12 (11th Cir. 1999); Moore Pub., Inc.  v. Big Sky Mktg., Inc., 756 F. Supp. 1371, 1374, 1378 (D. Idaho 1990)).</simpara></footnote> Since most new works are influenced, in some way, by a pre-existing work, there exists a fine line between a derivative work and an entirely new work.<footnote><simpara>Lothar Determan, <emphasis>Dangerous Liaisons&#8201;&#8212;&#8201;Software Combinations as Derivative Works?  Distribution, Installation, and Execution of Linked Programs Under Copyright Law, Commercial Licenses, and the GPL</emphasis>, 21 Berkeley Tech. L. J. 1421, 1430 (2006).</simpara></footnote> If a developer uses very little of a pre-existing work, taking only code not protected by copyright (like a basic function), or if she uses the pre-existing code in such a way that the resulting program is substantially different from the original, the new creation is simply a new, original work of authorship and not a derivative work.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote></simpara>
<simpara>Ownership of a separate copyright in a derivative work not only requires more than a minimal contribution to the prior work, but also permission from the owner or owners of the copyright in the prior work. Even with such permission, the creator of the derivative work will own the copyright in only that portion of the derivative work he contributed and not in any portion of the pre-existing work upon which the derivative work is based.<footnote><simpara>1-6 Nimmer, §6.05.</simpara></footnote></simpara>
</section>
<section id="_compilations_and_collective_works">
<title>Compilations and collective works</title>
<simpara>Finally, the Act protects interests in compilations, including collective works.<footnote><simpara>17 U.S.C. §103(a).</simpara></footnote> A compilation is &#8220;a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship.&#8221;<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> The preexisting materials or data incorporated in a compilation may or may not, on their own, be capable of being protected by copyright.<footnote><simpara>1-3 Nimmer §3.02.</simpara></footnote> For example, a program created by stringing together a set of basic functions (which in themselves are not protected by copyright) may receive copyright protection in the selection, coordination, and arrangement of such basic functions.</simpara>
<simpara>Those compilations that do, however, incorporate preexisting material capable of receiving copyright protection are known as collective works.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> The Act defines a collective work as &#8220;a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole.&#8221;<footnote><simpara>17 U.S.C.§ 101.</simpara></footnote> For example, a program that includes preexisting modules (which in themselves are protected by copyright) may receive copyright protection in the selection, coordination, and arrangement of the modules.</simpara>
<simpara>As with derivative works, for copyright protection to extend to a compilation or collective work, &#8220;the additional matter injected in a prior work, or the manner of rearranging or otherwise transforming a prior work, must constitute more than a minimal contribution.&#8221;<footnote><simpara>1-3 Nimmer § 3.03(A) (citing Feist Publications, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 348, 111 S. Ct. 1282, 113 L. Ed. 2d 358 (1991); Siegel v. Time Warner Inc., 496 F. Supp. 2d 1111, 1151 (C.D. Cal. 2007); Sherry Mfg. Co. v.  Towel King of Fla., Inc., 753 F.2d 1565 (11th Cir. 1985); Montgomery v. Noga, 168 F.3d 1282, 1290 n.12 (11th Cir. 1999); Moore Pub., Inc.  v. Big Sky Mktg., Inc., 756 F. Supp. 1371, 1374, 1378 (D. Idaho 1990)).</simpara></footnote> In the case of a collective work, the copyright in the prior work and copyright in the collective work as a whole are separate and distinct; the author of the prior work retains copyright ownership in her work, while ownership of the collective work, including contributions made by the author of the collective work, vests in the author of the collective work.<footnote><simpara>17 U.S.C.  §201(c).</simpara></footnote></simpara>
</section>
<section id="_joint_works_vs_derivative_works_vs_compilations">
<title>Joint works vs. derivative works vs. compilations</title>
<simpara>Joint works of authorship share similarities with derivative works and compilations and, but for the intention of the authors, could be seen as one and the same.<footnote><simpara>1-6 Nimmer §6.05.</simpara></footnote> Depending on the intent at the time of creation, one author&#8217;s recasting, transforming, or adapting of another author&#8217;s preexisting work may create either a derivative work or a joint work consisting of inseparable parts.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> Similarly, depending on the intent at the time of creation the assembling of the works of several different authors into a collective whole may create either a compilation or a joint work consisting of interdependent parts.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote>  Which case applies in each instance &#8220;lies in the intent of each contributing author at the time his contribution is written.&#8221;<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> If, at the time of creation, the author intends his contribution and those contributions of others &#8220;be merged into inseparable or interdependent parts of a unitary whole&#8221; then such a merger creates a joint work.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> On the other hand, if the intention to merge occurs only after creation of the work, then such a merger results in a derivative work or a compilation.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote></simpara>
</section>
</section>
<section id="sec_exclusiveusa">
<title>Exclusive rights</title>
<simpara>The right holder&#8217;s exclusive rights to do or to authorize are set out in Sec. 106 of the Act.<footnote><simpara>17 U.S.C. §106.</simpara></footnote> The author of software has the exclusive right to reproduce the copyrighted work, to prepare derivative works based on the copyrighted work, and to distribute copies of the copyrighted work to the public by sale or other transfer or ownership, or by rental, lease, or lending.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> The exclusive right to distribute only pertains to the original public distribution of a work and does not extend to a subsequent distribution by a party holding legal rights in a copy of the work.<footnote><simpara>17 U.S.C. §109(a).</simpara></footnote> However, a party receiving a copy under such subsequent distribution remains bound by any contractual limitations to which the original recipient agreed.<footnote><simpara>2-8 Nimmer §8.12.</simpara></footnote></simpara>
</section>
<section id="sec_exceptionsusa">
<title>Exceptions to exclusive rights</title>
<section id="_functionality_exception_to_copyright_protection">
<title>Functionality exception to copyright protection</title>
<simpara>When developing computer programs it is inevitable that some of the code will be functional in nature. As stated earlier, the Act awards copyright protection to creative expression. &#8220;Functional elements and elements taken from the public domain do not qualify for copyright protection.&#8221;<footnote><simpara>Computer Assoc., 982 F.2d at 714.</simpara></footnote>  Therefore, there is no striking similarity even between two identical works so as to warrant an inference of copying to the extent that, albeit copyrightable, functional considerations can account for the identity.<footnote><simpara><emphasis>See</emphasis>, 4-13 Nimmer §13.02(B).</simpara></footnote> What makes an element &#8220;functional?&#8221; Elements are functional if they are necessary to the program and do not exhibit any creativity. Aspects of a program&#8217;s structure which are dictated by the nature of other programs with which they were designed to interact are functional in nature and, thus, not protected by copyright.<footnote><simpara><emphasis>See</emphasis>, Computer Assoc., 982 F.2d at 715.</simpara></footnote></simpara>
<simpara>Functional elements may also be dictated by the nature of the program being developed. In <emphasis>Computer Associates</emphasis>, &#8220;the district court found that the overlap exhibited between the list of services required for both ADAPTER and OSCAR 3.5 was determined by the demands of the operating system and of the applications program to which it was to be linked through ADAPTER or OSCAR.&#8221;<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> These aspects of the program&#8217;s structure are therefore functional in nature and not copyrightable.</simpara>
<simpara>For example, graphical user interfaces [GUI&#8217;s] generated by computer programs are partly artistic and partly functional. They are a tool to facilitate communication between the user and the computer. GUIs do graphically what a character-based interface, which requires a user to type in alphanumeric commands, does manually.<footnote><simpara>Apple Computer, Inc v. Microsoft Corp., 35 F.3d 1435, 1445 (9th Cir.  1994).</simpara></footnote></simpara>
<simpara>In Lotus the court held that the Lotus menu command hierarchy is an uncopyrightable method of operation.<footnote><simpara><emphasis>See</emphasis>, Lotus Dev. Corp. v. Borland Int&#8217;l, 49 F.3d 807, 819 (1st Cir. 1995).</simpara></footnote></simpara>
<blockquote>
<attribution>
Id. at 815.
</attribution>
<simpara>The Lotus menu command hierarchy provides the means by which users control and operate Lotus 1-2-3. If users wish to copy material, for example, they use the Copy command. If users wish to print material, they use the Print command. Users must use the command terms to tell the computer what to do. Without the menu command hierarchy, users would not be able to access and control, or indeed make use of, Lotus 1-2-3&#8217;s functional capabilities.</simpara>
</blockquote>
<simpara>The menu command hierarchy in Lotus 1-2-3 is functional by nature of the program and therefore not copyrightable.<footnote><simpara><emphasis>See, Id.</emphasis> at 815.</simpara></footnote></simpara>
<simpara>Other areas to consider when determining whether an element is purely or primarily functional include:</simpara>
<orderedlist numeration="arabic">
<listitem>
<simpara>
hardware standards;
</simpara>
</listitem>
<listitem>
<simpara>
software standards;
</simpara>
</listitem>
<listitem>
<simpara>
computer manufacturer design standards;
</simpara>
</listitem>
<listitem>
<simpara>
target industry practices; and
</simpara>
</listitem>
<listitem>
<simpara>
computer industry programming practices.<footnote><simpara>4-13 Nimmer §13.03(F).</simpara></footnote>
</simpara>
</listitem>
</orderedlist>
<simpara>An extensive discussion on the functionality exception to copyright in software and its application may be found in an order of the Court in <emphasis>Oracle America, Inc. v. Google, Inc.</emphasis><footnote><simpara><emphasis>See,</emphasis> Order Re Copyrightability Of Certain Replicated Elements Of The Java Application Programming Interface (hereinafter <emphasis>Order</emphasis>) found at <ulink url="http://www.groklaw.net/pdf3/OraGoogle-1202.pdf">http://www.groklaw.net/pdf3/OraGoogle-1202.pdf</ulink>.</simpara></footnote></simpara>
</section>
<section id="_idea_expression_merger_exception_to_copyright_protection">
<title>Idea/Expression merger exception to copyright protection</title>
<simpara>Under the Act, in no case does copyright protection extend to any idea regardless of the form in which it is described, explained, illustrated, or embodied in such work.<footnote><simpara>17 U.S.C. §102(b).</simpara></footnote>  &#8220;It is a fundamental precept of copyright that only the expression of ideas, and not the ideas themselves, are copyrightable.&#8221;<footnote><simpara>1-2 Nimmer §2.02.</simpara></footnote> &#8220;Merely stating the rule, however, does not make any easier the task of drawing the line between where idea ends and expression begins.&#8221;<footnote><simpara>4-13 Nimmer §13.03(B)(2)(a).</simpara></footnote></simpara>
<blockquote>
<attribution>
Whelp Assoc.
<citetitle>Inc. v. Jaslow Dental Lab</citetitle>
</attribution>
<simpara>The line between idea and expression may be drawn with reference to the end sought to be achieved by the work in question. In other words, the purpose or function of a utilitarian work would be the work&#8217;s idea, and everything that is not necessary to that purpose or function would be part of the expression of the idea&#8230; Where there are various means of achieving the desired purpose, then the particular means chosen is not necessary to the purpose; hence, there is expression, not idea.</simpara>
</blockquote>
<simpara>The characteristics of computer software, a utilitarian work, make the determination of idea and expression more complicated. Competitive forces that exist in the software marketplace lead to the problem that multiple programmers may design identical or highly similar works.<footnote><simpara>Computer Assoc., 982 F.2d at 708.</simpara></footnote></simpara>
<blockquote>
<attribution>
Id.
</attribution>
<simpara>Efficiency is an industry-wide goal. Since, as we have already noted, there may be only a limited number of efficient implementations for any given program task, it is quite possible that multiple programmers, working independently, will design the identical method employed in the allegedly infringed work. Of course, if this is the case, there is no copyright infringement.</simpara>
</blockquote>
<simpara>The merger doctrine is as an exception to the idea-expression dichotomy which holds that, when there are so few ways of expressing an idea, not even the expression is protected by copyright.<footnote><simpara><emphasis>See,</emphasis> BUC Int&#8217;l Corp. v. Int&#8217;l Yacht Council Ltd., 489 F.3d 1129, 1143 (11th Cir. 2007).</simpara></footnote> When idea and expression merge such that a given idea is inseparably tied to a particular expression, rigorously protecting the expression would confer a monopoly over the idea itself, in contravention of the statutory command. To prevent such an occurrence, courts have invoked the merger doctrine.<footnote><simpara><emphasis>See</emphasis>, 4-13 Nimmer §13.03(B)(3).</simpara></footnote></simpara>
<simpara>In the realm of computer programs, merger issues may arise in unusual ways. Although, there may be many ways to implement a particular idea, efficiency concerns can make one or two choices so compelling, as to virtually eliminate any other form of expression.<footnote><simpara><emphasis>See</emphasis>, 4-13 Nimmer §13.03(F)(2).</simpara></footnote></simpara>
<blockquote>
<attribution>
Id.
</attribution>
<simpara>Computer searching and sorting algorithms provide good examples of this phenomenon. Any computer system that deals with significant quantities of data will spend much of its operating time engaged in sorting and searching through that data. Because the amount of time spent on sorting and searching operations can significantly influence a program&#8217;s operating speed, efficient methods of sorting are highly desirable. A great deal of computer science research has been devoted to developing methods of sorting or searching through data, and to analyzing the relative efficiency of various methods.  As a result of such research, it is now recognized that some methods of sorting or searching are significantly more efficient than others in handling particular types of data, even though any of numerous methods will work. In such cases, the merger doctrine should be applied to deny protection to those elements of a program dictated purely by efficiency concerns.</simpara>
</blockquote>
<simpara>While the merger doctrine and the functionality exception to copyright protection are similar, there is a slight difference which distinguishes the two. &#8220;Under the merger doctrine, when an idea can be expressed in only one fashion, that expression is not protected by copyright.&#8221;<footnote><simpara>4-13 Nimmer §13.03(F)(2).</simpara></footnote> Here the focus is on the limitations of the expression of an idea which results in the merger of that idea and its expression. In contrast, elements are functional if they are necessary to the program and do not exhibit any creativity.<footnote><simpara><emphasis>See,</emphasis> Computer Assoc., 982 F.2d at 715.</simpara></footnote>  In reference to the functionality exception, the focus is not on the limitations on expression of an idea resulting in merger of the two, but on aspects of a program&#8217;s structure which are dictated by the nature of other programs with which they were designed to interact.<footnote><simpara><emphasis>See</emphasis>, Computer Assoc., 982 F.2d at 715.</simpara></footnote></simpara>
<simpara>An extensive discussion on the idea/expression merger exception to copyright in software and its application may be found in an order of the Court in <emphasis>Oracle America, Inc. v. Google, Inc.</emphasis><footnote><simpara>Order <emphasis>supra</emphasis> Note XXX</simpara></footnote>.  One important aspect of this holding by the Court was that Java specifications constitute unprotectable ideas and that it is only an implementation of a specification that constitutes protected expression.</simpara>
</section>
<section id="_scènes_à_faire_in_software_exception_to_copyright_protection">
<title>Scènes à faire in software exception to copyright protection</title>
<simpara>The Act does not directly define the scènes à faire doctrine. Scènes à faire refers to aspects of a work that are indispensable or standard parts of the material to be copyrighted.<footnote><simpara><emphasis>See, Id.</emphasis>  at 710.</simpara></footnote> &#8220;The [scènes à faire] doctrine is often invoked to immunize from liability similarity of incidents or plot that necessarily follows from a common theme or setting.&#8221;<footnote><simpara>4-13 Nimmer §13.03(B)(4).</simpara></footnote> &#8220;Judge Leon Yankwich has called such incidents scènes à faire, i.e., scenes which must be done.&#8221;<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote></simpara>
<blockquote>
<attribution>
Id.
</attribution>
<simpara>As was remarked above concerning merger, this doctrine does not limit the subject matter of copyright; instead, it defines the contours of infringing conduct. Labeling certain stock elements as &#8220;scènes à faire&#8221; does not imply that they are uncopyrightable; it merely states that similarities between plaintiff&#8217;s and defendant&#8217;s works that are limited to hackneyed elements cannot furnish the basis for finding substantial similarity.</simpara>
</blockquote>
<simpara>In <emphasis>Durang</emphasis>, the court found that alleged similarities that follow obviously from the unprotected idea are therefore unprotected &#8220;scènes à faire.&#8221;<footnote><simpara><emphasis>See</emphasis>, John William See v. Christopher Durang and LA. Stage Co., 711 F.2d 141, 143 (9th Cir. 1983).</simpara></footnote> The <emphasis>Durang</emphasis> court held that the lower court properly applied the scènes à faire doctrine to hold unprotectable, forms of expression that were either stock scenes or scenes that flowed necessarily from common unprotectable ideas.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> The <emphasis>Durang</emphasis> court went on to explain that common in that context means common to the works at issue, not necessarily commonly found in other artistic works.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote></simpara>
<simpara>Further, under the doctrine of scènes à faire, elements of an original work are not protected if the &#8220;common idea is only capable of expression in more or less stereotyped form.&#8221;<footnote><simpara>Mist-On Sys. v. Gilley&#8217;s European Tan Spa, 303 F. Supp. 2d 974, 978 (W.D.  Wis. 2002).</simpara></footnote> &#8220;Beyond mere plot incidents applicable to works of fiction, the scènes à faire doctrine can be invoked throughout other copyright contexts as well; from guidebooks to infomercials to Frequently Asked Questions web pages and beyond.&#8221;<footnote><simpara>4-13 Nimmer §13.03(B)(4).</simpara></footnote></simpara>
<simpara>In <emphasis>Gilley&#8217;s European Tan Spa</emphasis>, &#8220;[the] plaintiff contended that defendants infringed plaintiff&#8217;s exclusive rights under the Copyright Act by preparing and displaying on their web page an unauthorized Frequently Asked Questions page that mirrors the Frequently Asked Questions page found on plaintiff&#8217;s web page.&#8221;<footnote><simpara>Mist-On Sys., 303 F. Supp. 2d at 976 (W.D. Wis. 2002)</simpara></footnote>.</simpara>
<blockquote>
<attribution>
Id. at 978.
</attribution>
<simpara>The Gilley&#8217;s court held a business cannot copyright a Frequently Asked Questions page as such or copyright words or phrases commonly used to assemble any given Frequently Asked Questions page. The format of a Frequently Asked Questions page is a common idea in our society; the elements of a Frequently Asked Questions page (a list of questions beginning with common words) are stereotypical. Some additional similarity beyond generic formatting is necessary to establish infringe-ment.</simpara>
</blockquote>
<simpara>Applied to computer programs, the merger and scènes à faire doctrines suggest that if a limited number of options exist to achieve a given function efficiently, interoperate with another application, or run in a given environment, copyright will not permit exclusive control over those program elements.<footnote><simpara>Computer Assocs., 982 F.2d at 709-10.</simpara></footnote> Scènes à faire is distinguishable from the merger doctrine because, the merger doctrine holds that when there are so few ways of expressing an idea, not even the expression is protected by copyright.<footnote><simpara>BUC Int&#8217;l Corp. v. Int&#8217;l Yacht Council Ltd., 489 F.3d 1129, 1143 (11th Cir. 2007).</simpara></footnote> The idea and expression are in essence, fused. In contrast, scènes à faire relates to alleged similarities that follow obviously from the unprotected idea.<footnote><simpara><emphasis>See</emphasis> v. Durang, 711 F.2d at 143.</simpara></footnote> The focus in scènes à faire is not on the merged idea and expression or the limited number of ways to express the idea, but on the similarities between expression in question which are a natural result of the idea being expressed.</simpara>
<simpara>Moreover, scènes à faire is also distinguishable from the functionality exception to copyright protection. While scènes à faire is expression that relates to stock scenes or elements which are necessary to the idea such as frequently asked questions or readme files, functionality relates to aspects of a program&#8217;s structure which are dictated by the nature of other programs with which they were designed to interact,<footnote><simpara>Computer Assoc., 982 F.2d at 715.</simpara></footnote>  such as hardware or software standards. As software development languages become more and more sophisticated in the ready-made tools they provide developers and as more and more developers, especially open source developers, reuse standard or stock bits of code to carry out standard functions, we can expect to see the scènes à faire doctrine applied with greater regularity in software to deny copyright protection.</simpara>
</section>
<section id="_public_domain_exception_to_copyright_protection">
<title>Public domain exception to copyright protection</title>
<simpara>Works eligible for copyright protection may nonetheless enter the public domain, i.e., no longer enjoy that copyright protection. For example, a work whose copyright term has expired is obviously not protected. Similarly, a work may have entered the public domain by reason of the failure to satisfy certain statutory formalities of the Act as it existed prior to 1978. In addition, an author may choose to lift the protections of copyright and voluntary place the work into the public domain.<footnote><simpara><emphasis>See</emphasis>, 1-2 Nimmer §2.03(G).</simpara></footnote>  &#8220;Moreover, copyright protection under the Act is not available for any work of the United States Government, but the United States Government is not precluded from receiving and holding copyrights transferred to it by assignment, bequest, or otherwise.&#8221;<footnote><simpara>17 U.S.C §105.</simpara></footnote></simpara>
<simpara>What is the public domain? &#8220;A work of authorship is in the public domain if it is no longer under copyright protection, it failed to meet the requirements for copyright protection, or the holder of the copyright disclaimed copyright in the work.&#8221;<footnote><simpara><ulink url="http://copyright.gov/help/faq/faq-definitions.html">http://copyright.gov/help/faq/faq-definitions.html</ulink>.</simpara></footnote>  Works in the public domain are free for anyone to use without permission from the former owners(s) of the copyright.<footnote><simpara><emphasis>See, Id.</emphasis></simpara></footnote> Material found in the public domain is free for the taking and cannot be appropriated by a single author even though it is included in a copyrighted work.<footnote><simpara><emphasis>See</emphasis>, Computer Assocs., 982 F.2d at 710.</simpara></footnote></simpara>
<blockquote>
<attribution>
4-13 Nimmer §13.03(F)(4).
</attribution>
<simpara>An enormous amount of public domain software exists in the computer industry, perhaps to a much greater extent than is true of other fields. Nationwide computer &#8220;bulletin boards&#8221; permit users to share and distribute programs. In addition, computer programming texts may contain examples of actual code that programmers are encouraged to copy. Programmers often will build existing public domain software into their works. The courts thus must be careful to limit protection only to those elements of the program that represent the author&#8217;s original work.</simpara>
</blockquote>
<simpara>Copyright protection is automatic and vested in the author the moment it is created and fixed in a tangible form.<footnote><simpara><ulink url="http://www.copyright.gov/help/faq/faq-general.html">http://www.copyright.gov/help/faq/faq-general.html</ulink>.</simpara></footnote>  Voluntarily placing a copyrighted work in the public domain requires some manifest expression of the author&#8217;s intent.<footnote><simpara>4-13 Nimmer §13.03(F)(4).</simpara></footnote> Consequently, anyone considering reusing code purportedly in the public domain should be cautious about assuming that code to be in the public domain without some express statement from the copyright holder declaring the code to be in the public domain. An invitation to use with nothing more may be sufficient, but combined with a requirement of attribution suggests the author is merely granting permission to use while retaining the copyright and its various protections. A more definite state, such as &#8220;as the author of this work I disclaim the copyright in the work and declare the work to be in the public domain&#8221; would leave little doubt as to the copyright holder&#8217;s intent. The Creative Commons Copyright-Only Dedication statement gives some indication of the complexity of committing a work to the public domain.<footnote><simpara><ulink url="http://creativecommons.org/licenses/publicdomain/">http://creativecommons.org/licenses/publicdomain/</ulink>.</simpara></footnote></simpara>
</section>
<section id="_facts_in_software_exception_to_copyright_protection">
<title>Facts in software exception to copyright protection</title>
<blockquote>
<attribution>
Feist Publ'ns
<citetitle>Inc. v. Rural Tel. Serv. Co.</citetitle>
</attribution>
<simpara>Facts, whether alone or as part of a compilation, are not original and therefore may not be copyrighted. A factual compilation is eligible for copyright if it features an original selection or arrangement of facts, but the copyright is limited to the particular selection or arrangement. In no event may copyright extend to the facts themselves.</simpara>
</blockquote>
<simpara>&#8220;In no case does copyright protection for an original work of authorship extend to any &#8230; discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.&#8221;<footnote><simpara>17 U.S.C. §102(b).</simpara></footnote> Nimmer explains that the discoverer merely finds and records.</simpara>
<blockquote>
<attribution>
1-2 Nimmer §2.03(E).
</attribution>
<simpara>He may not claim that the facts are original with him, although there may be originality and hence, authorship in the manner of reporting, i.e., the expression, of the facts. As copyright may only be conferred upon authors, it follows that quite apart from their status as ideas, discoveries as facts per se may not be the subject of copyright.</simpara>
</blockquote>
<blockquote>
<attribution>
1-3 Nimmer §3.04(2)(a).
</attribution>
<simpara>(The Court in <emphasis>Fiest</emphasis>)<footnote><simpara>Feist, 499 U.S. at 350 (1991).</simpara></footnote>  noted] the tension between two well-established copyright propositions, &#8230; facts are not copyrightable, whereas compilations of facts generally are. As the tool for untangling those disparate strands, the Court relied on the bedrock principle of copyright subsistence&#8212;that only original works of authorship qualify for protection. Given that facts, by themselves, are never copyrightable, the Court reasoned that the element of originality that renders a factual compilation protectable must lie in selection, coordination, or arrangement of facts, with the scope of protection concomitantly limited to that original selection, coordination, or arrangement. That formulation, it should be noted, corresponds to the scope of copyright generally for derivative or collective works.</simpara>
</blockquote>
<simpara>How does this relate to computer software? In <emphasis>WIREdata</emphasis> an owner of a copyright attempted to hide data in its copyrighted program.<footnote><simpara>Assessment Techs. of WI, LLC v. WIREdata, Inc., 350 F.3d 640 (7th Cir. 2003).</simpara></footnote> Specifically, the copyright owner attempted to use copyright law to &#8220;block access to data that not only are neither copyrightable nor copyrighted, but were not created or obtained by the copyright owner.&#8221;<footnote><simpara>1-3 Nimmer §3.04(B)(3)(a).</simpara></footnote></simpara>
<blockquote>
<attribution>
Id.
</attribution>
<simpara>The information at issue in [<emphasis>WIREdata</emphasis>] was collected and then was slotted into plaintiff&#8217;s database. Defendant did not want that database&#8217;s organized structure; it only wanted the raw data. That last consideration proved decisive in defeating plaintiff&#8217;s copyright infringement claim: A work that merely copies uncopyrighted material such as facts is wholly unoriginal and the making of such a work is therefore not an infringement of copyright.</simpara>
</blockquote>
<simpara>Within the framework of computer software development it will not be unusual to find lines of code that merely make a factual statement. A reference in a line of code to another place in the program, a table showing equivalences, or a target name may all be merely factual statements within the context of the software and, thus, not eligible for copyright protection.</simpara>
</section>
<section id="_fair_use">
<title>Fair use</title>
<simpara>Originally developed by the courts through case law, certain uses or reproductions of a work protected by copyright are considered to be fair, and thus, not an infringement of the owner&#8217;s exclusive rights granted by copyright law.<footnote><simpara>17 U.S.C. § 107.</simpara></footnote> In other words, fair use is a defense to copyright infringement.</simpara>
<simpara>Section 107 of the Act contains a list of the various purposes for which the reproduction of a particular work may be considered fair, such as criticism, comment, news reporting, teaching, scholarship, and research.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote> In addition, the Act sets out four factors to be considered by a court determining whether or not a particular use is fair:</simpara>
<itemizedlist>
<listitem>
<simpara>
the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;
</simpara>
</listitem>
<listitem>
<simpara>
the nature of the copyrighted work;
</simpara>
</listitem>
<listitem>
<simpara>
the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and
</simpara>
</listitem>
<listitem>
<simpara>
the effect of the use upon the potential market for or value of the copyrighted work.<footnote><simpara><emphasis>Id.</emphasis></simpara></footnote>
</simpara>
</listitem>
</itemizedlist>
<simpara>From a practical perspective, it is important to recognize that the fair use doctrine is malleable&#8201;&#8212;&#8201;the court has wide discretion in its application of the four factors to the particular facts of the case before it. There are no hard and fast rules in fair use and the difference between an infringing use and a fair use may be murky and not easy to delineate. Using a work protected by copyright without permission poses a substantial amount of risk. But for fair use, the unauthorized use of a work protected by copyright is an infringement.  Unless the use falls within one of the permissible statutory uses, there is no way to conclusively know whether the use is fair without costly and expensive litigation.</simpara>
</section>
<section id="_statutory_limitations_on_copyright_in_software">
<title>Statutory limitations on copyright in software</title>
<simpara>Sec. 117 of the Copyright Act imposes statutory limitations on the rights of authors or holders of copyright in computer programs by assuring the right of a lawful owner of a copy of the software to load that software onto a computing device and to make an archival copy of that software.<footnote><simpara>17 U.S. Code §117(a).</simpara></footnote> This right to use or make a temporary copy also extends to the so-called &#8220;maintenance or repair exception,&#8221; i.e., it is not an infringement to activate a machine for maintenance and repair purposes and incidental to such activation run the software installed on the machine.<footnote><simpara>17 U.S. Code §117(c).</simpara></footnote></simpara>
</section>
</section>
<section id="sec_moralusa">
<title>Moral rights</title>
<simpara>Unlike the copyright laws of many European nations, the United States does not generally recognize moral rights in copyrighted works. The exception lies with works of visual arts, such as posters, maps, globes, motion pictures, electronic publications, and applied art.<footnote><simpara>Visual Artists Rights Act of 1990, 17 U.S. Code §106A.</simpara></footnote> As a consequence, the ability to assert moral rights under copyright in computer programs would be rare.</simpara>
</section>
<section id="sec_protectionusa2">
<title>Term of protection</title>
<simpara>In the United States the duration of copyright in computer programs is dependent on the nature of the authorship. Where the computer program was written by a single author on or after January 1, 1978, the copyright expires 70 years following the death of the author.<footnote><simpara>17 U.S. Code §302(a).</simpara></footnote> If a work was created by joint authors, the 70-year period is calculated from the date of the death of the last surviving author.<footnote><simpara>17 U.S. Code §302(b).</simpara></footnote>  Where the computer program was written anonymously, under a pseudonym, or as a work made for hire, the copyright endures for a term of 95 years from the year of its first publication, or a term of 120 years from the year of its creation, whichever expires first. Should the author or his/her legal successor record his/her identity with the U.S. Copyright Office prior to the date of expiration, the copyright term is calculated under the general rules for known authors.<footnote><simpara>17 U.S. Code §302(c).</simpara></footnote> As to derivative works, compilations or collective works, there is no special rule as both the author of the preexisting works (if any) and the author of the derivative work, compilation or collective work hold independent copyrights. Thus, each protection term is calculated separately under the general rule.</simpara>
</section>
<section id="sec_assignmentusa">
<title>Copyright assignment</title>
<simpara>Under U.S. copyright law the ownership of a copyright may be transferred in whole or in part by any means of conveyance or by operation of law, and may be bequeathed by will or pass as personal property by the applicable laws of intestate succession.<footnote><simpara>17 U.S. Code §201(d)(1).</simpara></footnote> Rights in copyright are considered bundled and may be unbundled for purposes of license or transfer, i.e., they may be licensed or transferred outright either individually or in their entirety.<footnote><simpara>17 U.S. Code §201(d)(2).</simpara></footnote></simpara>
<simpara>To be effective, any transfer of rights under copyright, whether by license or complete assignment, must be in writing and signed by the holder of the rights in the copyright or that holder&#8217;s authorized agent.<footnote><simpara>17 U.S. Code §204(a).</simpara></footnote> Such transfers may, but are not required to be recorded with the U.S. Copyright Office; however, a failure to record an exclusive grant may result in a preemption of such grant by a subsequent grant if such subsequent grant is the first to be recorded, provided the exclusive grant is not recorded within one month of its execution (two months if executed outside the U.S.).<footnote><simpara>17 U.S. Code §205(d).</simpara></footnote> Nonexclusive licenses embodied in a writing are not subject to such preemption.<footnote><simpara>17 U.S. Code §205(e).</simpara></footnote></simpara>
<simpara>A unique provision of U.S. copyright law pertaining to licenses and assignments is that all such licenses and assignments, except those made pursuant to a work for hire, are subject to revocation by the author or the author&#8217;s estate under certain conditions.<footnote><simpara>17 U.S. Code §203(a)(1-2).</simpara></footnote> Such revocation may occur only during a period commencing with the end of the 35th year following the date of the grant (or if the grant includes a right of publication, the end of the 35th year following such publication) and ending at the end of the 40th year following the date of the grant.<footnote><simpara>17 U.S. Code §203(a)(3).</simpara></footnote> To effect the revocation, the empowered party(ies) must serve notice of termination on the grantee under the license or assignment.<footnote><simpara>17 U.S. Code §203(a)(4).</simpara></footnote> An important exception to such termination is that rights in any derivative works prepared under such grant and existing prior to the date of termination shall survive such termination, but only in the form in which the derivative work existed at the time of such termination.<footnote><simpara>17 U.S. Code §203(b)(1).</simpara></footnote></simpara>
</section>
<section id="sec_enforcementusa">
<title>Enforcement</title>
<section id="_infringement">
<title>Infringement</title>
<simpara>Enforcement of copyright in software where infringement occurs is no different than for other matter subject to copyright protection.  Infringement may be found where any of the exclusive rights of the copyright holder have been undertaken without authorization.<footnote><simpara>17 U.S. Code §501(a).</simpara></footnote> In order to bring a civil action for infringement the copyright holder must record the copyright with the U.S. Copyright Office.<footnote><simpara>17 U.S. Code §411.</simpara></footnote> Registration serves the dual purpose of establishing the earliest date for liability for statutory damages and attorney&#8217;s fees.<footnote><simpara>17 U.S. Code §412.</simpara></footnote></simpara>
<simpara>Only the exclusive holder of a right or all of the rights (whether the original author, an assignee, or licensee) in copyright has standing to bring a civil action for infringement.<footnote><simpara>17 U.S. Code §501(b).</simpara></footnote> The exclusive holder of less than all of the rights may only claim infringement of those rights held; it is not necessary for the exclusive holder of a right to join the primary copyright holder.<footnote><simpara><emphasis>Id.</emphasis>; Eden Toys, Inc. v. Florelee Undergarment Co., 697 F.2d 27 (2d Cir. 1982); Random House, Inc. v.  Rosetta Books LLC, 150 F. Supp. 2d 613, 617 (S.D.N.Y. 2001), aff&#8217;d per curiam, 283 F.3d 490 (2d Cir. 2002)</simpara></footnote> Nonexclusive licenses have no right to bring an action for infringement.<footnote><simpara>Eden Toys, 697 F.2d at 32 (1982).</simpara></footnote></simpara>
<simpara>Remedies available to a successful complainant may include injunctive relief, impoundment and disposition of the infringing articles, statutory damages or actual damages and lost profits, and costs of court and attorney&#8217;s fees.<footnote><simpara>17 U.S. Code §§502-505.</simpara></footnote></simpara>
<simpara>Jurisdiction and venue in copyright cases only lies with the federal courts.<footnote><simpara>28 U.S. Code §1338.</simpara></footnote> This will be true even when breach of contract claims are asserted so long as at least one claim lies solely in copyright and such copyright claim is the primary basis of the suit.<footnote><simpara>Wooster v. Crane &amp; Co., 147 F. 15 (8th Cir. 1906).</simpara></footnote></simpara>
</section>
<section id="_breach_of_contract">
<title>Breach of contract</title>
<simpara>Apart from the right to bring an action for infringement, licensor&#8217;s of software may also bring an action for breach of contract where the subject matter of the breach does not relate to rights granted under copyright. As examples, the failure to pay license fees in a timely manner, royalty rates, and a breach of warranty all constitute contract claims. Unlike an action for copyright infringement, in a breach of contract action only money damages are generally available and not injunctive relief. A general exception to this rule would be in an action for specific performance under the contract. Most importantly, unlike copyright infringement where injunctive relief is a matter of right, injunctive relief will only be granted in breach of contract actions where such breach would result in irreparable harm that could not be adequately remedied by money damages.</simpara>
</section>
</section>
<section id="sec_patentusa">
<title>Patent protection of software</title>
<simpara>Unlike copyright, patent protection of software is not automatic, and such protection is largely limited to the jurisdiction issuing the patent. Whether inventions contained in software constitute patentable subject matter has been the subject of a great deal of debate and evolving law in the U.S. Prior to the 1980&#8217;s it was generally believed that one could not obtain a patent on inventions embodied in software, as such software consisted primarily of algorithms and, by law, algorithms were deemed unpatentable subject matter. This view first changed in 1981 in the <emphasis>Diamond v. Diehr</emphasis> case when the U.S. Supreme Court held that the use of an algorithm in software does not preclude it as patentable subject matter so long as the claimed invention related solely to the use of the software to solve a specific technological problem and did not preclude all other uses of the algorithm.<footnote><simpara>Diamond v. Diehr, 450 U.S. 175 (1981).</simpara></footnote></simpara>
<simpara>The interpretations of patent eligibility of software inventions continue to evolve. The U.S. Supreme Court in the case of <emphasis>In re Bilski</emphasis><footnote><simpara>In re Bilski, 130 S. Ct. 3218 (2010).</simpara></footnote> held that the machine or transformation test previously adopted by the U.S.  Court of Appeals for the Federal Circuit, i.e., &#8220;(a) claimed process is surely patent-eligible under § 101 if: (1) it is tied to a particular machine or apparatus, or (2) it transforms a particular article into a different state or thing,&#8221; constituted a test, although not the sole test, of whether a process is patent eligible.<footnote><simpara>In re Bilski, 130 S. Ct. at 3226 (2010).</simpara></footnote> In any case, inventions embodied in software remain patent eligible in the U.S., but the scope of that patent protection appears to be narrowing.</simpara>
<simpara>A scope of a patent is defined by the claims asserted in the patent.  In patents related to software such claims generally define the broad outline of the invention in terms of a process. Thus, the claims are not limited to a particular embodiment of that process (or, like copyright, to a specific set of written instructions) but may apply to an unlimited number of embodiments so long as each embodiment incorporates each element of one of the claims asserted in the patent.  As a consequence, patents related to software may be infringed by numerous computer programs, and any computer program may infringe the claims of numerous patents.</simpara>
<section id="_exclusive_rights">
<title>Exclusive rights</title>
<simpara>A patent holder in the U.S. has the exclusive right to make, have made, use, sell, or import any product made by means of a claimed process or product embodying the claimed invention.<footnote><simpara>35 U.S.C. §271(a)&amp;(g).</simpara></footnote> As with copyright, these rights may be assigned or licensed to another either in whole or in part.</simpara>
</section>
<section id="_exhaustion_and_implied_licenses">
<title>Exhaustion and implied licenses</title>
<simpara>Upon the unrestricted sale (as contrasted with the license) of a patented invention all patent rights in the invention are exhausted, i.e., the purchaser has the right to do anything with the purchased invention without fear of a claim of infringement. Related to the doctrine of exhaustion are implied licenses. When a patent holder incorporates the patented invention in a product and sells the product without an express license to the patent, courts will generally imply the grant of license since the patent holder essentially invites infringement. There is a line of cases in the U.S. that interprets the boundaries of such exhaustion and implied licenses:</simpara>
<itemizedlist>
<listitem>
<simpara>
<emphasis>Adams v. Burke</emphasis><footnote><simpara>Adams v. Burke, 84 U.S. 453 (1873).</simpara></footnote> &#8201;&#8212;&#8201;claims that are directly infringed by the product are exhausted at the time of sale.
</simpara>
</listitem>
<listitem>
<simpara>
<emphasis>Univis Lens</emphasis><footnote><simpara>United States v. Univis lens, 316 U.S.  241 (1942).</simpara></footnote>&#8201;&#8212;&#8201;implied license in claims necessary to finish an incomplete product.
</simpara>
</listitem>
<listitem>
<simpara>
<emphasis>Intel v. ULSI</emphasis><footnote><simpara>Intel Corp. v. ULSI System Technology, 995 F.2d 1566 (Fed. Cir. 1993).</simpara></footnote>&#8201;&#8212;&#8201;implied license accompanies the sale of infringing goods by a licensed manufacturer.
</simpara>
</listitem>
<listitem>
<simpara>
<emphasis>Cyrix v. Intel</emphasis><footnote><simpara>Cyrix Corp. v. Intel Corp., 77 F.3d 1381 (Fed. Cir. 1996).</simpara></footnote>&#8201;&#8212;&#8201;implied license in claims necessary to make a complete product commercially viable (use for intended purpose).
</simpara>
</listitem>
</itemizedlist>
<simpara>In addition to these cases specifically related to patent claims, licenses may be implied by courts for a variety of other legal and equitable reasons. For example, the conduct of the two parties may be construed as establishing a license. Also, equitable estoppel may be found where a party knowingly infringes and the patent holder, knowing of the infringement and objecting to such infringement, takes no action to halt the infringement, misleading the infringer into believing the patent holder will not act. Finally, a court may impose legal estoppel on a patent holder who has licensed or assigned a right, received consideration, and then sought to derogate from the right granted.</simpara>
</section>
<section id="_term_of_protection">
<title>Term of protection</title>
<simpara>Patent protection in the U.S. is granted for a term of 20 years measured from the date of the filing of the patent application for all patents issued on or after June 9, 1995.<footnote><simpara>35 U.S.C.  §154.(a)(2).</simpara></footnote> For patents issued prior to that date the term is the longer of 20 years from the date of filing or 17 years from the date of issue; this transition term phasing out on June 9, 2012.</simpara>
<simpara>Effective March 13, 2013, the U.S. joined most other national patent bodies in granting patent protection to the first party to file.<footnote><simpara>America Invents Act, Public Law 112-29 found at <ulink url="http://www.gpo.gov/fdsys/pkg/PLAW-112publ29/html/PLAW-112publ29.htm">http://www.gpo.gov/fdsys/pkg/PLAW-112publ29/html/PLAW-112publ29.htm</ulink>.</simpara></footnote></simpara>
</section>
<section id="_extraterritorial_reach">
<title>Extraterritorial reach</title>
<simpara>Sec. 271(f) of the Patent Act<footnote><simpara>35 U.S.C. §271(f)(1).</simpara></footnote>  extends infringement liability to any party who &#8220;without authority supplies or causes to be supplied in or from the United States all or a substantial portion of the components of a patented invention, where such components are uncombined in whole or in part, in such manner as to actively induce the combination of such components outside of the United States in a manner that would infringe the patent if such combination occurred within the United States.&#8221; This provision had been read to imply that the making outside the U.S. of copies from of an infringing gold master provided by a U.S. software developer would constitute additional infringing acts increasing the liability of the U.S. developer. In the case of <emphasis>AT&amp;T v.  Microsoft</emphasis><footnote><simpara>AT&amp;T v. Microsoft, 550 U.S. 437 (2007).</simpara></footnote>  the Supreme Court held that so long as the copies were made outside the U.S. from a gold master provided from the U.S. no liability accrued where the infringing act arises from the actual loading of the software onto a computer or the operation of the software on that computer.</simpara>
</section>
<section id="_infringement_2">
<title>Infringement</title>
<simpara>Liability for patent infringement arises when a party &#8220;without authority makes, uses, offers to sell, or sells any patented invention, within the United States or imports into the United States any patented invention during the term of the patent therefor, infringes the patent.&#8221;<footnote><simpara>35 U.S.C. §271(a).</simpara></footnote> The Patent Act also recognizes liability for inducing infringement.<footnote><simpara>35 U.S.C. §271(b).</simpara></footnote></simpara>
<simpara>A patent that is asserted in an infringement action is presumed to be valid,<footnote><simpara>35 U.S.C. §282.</simpara></footnote> and at present such validity may only be overcome by clear and convincing evidence of invalidity. This clear and convincing evidence standard is higher than the preponderance of the evidence standard used by patent examiners at the time of examination even if the evidence supporting invalidity was not before the examiner at the time of examination.</simpara>
<simpara>Remedies for patent infringement include injunctive relief, monetary damages in the form of a reasonable royalty, and attorney&#8217;s fees and costs of court.<footnote><simpara>35 U.S.C. §§283-285.</simpara></footnote> Where infringement is found to be willful the court may award treble damages.<footnote><simpara>35 U.S.C. §284.</simpara></footnote> Damages for patent infringement only begin to accrue when a party has been placed on notice of their infringement. While such notice may be provided by marking the goods for patents, such marking rarely occurs with respect to software.  Consequently, notice of infringement of patents related to software usually only arises upon the giving of written notice to the infringer.<footnote><simpara>35 U.S.C. §287.</simpara></footnote></simpara>
</section>
</section>
<section id="sec_otherusa">
<title>Other matters of law</title>
<section id="_representations_warranties_and_disclaimers">
<title>Representations, warranties and disclaimers</title>
<simpara>Although there is a legal distinction between a representation (a fact that is true at the time of the making of an agreement) and a warranty (a fact that is true at the time of the making of an agreement and throughout the term of the agreement unless otherwise limited), U.S.  courts rarely draw such a distinction except in determining the remedy (revocation for a breach of a representation versus money damages for breach of a warranty). A representation or warranty constitutes an assumption of risk on the part of the party making the representation or warranty. As such, most such representations and warranties must be expressly stated within the license agreement. However, some warranties may be implied. Those may include an implied warranty of title (i.e., the licensor holds good title to the copyright or patent being license), of non-infringement (i.e., the licensing of the copyright or patent will not constitute an infringing act on the part of the licensee with respect to a third party&#8217;s copyright or patent), of merchantability (i.e., the goods must reasonably conform to an ordinary buyer&#8217;s expectations) and of fitness for a particular purpose (i.e., the goods are held out by the seller to address a specific purpose). Most licensors will include a disclaimer of any and all such implied warranties in order to limit their exposure to only those express warranties to which they have agreed, and such disclaimers are generally held valid under principles of contract law. You will often see such disclaimers stated in all capital letters or bold print; this is commonly done to conform to the safe harbor provisions of laws pertaining to warranties, including the Uniform Commercial Code and the Magnuson-Moss Warranty Act.<footnote><simpara>Magnuson-Moss, 15 U.S.C.  §2301 <emphasis>et seq.</emphasis>.</simpara></footnote></simpara>
</section>
<section id="_liability_and_limitation">
<title>Liability and limitation</title>
<simpara>Under principles of contract law parties may agree to limit the scope of liability that may be imposed on a party under a license agreement, and such limitations are generally held to be valid.</simpara>
</section>
<section id="_export_control">
<title>Export control</title>
<simpara>Although there are numerous other laws that are applicable to the licensing of software, we only make mention of one here&#8201;&#8212;&#8201;export control. U.S. law prohibits the exporting of software incorporating cryptographic code except under a license issued by the Bureau of Industry and Security.<footnote><simpara>15 Code of Federal Regulations §742.15.</simpara></footnote> Obligations and liability under the statute extend beyond the original distributor to any downstream party that redistributes the software. As a consequence, most original distributors include in their license a notice of such obligations and liability.</simpara>
</section>
</section>
</section>
<section id="sec_analysisusa">
<title>Analysis of FOSS under United States law</title>
<simpara>Rights in FOSS under copyright, patent, and trademark law and the enforcement of such rights does not differ from other forms of licensing. The principle question to be addressed in each instance, particularly with respect to the exercise of rights granted under the FOSS license is whether any of such rights are subject to conditions.  Absent such conditions applicable to the exercise of the right in question, such FOSS licenses will be interpreted exclusively under principles of contract law, and as a consequence, injunctive relief (the most valuable tool available to a FOSS licensor) is likely to be unavailable. Consequently, when considering the selection and enforcement of a FOSS license, the licensor will want to give due consideration as to whether a court would likely find a condition limiting the exercise of such right (e.g., the obligations imposed by the GNU General Public License (GPL) on any party distributing code licensed under the GPL) or no such condition (e.g., arguably the Berkeley Software Distribution (BSD) and MIT licenses impose no such conditions).</simpara>
</section>
<section id="sec_casesusa">
<title>FOSS cases in the United States</title>
<simpara>There have been few cases in the U.S. that have addressed the enforcement of free and open source licenses. Many of the so-called free and open source cases have dealt primarily with trademark issues.</simpara>
<section id="sec_jacobsenusa">
<title>Jacobsen v. Katzer</title>
<simpara><emphasis>Jacobsen v. Katzer</emphasis><footnote><simpara>Jacobsen v. Katzer, 535 F.3d 1373 (Fed.  Cir. 2008).</simpara></footnote> is undoubtedly the most important of the cases addressing free and open source software in the U.S. At issue was the provision of the Artistic license that requires licensees to include both copyright notices and a tracking of modifications in derivative works.</simpara>
<simpara>Citing to Nimmer in support of enforcement of the license the court stated: &#8220;An express (or possibly an implied) condition that a licensee must affix a proper copyright notice to all copies of the work that he causes to be published will render a publication devoid of such notice without authority from the licensor and therefore, an infringing act.&#8221;<footnote><simpara>3-10 Nimmer on Copyright §10.15 .</simpara></footnote></simpara>
<simpara>In broad language that would support most, if not all, open source licenses the court stated:</simpara>
<blockquote>
<attribution>
Jacobsen
<citetitle>535 F.3d at 1381 (2008).</citetitle>
</attribution>
<simpara>Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material&#8230; Copyright licenses are designed to support the right to exclude; money damages alone do not support or enforce that right. The choice to exact consideration in the form of compliance with the open source requirements of disclosure and explanation of changes, rather than as a dollar-denominated fee, is entitled to no less legal recognition. Indeed, because a calculation of damages is inherently speculative, these types of license restrictions might well be rendered meaningless absent the ability to enforce through injunctive relief.</simpara>
</blockquote>
<simpara>Although the Jacobsen case later settled, this Federal Circuit ruling clearly established the enforceability of free and open source licenses containing at least one condition limiting a licensee&#8217;s right to exercise one or more rights granted under a copyright license.</simpara>
</section>
<section id="sec_wallaceusa">
<title>Wallace v. International Business Machines Corp.</title>
<simpara>Although a bit of an odd case and one not directly related to the enforcement of a free and open source license, <emphasis>Wallace v.  IBM</emphasis><footnote><simpara>Wallace v. International Business Machines Corp., 467 F.3d 1104 (CA 7 2006).</simpara></footnote> is worth mentioning because of the antitrust (anti-competition) issue raised by the plaintiff, Mr. Wallace, i.e., that the distribution of free and open source software at no cost constitutes illegal price fixing within the terms of U.S. antitrust law. The court found no such price fixing or restraint and found the GPL to be &#8220;a cooperative agreement that facilitates production of new derivative works, and agreements that yield new products that would not arise through unilateral action are lawful.&#8221;<footnote><simpara>Wallace, 467 F.3d at 1107 (2006).</simpara></footnote></simpara>
</section>
<section id="_recommended_literature">
<title>Recommended literature</title>
<section id="_recommended_literature_in_the_united_states">
<title>Recommended literature in the United States</title>
<itemizedlist>
<listitem>
<simpara>
O. Johnny, M. Miller and M. H. Webbink: Copyright in Open Source Software&#8201;&#8212;&#8201;Understanding the Boundaries
</simpara>
<simpara><ulink url="http://www.ifosslr.org/ifosslr/article/view/30">http://www.ifosslr.org/ifosslr/article/view/30</ulink></simpara>
</listitem>
<listitem>
<simpara>
M. H. Webbink: Packaging Open Source
</simpara>
<simpara><ulink url="http://www.ifosslr.org/ifosslr/article/view/26">http://www.ifosslr.org/ifosslr/article/view/26</ulink></simpara>
</listitem>
<listitem>
<simpara>
H. Anderson and T. Dare: Passport Without a Visa: Open Source Software Licensing and Trademarks
</simpara>
<simpara><ulink url="http://www.ifosslr.org/ifosslr/article/view/11">http://www.ifosslr.org/ifosslr/article/view/11</ulink></simpara>
</listitem>
<listitem>
<simpara>
K. Copenhaver: Open Source Policies and Processes for In-Bound Software,
</simpara>
<simpara><ulink url="http://www.ifosslr.org/ifosslr/article/view/27">http://www.ifosslr.org/ifosslr/article/view/27</ulink></simpara>
</listitem>
<listitem>
<simpara>
L. Rosen: Bad Facts Make Good Law: The Jacobsen Case and Open Source,
</simpara>
<simpara><ulink url="http://www.ifosslr.org/ifosslr/article/view/5">http://www.ifosslr.org/ifosslr/article/view/5</ulink></simpara>
</listitem>
</itemizedlist>
</section>
<section id="_comprehensive_books">
<title>Comprehensive books</title>
<itemizedlist>
<listitem>
<simpara>
Andrew M. St. Laurent: Understanding Open Source and Free Software Licensing (2008, O&#8217;Reilly Media)
</simpara>
</listitem>
<listitem>
<simpara>
Lawrence E. Rosen: Open Source Licensing: Software Freedom and Intellectual Property Law (2004 Prentice Hall)
</simpara>
</listitem>
<listitem>
<simpara>
Heather J. Meeker: The Open Source Alternative: Understanding Risks and Leveraging Opportunities (2008 John Wiley &amp; Sons)
</simpara>
</listitem>
</itemizedlist>
</section>
</section>
</section>
</section>
</article>