Copyright Registration of Computer Programs

Picture a two-person startup—call it Acme Logic, Inc.—that has spent eighteen months building a clever scheduling engine. The founders have shipped it, signed three paying customers, and are quietly proud. Then a former contractor launches a competing product that behaves suspiciously like theirs, down to the same odd bug in the time-zone handling. Acme's lawyer asks one question that decides everything that follows: "Did you register the copyright in your code?" The answer—"We always meant to"—is the single most expensive sentence a software company can say.

Here is the thing that surprises almost everyone the first time they hear it: Acme already owns a copyright in its code. It has owned it since the moment a developer's fingers left the keyboard. In the United States, copyright is automatic; it springs into existence the instant an original work of authorship is "fixed in a tangible medium of expression" (17 U.S.C. § 102(a)), and saving a file to disk counts as fixation. No form, no fee, no notice required. So why does registration matter so much? Because the Copyright Act draws a sharp line between owning a copyright and being able to enforce one. Registration is the bridge across that line, and as we will see, it is also the source of the most valuable remedies in the statute.

This guide explains how to register a computer program with the U.S. Copyright Office and—just as important—what that registration actually protects. We will start with the law of what copyright covers in software (and the surprisingly large amount it does not), because you cannot intelligently fill out a registration application without understanding the legal terrain underneath it. Then we will move through the mechanics: who owns the copyright in the first place, the application itself, the all-important deposit of source code, the special rules that let you protect trade secrets without surrendering them, and the wrinkles for derivative versions, screen displays, user manuals, video games, HTML, and object code. We close with how a registration is actually put to work in a lawsuit. Whether you are a solo developer, a general counsel, a judge trying to understand a deposit dispute, or simply curious, you should be able to follow every step. Terms of art are explained in plain English the first time they appear.

A note on scope: this article is about copyright registration specifically. Software can also be protected by patents, trade secrets, and contracts, and the smartest companies layer all four. For the bigger picture, see our companion piece on the legal protection of software. For the general copyright-registration process across all kinds of works, see Copyright Registration—A Comprehensive Guide, and for the step-by-step mechanics common to every work type, How to Register a Copyright With the U.S. Copyright Office. This piece zooms all the way in on code.

Software Is a "Literary Work" (Really)

The first conceptual hurdle is also the one that makes people laugh: in the eyes of copyright law, your C++ application is a literary work—the same category as a novel, a poem, or a cookbook. This is not a metaphor. The Copyright Act defines a "computer program" as "a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result" (17 U.S.C. § 101). Congress added that definition, and confirmed that programs are copyrightable subject matter, through the Computer Software Copyright Act of 1980, acting on the recommendation of the National Commission on New Technological Uses of Copyrighted Works (CONTU). Courts had already been heading that way; the Third Circuit's foundational decision in Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3d Cir. 1983), confirmed that both source code and object code—and programs embedded in ROM—are protectable. The Ninth Circuit reached the same conclusion, anchoring software protection in the bedrock requirement that the code be original and fixed in a tangible medium (Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510, 1520 (9th Cir. 1992); 17 U.S.C. § 102(a)).

Why "literary"? Because copyright's categories are about the form of expression, not the subject. A literary work is one expressed in words, numbers, or other verbal or numerical symbols, regardless of the material object in which it is embodied. Source code is a string of symbols an author chose and arranged. That is enough. When you register, you will indeed select "computer program" as the type of work, but the underlying legal pigeonhole is the literary work.

Two technical terms will recur throughout this article, so let us define them cleanly:

Source code is the human-readable set of instructions a programmer writes in a language like C++, Python, Java, or Perl. A person fluent in the language can read it.
Object code (sometimes "machine code" or "executable code") is what the source code becomes after it is compiled or assembled into the 1s and 0s a computer actually runs. It is not meaningfully human-readable.

Both are copyrightable. But—and this is the heart of the Copyright Office's deposit rules—the Office strongly prefers that you deposit source code, because source code is where a human examiner can actually see the creative expression. We will return to this preference, and to the consequences of ignoring it, when we discuss object code and the Rule of Doubt.

What Copyright in Code Protects—and the Large Slice It Does Not

Here is the single most important sentence in this entire guide, and it is one the Copyright Office itself emphasizes: copyright protects the expression in a program, not the program's functional aspects. The statute is blunt about it. Section 102(b) of the Copyright Act provides that copyright protection "in no case extends to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work" (17 U.S.C. § 102(b)).

Translate that into software terms and you get a list of things your copyright registration will not lock up: a program's algorithms, its logic, its system design, its formatting conventions, its general functions, and the procedures or methods of operation it implements. If your scheduling engine uses a brilliant algorithm to resolve calendar conflicts, copyright does not give you a monopoly on that algorithm. A competitor who writes entirely different code to perform the same function, achieving the same result, has not infringed your copyright at all—they may have written their own protectable literary work. (Whether they have infringed a patent, or misappropriated a trade secret, is a different question with different answers; see Protection of Trade Secrets.) Courts confront this tension constantly precisely because computer code is "both expressive and functional," which makes deciding what is protectable harder than for traditional works (Oracle America, Inc. v. Google Inc., 750 F.3d 1339, 1354 (Fed. Cir. 2014)).

This idea/expression dividing line is old—older than software. The Supreme Court announced its modern form in Baker v. Selden, 101 U.S. 99 (1880), holding that a copyright in a book explaining a bookkeeping system did not give the author any monopoly over the system itself; anyone was free to use the method, even to copy the blank ledger forms that were necessary to practice it. Copyright protects the explanation, never the underlying method. Software simply forced courts to apply that century-old principle to a medium where expression and function are fused tightly together in every line.

Literal and Non-Literal Elements

Before the doctrines do their filtering work, it helps to know what they filter. Courts analyze software at two layers. The literal elements are the code itself—the actual source code and object code as written. The non-literal elements are everything else an author created that is not the verbatim text: the program's structure, sequence, and organization, its modules and their interrelationships, the design of its data structures, and aspects of its user interface. Both layers can, in principle, be protected (see, for example, Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693, 701 (2d Cir. 1992)). This matters commercially because a program's non-literal elements—the architecture, the look and feel of the interface—are often more valuable than the literal lines, and a sophisticated copier rarely copies code verbatim. The hard cases are about the non-literal elements, which is exactly where the next two doctrines and the Altai test earn their keep.

The Merger Doctrine and Scènes à Faire

Two related doctrines do further filtering work, and they matter enormously in software because efficiency tends to dictate code.

Under the merger doctrine, when an idea can be expressed in only one or a very small number of ways, the expression is said to "merge" with the idea and loses protection—because protecting the expression would, in practice, protect the idea, which § 102(b) forbids. In code, a routine that can really only be written one efficient way is often unprotectable on merger grounds.

Under scènes à faire—a phrase borrowed from drama, literally "scenes that must be done"—stock or standard elements that are essentially required by the context are not protected. In a war movie, the obligatory bootcamp scene is scènes à faire; in software, common programming practices, standard techniques, elements dictated by hardware constraints, by interoperability requirements, or by industry standards, are filtered out the same way. Originality—the constitutional and statutory bedrock of copyright—requires a "modicum of creativity," as the Supreme Court held in Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340, 345, 350-51 (1991). Facts, data, and the obligatory are not original to anyone.

Abstraction-Filtration-Comparison: The Workhorse Test

How do courts separate the protectable wheat from the unprotectable chaff in real software disputes? The dominant framework is the abstraction-filtration-comparison test, articulated by the Second Circuit in Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992). It works in three steps:

Abstraction. The court breaks the program down into levels of generality, from the most concrete (the literal code) up through its structure, modules, and algorithms, to its most abstract idea or ultimate function. This mirrors how a program is actually designed, in reverse. One influential decision parsed the program into at least six descending levels of abstraction: "(i) the main purpose, (ii) the program structure or architecture, (iii) modules, (iv) algorithms and data structures, (v) source code, and (vi) object code" (Gates Rubber Co. v. Bando Chemical Industries, Ltd., 9 F.3d 823, 835 (10th Cir. 1993)).
Filtration. At each level, the court strips out everything that is not protectable: ideas and methods under § 102(b), material dictated by efficiency (merger), elements required by external factors and standard practices (scènes à faire), and anything taken from the public domain or owned by third parties. The main purpose, as an idea, generally falls away; the source code and object code generally survive unless they were copied from others.
Comparison. Whatever core of protectable expression survives filtration is then compared to the accused work to determine whether the defendant copied that protected expression (Altai, 982 F.2d at 710).

Altai deliberately buried an earlier, broader test from Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc., 797 F.2d 1222, 1248 (3d Cir. 1986), which had treated everything not strictly necessary to a program's single purpose as protectable expression. Whelan's "structure, sequence, and organization" approach was widely criticized as overprotective, and the abstraction-filtration-comparison framework has become the controlling or leading approach not only in the Second Circuit but also in the Fifth, Sixth, Ninth, Tenth, Eleventh, and Federal Circuits (see, e.g., Engineering Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335, 1342-43 (5th Cir. 1994); Sega, 977 F.2d at 1525; Gates Rubber, 9 F.3d at 834; Bateman v. Mnemonics, Inc., 79 F.3d 1532, 1543-44 (11th Cir. 1996)). Whelan technically remains on the books in the Third Circuit. A third strand exists in the First Circuit, which in Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807, 815-16 (1st Cir. 1995), aff'd by an equally divided Court, 516 U.S. 233 (1996), held that a software "method of operation"—there, the menu command hierarchy of a spreadsheet—is categorically unprotectable under § 102(b), no matter how it is or could be expressed. The practical upshot across all three approaches is the same: the law deliberately leaves a great deal of functional software material free for others to use.

Google v. Oracle: The API Decade Ends (Sort Of)

No discussion of software copyright today is complete without Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021)—the case that consumed the industry for more than a decade. The dispute concerned roughly 11,500 lines of "declaring code" from the Java SE application programming interface (API) that Google reused to build the Android platform, so that the millions of programmers who already knew Java could write Android apps with familiar commands.

An API, in plain terms, is the agreed-upon set of names and calls that lets one piece of software talk to another—think of it as the menu of commands a programmer can invoke. Oracle argued that copying its declaring code (the menu's organization and the method names that summon prewritten functions) was massive infringement. The litigation seesawed: the Federal Circuit twice ruled for Oracle, first holding in Oracle America, Inc. v. Google Inc., 750 F.3d 1339 (Fed. Cir. 2014), that the declaring code and its structure, sequence, and organization were copyrightable, and later that Google's use was not fair.

The Supreme Court, in a 6-2 opinion by Justice Breyer, sidestepped the thorny question of whether the API was copyrightable at all and instead assumed copyrightability for argument's sake and held that Google's copying was fair use under 17 U.S.C. § 107. The Court reasoned that the declaring code was inherently bound up with the uncopyrightable idea of organizing tasks and with the investment of other programmers who had learned the Java calls, that Google took only what was needed to let those programmers work in a new environment (smartphones), and that allowing Oracle to enforce a monopoly here would harm the public by locking up a functional interface. Justice Thomas, joined by Justice Alito, dissented sharply, arguing the declaring code was plainly protectable and the use was not fair.

Two lessons for anyone registering software copyrights. First, Google v. Oracle did not hold that APIs are uncopyrightable—it pointedly declined to decide that, so the question lingers. Second, even where code is registered and protectable, the functional, interoperability-serving slices of it are vulnerable to a fair-use defense. Registration is powerful, but it is not a force field; the idea/expression line and fair use still run straight through your code. (For more on how fair use is reshaping technology disputes, see Copyright Infringement Claims Against Generative AI.)

The Reverse-Engineering Cases: Copying Object Code to Reach Ideas

Google v. Oracle is the latest chapter in a longer story about fair use and functional code. A line of cases predating it established that a competitor may sometimes copy object code wholesale—as an intermediate step—in order to study it and extract the unprotectable ideas, methods, and interface specifications it contains, so long as the end product does not itself reproduce protected expression. In Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992), the Ninth Circuit held that disassembling a game console's code to discover the requirements for making compatible games was fair use; the Ninth Circuit extended that reasoning to copying made to develop an emulator in Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596, 602 (9th Cir. 2000), and the Federal Circuit reached a parallel result in Atari Games Corp. v. Nintendo of America Inc., 975 F.2d 832, 843 (Fed. Cir. 1992). The thread tying these cases to Google v. Oracle is interoperability: copyright is not allowed to become a backdoor patent on the functional ideas needed to make software work with other software. For the registrant, the takeaway is sobering but useful—registration secures your expression, not your ability to stop others from learning how your program works and building around it.

Who Owns the Copyright? Authorship, Work Made for Hire, and Assignments

Before you can register, you have to know whose name goes on the certificate—and getting this wrong is one of the most common and most damaging mistakes in software registration. The default rule is that copyright vests initially in the author, the human (or humans) who created the expression. For software, that default is frequently displaced by two mechanisms.

The first is work made for hire (17 U.S.C. § 101). When an employee writes code within the scope of employment, the employer is treated as the author and original owner from the start. So if Acme's two founders wrote the scheduler as salaried employees of Acme, Inc., the company—not the individuals—is the author, and Acme is both author and claimant on the application. The work-for-hire doctrine is narrower than people assume, though: for an independent contractor, code is a work made for hire only if it falls within one of the nine enumerated categories of specially commissioned works (a category that does not comfortably include most standalone software) and the parties have signed a written agreement saying so. This is exactly how Acme's "former contractor" problem can become an ownership disaster—if the contractor's agreement did not assign the copyright, the contractor may own the very code Acme thinks it owns.

The second mechanism is assignment. Because contractor code is usually not a work made for hire, the standard fix is a written, signed copyright assignment transferring all rights to the company. A transfer of copyright ownership is not valid unless it is in a writing signed by the owner (17 U.S.C. § 204(a)). Founders, too, should formally assign any code they wrote before incorporation to the company. On the application, the entity that owns the copyright is the claimant; if the claimant obtained ownership from the author by something other than work-for-hire, the application asks for a brief "transfer statement" (for example, "by written assignment"). For practical guidance on getting these agreements right, see Employee Invention Assignment Agreements. Sorting out ownership before you register saves you from a registration that names the wrong claimant—a defect that can be exploited in litigation.

Why Register at All? The Enforcement Payoff

If copyright is automatic, why bother with the form and the fee? Because the Copyright Act reserves its sharpest teeth for owners who have registered. Three reasons stand out.

1. You cannot sue without it. Section 411(a) makes registration a precondition to filing an infringement suit for a U.S. work. For years, courts split over whether you needed a completed registration or merely a filed application. The Supreme Court settled it in Fourth Estate Public Benefit Corp. v. Wall-Street.com, LLC, 586 U.S. 296 (2019), holding that "registration . . . has been made" means the Copyright Office has actually acted on your application—either granting or refusing it—not merely that you mailed it in. Translation: if you wait until you discover infringement to apply, you must either sit through the Office's processing queue (often many months) or pay extra for expedited "special handling." Acme Logic's "we always meant to" just became a delay measured in seasons.

2. Statutory damages and attorney's fees. This is the big one. Under 17 U.S.C. § 412, you can recover statutory damages (set amounts under § 504(c), generally up to $30,000 per work, and up to $150,000 per work for willful infringement) and attorney's fees only if the work was registered before the infringement began—or, for a published work, within three months of first publication. Without timely registration, you are limited to your actual damages and the infringer's profits, which in software cases can be devilishly hard to prove and may be small relative to the cost of litigation. Statutory damages change the entire economics of enforcement; they are why a cease-and-desist letter from a registered owner lands so much harder.

3. Prima facie validity. A registration made before or within five years of first publication constitutes prima facie evidence of the copyright's validity and of the facts stated in the certificate (17 U.S.C. § 410(c)). That shifts the burden in litigation onto the alleged infringer to prove your copyright is invalid—a meaningful advantage. Registration also lets you record the copyright with U.S. Customs and Border Protection to help intercept infringing imports.

The takeaway is simple and worth a sticky note on every developer's monitor: register early, register often, and register before you ship. The Office itself "strongly encourages" applicants to file before publication.

The Application: Three Essential Elements

An application for copyright registration has exactly three parts:

A completed application form (filed online through the Copyright Office's electronic registration system, eCO, at copyright.gov);
A nonrefundable filing fee (fees change periodically; the Office publishes current amounts in Circular 4 and on its website); and
A nonreturnable deposit—a copy of the work being "deposited" with the Office.

You apply online through eCO, which is faster and cheaper than paper. As a general rule, you must submit a separate application, fee, and deposit for each work you register. The Office has carved out exceptions—"group registration" options that let you cover multiple works on one application in defined circumstances—and for software the most relevant is the group option for unpublished works, discussed below.

One concept drives most of the software-specific rules, so internalize it now: each version of a computer program that contains new, copyrightable authorship is a separate work. Version 2.0 is legally a different creature from version 1.0. If you want protection for the new code in 2.0, you generally file a new application, with a new fee and a new deposit, for that version. We will see how derivative-work registration handles the relationship between versions.

A related concept you will meet on the form is publication, which has a specialized meaning in software. Software is published when it is made available to the general public on an unrestricted basis—by sale, license, loan, rental, or other transfer to an unrestricted group of users. Distributing commercial off-the-shelf software almost always counts as publication. Crucially, that distribution is typically limited to object code; the source code is usually held back and so remains unpublished. The published/unpublished distinction drives the deadline for preserving statutory damages, the available group-registration options, and how many deposit copies you owe, so answer the question carefully.

Walking Through eCO at a High Level

When you register a single program owned by one party, the high-altitude flow looks like this:

Choose "Standard Application" (or the appropriate group option).
Identify the type of work as a computer program.
Provide the title and, crucially for software, the version—e.g., "Acme Scheduler, Version 3.2."
Identify the author(s) and, where the author is not the owner (for example, because the code is a work made for hire or rights were assigned), the claimant who owns the copyright, with a transfer statement if needed.
Complete the "Author Created" field, checking the box for "computer program." (As we will see, that single box also captures any screen displays the program generates, if the same party owns both.)
Handle the "Limitation of Claim" if any preexisting, previously published, previously registered, public-domain, or third-party material is embedded in your code. This is where you tell the Office, in effect, "Don't credit me for the parts I didn't newly write."
Pay the fee and upload the deposit.

A worked example clarifies the limitation-of-claim point. Suppose Acme's Version 3.2 deposit shows a copyright notice reading "© 2023, 2024, 2025." An examiner seeing multiple years may wonder whether those refer to earlier versions that were separately published or registered (which the new registration would not cover) or merely to the program's development timeline. To avoid a delaying inquiry, Acme should use the "Note to Copyright Office" field to explain: e.g., "The dates reflect the developmental history of a single program first published in 2025; no earlier version was published or registered." A few sentences here can save weeks. (For why those notice dates appear in the first place and how to format them, see Copyright Notice—Form, Function, and Best Practices.)

There is a narrow but useful exception worth knowing: a single registration may cover both new and preexisting source code if (1) the preexisting code was never published or registered, and (2) the same claimant owns the copyright in both the new and the preexisting code. In that case the claimant can register the whole thing at once. But the moment the preexisting code was published, registered, dedicated to the public domain, or owned by someone else, it falls outside the new registration and must be disclaimed in the limitation-of-claim field.

The Deposit: Source Code, and the Famous 25-and-25 Rule

The deposit is where software registration gets genuinely interesting, because Congress and the Copyright Office had to solve a real-world problem: developers want the legal benefits of registration but do not want to dump their valuable, secret source code into a government file that the public can inspect. The deposit rules are the elegant—if fussy—compromise.

The baseline instruction is straightforward: deposit the source code for the specific version you want to register. You can upload it through eCO (a PDF is preferred) or print and mail it. Always add the title and version number to the first page. A quick but important note on scripted languages: for programs written in JavaScript or similar scripting languages, the script counts as the equivalent of source code, and you deposit the same number of pages you would for compiled source. Screenshots of on-screen text, buttons, or commands are not an acceptable substitute for code.

Now the compromise. The Office does not require you to deposit all of your source code. For a program without trade secret material, the rule is the well-known "first 25 and last 25":

Deposit one copy of the first twenty-five pages and the last twenty-five pages of the source code for the version you want to register.
If the code lacks a precise beginning, middle, or end, deposit fifty pages that reasonably represent the first and last portions.
If the entire program is fifty pages or fewer, deposit the entire source code and tell the Office you are submitting all of it.
In every case, include the page containing the copyright notice, if there is one.

Why 25 and 25? Because those fifty pages give the examiner enough to confirm that the deposit is, in fact, copyrightable source code—while leaving the bulk of a large program unpublished and out of public view. (Once a work is registered, the deposit becomes part of the public record; anyone can request to inspect it. That is exactly why developers care so much about what goes in.)

Protecting Trade Secrets in the Deposit

Here is where the Copyright Office shows real sophistication, because a single block of source code can be both a copyrighted literary work and a trade secret. A trade secret, broadly, is information that derives independent economic value from not being generally known and that the owner takes reasonable steps to keep secret (see Protection of Trade Secrets and Building a Trade Secret Protection Program From Scratch). Publicly depositing the secret sauce would destroy the very secrecy that makes it a trade secret. So the Office offers special trade-secret deposit options that let an owner register copyright while keeping the confidential portions confidential.

If your source code contains trade secrets, you must say so in writing to the Office, and then choose one of the following options for the version you want to register:

First 10 and last 10, nothing blocked out. Deposit one copy of the first ten pages and last ten pages of source code, with no redactions. (You give up fewer total pages, but those pages are fully visible.)
First 25 and last 25, with redactions. Deposit the first and last twenty-five pages, blocking out the portions containing trade secret material—provided the blocked-out portions are less than fifty percent of the deposit.
Object code plus a source-code window. Deposit the first twenty-five and last twenty-five pages of object code, together with ten or more consecutive pages of source code with nothing blocked out. (This leans on the object-code rules discussed below.)
Short program, with redactions. If the entire program is fewer than fifty pages, deposit the whole thing, blocking out the trade-secret portions—again, provided the redactions are less than fifty percent of the deposit.
No precise structure. If the code lacks a precise beginning, middle, or end, deposit twenty to fifty pages reasonably representing the first and last portions.

In every option, include the portion that bears the copyright notice, if any.

A crucial caution, because this trips up filers constantly: the Office strictly enforces these redaction rules and will refuse a deposit that does not conform. Two requirements deserve emphasis. First, the blocked-out portions must be proportionately less than the portions left visible—you cannot black out the whole file and call it a deposit. Second, the unblocked portions must contain an appreciable amount of copyrightable expression. The logic is sound: the examiner has to be able to see enough genuine, original code to confirm there is something copyrightable there. The Office's detailed guidance lives in the Compendium of U.S. Copyright Office Practices (Third Edition), Chapter 1500, § 1509.1(C)(4)(d); the Compendium is the Office's internal operations manual and the most authoritative public source on these mechanics.

A worked example ties it together. Beta Crypto, LLC (a hypothetical) has a 4,000-page proprietary encryption library and considers its core key-derivation routine a closely guarded trade secret. Beta wants the litigation benefits of registration but cannot expose the routine. Option 2 fits: Beta deposits the first 25 and last 25 pages, redacting the lines that disclose the secret routine, and ensures the black bars cover well under half of those fifty pages while the remaining visible code still shows real authorship. Beta also files a written statement that the deposit contains trade secret material. Done correctly, Beta walks away with a registration and an intact trade secret. Done sloppily—redacting 80% of the pages—Beta gets a refusal and a delay. A second hypothetical shows when not to redact: if Beta's only secret is buried in a single mid-file module that never appears in the first or last 25 pages, Beta may not need to redact at all—the deposit can simply consist of unredacted opening and closing pages that happen never to contain the secret.

Derivative Computer Programs: Registering Versions

Software is never finished; it is iterated. The copyright system handles new versions through the concept of the derivative work. A derivative work is one "based upon one or more preexisting works"—a translation, adaptation, abridgment, or any form in which a preexisting work is "recast, transformed, or adapted" (17 U.S.C. § 101). A new version of a program, with revised and added code, is a textbook derivative work of the earlier version.

The cardinal rule of derivative copyright lives in 17 U.S.C. § 103(b): the copyright in a derivative work extends only to the new material contributed by the author, and it does not affect, enlarge, or grant any exclusive right in the preexisting material. So a registration for Version 4.0 covers the new and revised code added in 4.0—nothing more. It does not cover, and cannot rescue, code carried over from earlier versions that were published, registered, in the public domain, or owned by a third party. (For the full treatment of this topic across all media, see Copyright Registration for Derivative Works.)

There is a threshold of originality the new material must clear. You can register a derivative program only if its new material is both original and sufficiently different from the preexisting work to qualify as an independent work of authorship. Making "only a few minor changes," or changes "determined by the functionality of the hardware," does not cut it. Recompiling, fixing a handful of typos, or making purely mechanical adjustments will not earn a fresh registration. This mirrors the broader rule that derivative copyrights are "thin"—they protect only the incremental creativity, as illustrated by cases like Durham Industries, Inc. v. Tomy Corp., 630 F.2d 905 (2d Cir. 1980), where trivial variations on a preexisting work were held insufficiently original to support a separate copyright.

The deposit rules for a derivative program flex to make sure the examiner actually sees the new code:

If the new or revised material appears throughout the program, deposit the first 25 and last 25 pages of source code.
If the new material does not appear in those pages, deposit any fifty pages of source code that contain the new or revised material.
If the code contains trade secrets, use one of the trade-secret options described above.

As always, include the page bearing the copyright notice. The practical wisdom: keep good records of which lines changed between versions, because if your new authorship is buried in the middle of a million-line codebase, you will need to point the examiner to fifty pages that show it. A clean diff or release log is not just good engineering hygiene—it is registration evidence.

A worked example: Acme Scheduler 1.0 was published and registered in 2024. In 2025, Acme ships 2.0, adding a substantial new machine-learning conflict-resolution module while leaving 1.0's core intact. Acme files a new application for 2.0 as a derivative work, disclaims the previously registered 1.0 code in the limitation-of-claim field, and—because the new module sits in the middle of the codebase—deposits fifty pages drawn from the new module so the examiner can see the fresh authorship. Now Acme has timely registrations for both versions, which matters enormously for § 412 statutory damages if a competitor later copies the 2.0 module specifically.

A Word on Group Registration of Unpublished Versions

If your various versions are still unpublished, you may be able to register multiple of them together using the Office's group registration option for unpublished works, saving fees and effort. Once a version is published, though, it generally needs its own registration. Because "publication" in software (distribution of copies, including by sale or license) has its own technical contours, when in doubt, treat each shipped version as published and register it individually.

Screen Displays and Graphical User Interfaces: Usually One Work With the Code

A common question: do I need a separate registration for what my program looks like on screen—the windows, icons, layouts, and graphics it generates? Usually not. The Office's default position is that a computer program and the screen displays it generates are the same work, because most displays are produced by the program code itself. (The case law has long recognized that audiovisual displays generated by a program can be protectable; see Stern Electronics, Inc. v. Kaufman, 669 F.2d 852 (2d Cir. 1982), involving a video game's sounds and displays.)

A clarifying distinction helps here. The code that draws the interface is a literary work, registered as a computer program. The visual output—the graphical user interface, or GUI, with its buttons, icons, pull-down menus, windows, and scroll bars—is "computer-generated output," a product of the program rather than the program itself (see Altai, 982 F.2d at 703 (such items "represent products of computer programs, rather than the programs themselves")). It can be protected as an audiovisual or pictorial/graphic work to the extent it contains original expression, subject to the same § 102(b) filtering—a layout dictated purely by function or convention is no more protectable than functional code.

The practical consequences for registration:

Same owner. If the same party owns the copyright in both the program code and the screen displays, you register them together with a single application. You simply check the "computer program" box in the "Author Created" field; you do not need to separately assert a claim in the screen displays. A registration for the program covers the copyrightable expression in the code and in any copyrightable screen displays it generates—even if the application never mentions the displays and you never deposit a screenshot.
Different owners. If different parties own the code and the displays—for instance, a company licensed the underlying engine from a third party but designed the interface in-house—then separate applications are required, because they are no longer the same work owned by the same claimant.

If you do want to specifically claim the screen displays in the application (perhaps to make the visual authorship explicit on the record), you must then deposit a representative sampling of those displays—screenshots, in practice. The governing guidance is Compendium Chapter 1500, § 1509.1(C)(6).

This screen-display rule is one reason video games and richly visual applications need careful handling, which brings us to the next two topics. (For interface-heavy products like phone apps, where copyright, trade dress, and patents intersect, see Protecting Your Mobile App—A Comprehensive IP Strategy Guide.)

Video Games: Two Works in One Cartridge

A video game is a hybrid, and the registration rules reflect its split personality. The Office sees a typical game as having two major components: (1) the audiovisual material that appears on screen—the graphics, animation, characters, and sound—and (2) the computer program that runs the game underneath. (For the deeper dive on games specifically, including board games and the famous rule that game mechanics are not copyrightable, see Copyright Registration of Games.)

The registration logic tracks the screen-display rule:

Same owner, published together. If the same party owns both the program and the audiovisual material, you can register them on one application—provided that, if published, they were published together as a single unit.
Different owners or separate publication. If the program and the audiovisual material were published separately, or are owned by different parties, each is a separate work needing its own application. This is common where, say, a studio licenses a game engine from one company while owning the art and story itself.

The deposit for a game depends on its form. If the game is fixed on a CD-ROM (or analogous physical media), mail one complete copy of the entire package, including any instruction manual, plus a portion of the source code using one of the source-code options above. If the game is not fixed on a CD-ROM, deposit identifying material—a photograph or video frames showing representative portions of the audiovisual elements—together with a brief written description of the game, again plus a portion of the source code if you are registering the program too. The detailed video-game deposit guidance is in Compendium Chapter 1500, § 1509.2(E)(2).

User Manuals and Documentation

Programmers write more than code; they write user manuals, installation guides, flow charts, and developer documentation. These are protectable as literary works in their own right, provided they contain a sufficient amount of copyrightable authorship. (A bare list of commands with no explanatory prose may be too thin; a richly written manual is plainly protectable.)

Whether you register the documentation together with the program or separately depends on ownership and publication:

One application covers the program and its documentation if the same party owns the copyright in both. But there is a publication catch: if both have been published, they must have been physically bundled together and first published as an integrated unit. If they were published separately, or owned by different parties, each is a separate work needing its own application.
To register a program with its documentation on one application, deposit one complete copy of the documentation plus a portion of the source code (using a source-code option above).
To register documentation alone (no program), deposit two complete copies if published, one if unpublished. Upload as a PDF or mail a physical copy.

HTML Is Not a Computer Program

Web developers are often startled to learn that, for registration purposes, HTML is not a computer program. HyperText Markup Language is a markup language used to structure and present web pages; the Copyright Office takes the position that it does not constitute source code, in part because HTML is frequently generated by automated website-design software rather than hand-authored. The Office will therefore not register HTML as a computer program.

That does not mean HTML is unprotectable. You can register HTML as a literary work—but only if it was created by a human being (not generated by a design program) and contains a sufficient amount of creative expression. And there is a deposit twist: to register HTML, you must deposit a complete copy of the entire code; you cannot use the abbreviated first-25/last-25 options reserved for true source code. For the broader treatment of registering websites—which are bundles of text, images, code, and audiovisual works rather than a single "website" work—see Copyright Registration of Websites and Website Content. And because websites raise their own thicket of issues around scraping and user-generated content, see Data Scraping After hiQ v. LinkedIn.

Object Code and the "Rule of Doubt"

Recall the Office's strong preference for source-code deposits. You may deposit object code instead—the compiled machine code—but doing so triggers the Copyright Office's Rule of Doubt, and you should understand exactly what that means before you choose it.

The Rule of Doubt is the Office's way of registering something it cannot independently verify. Because object code is not human-readable, an examiner cannot look at it and confirm that it contains copyrightable authorship. So the Office registers it on the applicant's say-so, while notifying the world that it is "unwilling to grant a presumption of validity to certain aspects of the claim." In other words, you get a registration certificate, but the prima facie validity benefit of § 410(c)—the presumption that shifts the burden to your opponent in litigation—is undermined for the object-code material. That is a real cost in a future lawsuit, where you would rather start with the presumption on your side. The Rule of Doubt is explained in Compendium Chapter 600, § 607.

If you nonetheless deposit object code, the Office imposes specific requirements: you must state in writing that the object code contains copyrightable authorship and request registration under the Rule of Doubt. If the object code embeds the copyright notice, you must deposit the portion where the notice appears, with the notice underlined or highlighted and rendered in words and numbers an examiner can actually read. The Office will check that the formal and legal requirements for registration are met, but it will make no determination about the copyrightability of the object code—it simply accepts your assertion and registers under the Rule of Doubt.

The practical advice writes itself: deposit source code whenever you possibly can. Use object code only when you have a compelling reason (for example, the source has genuinely been lost), and pair it where possible with the trade-secret option that combines object code with a window of unredacted source code, so the examiner sees at least some readable authorship.

Special Relief: When the Source Code Is Gone

Sometimes life intervenes. A company is acquired, a server is wiped, a version is lost, and the source code for the specific release you need to register no longer exists. All is not lost, because the Office is authorized to grant special relief from the deposit requirements in appropriate circumstances.

If the source code for a particular version is no longer available, you may still register that version if a substantial portion of the code appears in an earlier or later version of the same program. To request special relief, you must:

Make the request in writing;
State the specific reasons you cannot submit source code for the version you want to register;
Explain what percentage of that version's code appears in the available earlier or later version;
Submit a portion of the code from the other version; and
Include at least some portion of the version you want to register, even if incomplete.

You can request special relief in the "Note to the Copyright Office" field of the online application, or by mail to the Associate Register of Copyrights and Director of Registration Policy and Practice, U.S. Copyright Office, P.O. Box 70400, Washington, DC 20024. The Office evaluates each request when it arrives. Special relief is discretionary, not a right—but it is a genuine safety valve worth knowing exists.

After Registration: Putting the Certificate to Work

A registration certificate is not a trophy for the wall; it is litigation infrastructure. Understanding how it functions in a real dispute clarifies why the choices above matter so much.

When Acme sues its former contractor, it must prove two things: (1) ownership of a valid copyright, and (2) copying of protected elements of the work. The registration does heavy lifting on the first element—if it issued within five years of first publication, it is prima facie evidence of validity, so the contractor bears the burden of showing the copyright is invalid (§ 410(c)). On the second element, because direct evidence of copying is rare, courts allow a plaintiff to prove actual copying circumstantially through access plus probative similarity, and then to prove unlawful appropriation through substantial similarity of the work's protected expression. Note that these are two distinct inquiries that opinions sometimes blur; some courts now use "probative similarity" for the copying question and reserve "substantial similarity" for the appropriation question (see, e.g., Tanksley v. Daniels, 902 F.3d 165, 173 (3d Cir. 2018); Design Basics, LLC v. Signature Construction, Inc., 994 F.3d 879, 888 (7th Cir. 2021)).

Here is where the entire first half of this guide comes home. To assess substantial similarity in a software case, the court runs the abstraction-filtration-comparison test, strips out the ideas, methods, merged expression, scènes à faire, and third-party material, and compares only what survives. The "same odd bug in the time-zone handling" that started this story is, in practice, exactly the kind of evidence that wins these cases—an arbitrary, expressive quirk that has no functional reason to be there and is wildly unlikely to be reproduced independently. Shared errors, idiosyncratic comments, and dead code copied verbatim are the fingerprints of literal copying. (For how courts conduct the similarity analysis in detail, and for the remedies available once infringement is shown, deeper treatment lives in the broader copyright-litigation literature; on enforcement strategy generally, see What Are the Consequences of Pirating Intellectual Property.) If the contractor instead rewrote the engine from scratch, copying only Acme's function, the filtration step may leave little behind—a reminder that copyright guards expression, not results.

How Copyright Fits With Patents, Trade Secrets, and Contracts

Copyright registration is one instrument in a four-piece band, and the best software protection comes from playing them together. A quick orientation, because choosing the wrong instrument—or only one—leaves value on the table:

Copyright protects the expression in your code automatically and cheaply, and registration unlocks enforcement, statutory damages, and fees. Its great limitation, as we have seen, is that it protects none of the functional ideas, algorithms, or methods. A clean-room reimplementation that copies your function but not your expression slips past it.
Patents can protect the functional inventions copyright cannot—novel, non-obvious processes and systems—but software patents must clear the eligibility gauntlet of Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), and § 101. See Patent Eligibility After Alice and the friendly primer at Patent Basics—A Plain-English Guide.
Trade secrets protect anything valuable that you keep secret—including the very algorithms copyright ignores—for as long as you keep it secret. The catch is that publication or independent discovery (including lawful reverse engineering, as the Sega/Sony line illustrates) ends the protection, which is precisely why the deposit redaction rules above are so important: they let you register copyright without forfeiting trade-secret status. See Protection of Trade Secrets and Trade Secrets in the Age of Remote Work and Cloud Computing.
Contracts—licenses, EULAs, NDAs—define what users may do with your software regardless of the background IP rules. See Software Licensing Agreements and Drafting Software License Agreements—Key Terms and Negotiation Points.

One special interaction deserves a flag: open source. If your codebase incorporates open-source components—and almost every modern codebase does—you must respect their licenses, and you must disclaim third-party code in your registration's limitation-of-claim field, because you do not own it. Copyleft licenses like the GPL can also impose obligations on the code you distribute alongside them. The pitfalls are real; see Open Source Licensing Landmines in Enterprise Software Development. Registering a codebase as if you authored every line, when half of it came from npm, is both inaccurate and potentially fatal to your registration if challenged—an inaccurate material statement made with knowledge can, under 17 U.S.C. § 411(b), give an opposing party an opening to attack the registration itself.

Key Takeaways

If you remember nothing else, remember these:

Copyright in your code is automatic, but enforcement is not. Registration is the gateway to federal court (Fourth Estate), and timely registration is the gateway to statutory damages and attorney's fees (§ 412)—the remedies that actually make infringement litigation worth pursuing.
Register early—ideally before you publish. Registering before infringement begins (or within three months of publication) is what preserves the powerful remedies. "We always meant to" is the costliest phrase in software IP.
Nail down ownership first. Confirm whether the code is a work made for hire and get signed assignments from contractors and founders (§ 204(a)) before you name a claimant.
Copyright protects expression, not function. Algorithms, logic, system design, and methods of operation are outside its reach (§ 102(b)), filtered out by merger, scènes à faire, and the abstraction-filtration-comparison test of Altai (now followed in most circuits). Google v. Oracle and the reverse-engineering cases are vivid reminders that even registered code can meet a fair-use defense where interoperability is at stake.
You usually deposit only a slice of your code—the first 25 and last 25 pages—and the Office offers specific trade-secret options (10-and-10 unredacted, 25-and-25 with redactions under 50%, the object-code-plus-source window, and others) so you can register without surrendering your secrets. Follow the redaction limits exactly; the Office strictly enforces them.
Each new version is a separate work. Register meaningful releases as derivative works, disclaim what you didn't newly author, and keep records (clean diffs) of what changed.
Mind the special cases: screen displays and GUIs usually ride along with the code; video games and documentation may be one work or several depending on ownership and publication; HTML registers (if at all) as a human-authored literary work, not a program; and object code drags in the Rule of Doubt, so deposit source whenever you can.

Treat registration not as paperwork but as insurance you buy before the fire. The premium—a form, a fee, and fifty pages of code—is trivial next to the payout it secures.

Frequently Asked Questions

Do I have to register my software to own the copyright? No. Copyright exists automatically the moment original code is fixed in a tangible medium—saved to disk. But you cannot file an infringement suit on a U.S. work until the Copyright Office has acted on a registration application (Fourth Estate Public Benefit Corp. v. Wall-Street.com, LLC, 586 U.S. 296 (2019)), and you cannot recover statutory damages or attorney's fees unless you registered before the infringement began or within three months of first publication (17 U.S.C. § 412). Registration is optional in theory and essential in practice.

Who owns the copyright in software written by an employee or a contractor? Code written by an employee within the scope of employment is a work made for hire, so the employer is the author and owner from the outset (17 U.S.C. § 101). Code written by an independent contractor is usually not a work made for hire, so the contractor owns it unless a signed written agreement assigns the copyright to the hiring party (17 U.S.C. § 204(a)). Founders should also assign any pre-incorporation code to the company. Sort this out before you register, because the application must name the correct claimant.

Will registering force me to make my source code public? Not your whole codebase. For ordinary programs you deposit only the first 25 and last 25 pages, and if your code contains trade secrets you can use special options—such as depositing the first and last 25 pages with the secret portions blocked out (redactions under 50% of the deposit), or depositing object code paired with a small window of unredacted source code. The Office strictly enforces these redaction rules, so follow them precisely. Done correctly, you keep your trade secrets while still registering.

Does my copyright stop a competitor from copying what my software does? No. Copyright protects your particular expression—the specific code you wrote—not the underlying function, algorithm, logic, or method of operation (17 U.S.C. § 102(b)). A competitor who independently writes different code to accomplish the same task has not infringed your copyright. To protect the functional invention itself, you would need a patent; to protect a secret method, a trade secret.

What did Google v. Oracle actually decide about software copyright? In Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021), the Supreme Court assumed (without deciding) that the copied Java API declaring code was copyrightable, and held that Google's reuse of roughly 11,500 lines to build Android was fair use. The case did not rule that APIs are uncopyrightable—it expressly left that open—but it confirmed that the functional, interoperability-serving portions of code are vulnerable to a fair-use defense even when registered. It sits alongside an older line of cases (Sega v. Accolade, Sony v. Connectix, Atari v. Nintendo) holding that copying code as an intermediate step to reach unprotectable ideas can be fair use.

I just released version 3.0 with major new features. Do I file a new registration? Generally yes. Each version with new copyrightable authorship is a separate work. Register 3.0 as a derivative work: claim the new and revised code, disclaim previously published or registered material in the limitation-of-claim field, and—if the new code isn't in the first or last pages—deposit any fifty pages that contain the new material. Registering each significant release preserves statutory-damages eligibility for that version's new code.

Can I just deposit my compiled executable (object code)? You can, but it's a last resort. Object code triggers the Copyright Office's "Rule of Doubt": because the Office can't read machine code to verify copyrightable authorship, it registers on your assertion and withholds the usual presumption of validity for that material. You must state in writing that the object code contains copyrightable authorship and request registration under the Rule of Doubt. Whenever possible, deposit source code instead.

Is HTML registrable as a computer program? No. The Copyright Office does not treat HTML as source code and will not register it as a computer program. You may register HTML as a literary work if a human (not a website-design program) authored it and it contains sufficient creative expression—but you must deposit the entire code, not an abbreviated portion. For websites generally, register the constituent works (text, images, audiovisual elements, and any true source code) by type.

What if I've lost the source code for the version I need to register? You may be able to obtain "special relief." If a substantial portion of the missing version's code appears in an earlier or later version, you can request, in writing, to deposit code from that other version plus at least some portion of the version you want to register, explaining why the original is unavailable and what percentage overlaps. The Office evaluates such requests case by case.

How will my registration help if I actually have to sue? A timely registration gives you a prima facie presumption that your copyright is valid (§ 410(c)), shifting the burden to the defendant, and it is what unlocks statutory damages and attorney's fees (§ 412). To win, you still must prove copying of protected expression—typically through access plus similarity—after a court filters out the unprotectable functional material under the abstraction-filtration-comparison test. Tell-tale fingerprints like copied bugs, comments, or dead code are powerful evidence of literal copying.

This article provides general information and is not legal advice. Copyright registration rules, fees, and Copyright Office practices change, and how the law applies depends on your specific facts. For advice about registering or enforcing rights in your software, consult qualified counsel.