Checklist · Intellectual Property

Copyright Registration for Software: A Practical Checklist

Type
Checklist
Jurisdiction
National
Date
2026-05-15
Topic
Intellectual Property

Copyright in software exists the instant the code is fixed, but registration is the key that opens the courthouse door, statutory damages, and attorney's fees. This checklist takes a developer, founder, or in-house lawyer through registering a computer program end to end: confirming ownership and clearing contractor and open-source problems, choosing the right application, filling in the limitation-of-claim field, and building a source-code deposit under the first-25-and-last-25 rule and the trade-secret redaction options that let you register without handing your crown jewels to the public. It works through derivative releases, screen displays, the Rule of Doubt for object code, preregistration, and special relief when the source has vanished. It anchors the mechanics in the Compendium, Section 412 timing, and the doctrine that fixes what copyright in code actually reaches. Confirm current fees and deposit options at copyright.gov before you file.

Copyright Registration for Software: A Practical Checklist

Intellectual Property > Copyright | Published 15 May 2026 - Updated 19 June 2026 | UpLaw - uplaw.us

A field guide to registering a computer program with the U.S. Copyright Office: how to fix ownership, choose an application, disclaim what you do not own, and file a deposit that satisfies the examiner without publishing your secret source code.

Keywords: copyright registration, software copyright, computer program, source code deposit, trade secret redaction, first 25 and last 25 rule, object code, Rule of Doubt, derivative computer program, work made for hire, Section 412 statutory damages, limitation of claim, eCO application, Fourth Estate, open-source disclaimer, preregistration

Copyright attaches to code the moment it is written to disk. Saving a file is "fixation in a tangible medium of expression," and fixation is all the statute requires for protection to spring into existence. See 17 U.S.C. § 102(a). No filing, no fee, no lawyer. A weekend project pushed to a private repository at 2 a.m. is already a protected literary work.

So why does anyone bother registering? Because the Copyright Act runs a two-tier system, and it saves its most valuable remedies for owners who registered. For a U.S. work, registration is a precondition to filing an infringement suit at all: the Supreme Court held in Fourth Estate Public Benefit Corp. v. Wall-Street.com, LLC, 586 U.S. 296 (2019), that "registration . . . has been made" under 17 U.S.C. § 411(a) means the Office has acted on the application, not merely that the applicant mailed it in. Until the certificate (or a refusal) issues, the courthouse door is shut. And timely registration is what unlocks statutory damages and attorney's fees under 17 U.S.C. § 412 — the remedies that make infringement worth suing over when actual damages are small or hard to prove.

The difficulty is uniquely acute for software. Registration is a public act. The deposit you submit becomes part of the public record, and anyone can ask to inspect it. But the whole commercial value of a proprietary codebase often lies in keeping the source secret. Developers want the litigation firepower that registration provides without dumping their algorithms into a government file cabinet that competitors can browse. The deposit rules are the Copyright Office's careful, fussy answer to that tension, and most of this checklist is about getting them right.

This is the software-specific companion to the general copyright registration checklist and the deeper copyright registration comprehensive guide. For the substantive law of what copyright in code actually protects, and how it sits alongside patents and trade secrets, see how the law protects software and the detailed treatment in registering copyright in software and source code. Everything below assumes you have decided that copyright is one of the tools in your protection stack; if you are still choosing among the regimes, start with copyright, trademark, patent, and trade secret compared.

What copyright in software actually protects (and what it does not)

Before touching the application, understand the shape of the right you are registering, because that shape controls how you describe the work, what you disclaim, and how you will later prove infringement.

A "computer program" is defined by statute 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. The Office pigeonholes programs as literary works — a program is protected on the same footing as a novel, because it is expression fixed in words and symbols. That classification matters: it is why the deposit rules resemble those for text, why the copyright subsists in the way the instructions are written rather than in what they accomplish, and why the human-authorship and originality requirements of Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340 (1991), apply. Sweat and cleverness are not enough; there must be a modicum of original expression.

Copyright protects both source code (the human-readable text) and object code (the machine-readable binary the compiler produces). The Third Circuit settled the point early in Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3d Cir. 1983), holding that object code embedded in a ROM is copyrightable expression no less than the source it was compiled from. Both are the same work in different clothing.

The crucial limit is 17 U.S.C. § 102(b): copyright never extends to "any idea, procedure, process, system, method of operation, concept, principle, or discovery," regardless of how it is described in the work. In software, § 102(b) does enormous work. It means:

  • The function is free. The algorithm, the protocol, the data structure as a concept, the thing the program does — none of that is copyrightable. A competitor may study what your program accomplishes and build an independent program that does the same thing, so long as it does not copy your expression.
  • Merger swallows expression that is dictated by function. Where there is essentially only one way, or only a few ways, to write the code that achieves a given result, idea and expression "merge," and that code is unprotectable. Efficiency, interoperability constraints, hardware requirements, and industry programming conventions all shrink the space of protectable expression.
  • Scenes a faire has a software cousin. Elements dictated by external factors — the target operating system, standard programming practice, the demands of the industry being served — are filtered out.

The Second Circuit built the dominant analytic framework in Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992): the abstraction-filtration-comparison test. A court breaks the program into levels of abstraction (from the literal code up through structure, sequence, and organization to the ultimate function), filters out at each level the unprotectable ideas, merger material, scenes a faire, and public-domain elements, and then compares what remains — the "golden nugget" of protectable expression — against the accused work. Altai deliberately narrowed the broad "structure, sequence, and organization" protection that the same court's earlier era had flirted with in Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc., 797 F.2d 1222 (3d Cir. 1986), where a single "idea" was defined so broadly that nearly all structure counted as protectable expression. The modern rule is filtration first, protection second.

Two more decisions frame the outer edges. In Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807 (1st Cir. 1995), aff'd by an equally divided Court, 516 U.S. 233 (1996), the First Circuit held that a spreadsheet's menu-command hierarchy was an uncopyrightable "method of operation" under § 102(b) — a reminder that the interface through which users operate a program can fall outside copyright entirely. And in Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021), the Supreme Court assumed for argument's sake that the declaring code of the Java SE API was copyrightable but held Google's reuse of roughly 11,500 lines to build Android was fair use — a decision that resolved a decade of litigation on fair-use grounds while pointedly declining to decide the copyrightability question the Federal Circuit had answered in Oracle America, Inc. v. Google Inc., 750 F.3d 1339 (Fed. Cir. 2014). The practical lesson for a registrant: copyright in code is real and worth having, but it is thin around functional and interface elements, and you should register with a clear-eyed view of which parts of your program carry the protectable expression.

None of this is academic. When you describe the work, disclaim third-party material, and later select which pages to deposit, you are implicitly making claims about where your protectable authorship lives. A registration that overclaims — that treats every functional line as your original expression — invites a validity fight later. For the eligibility side of software (the very different question of whether an invention embodied in the code can be patented after Alice), see protecting software and business-method inventions after Alice and the companion Section 101 eligibility checklist. Copyright and patent protect different things about the same program, and a mature IP strategy layers them; see how the law protects software.

Why bother: the four benefits registration actually buys

Keep these front of mind, because they set the deadlines that everything else in this checklist serves.

1. The right to sue. Under § 411(a) as construed by Fourth Estate, you cannot file a U.S. infringement suit until the Office has granted or refused registration. If you are trying to stop live infringement of a codebase you never registered, you are stuck in the queue — ordinary processing can run several months. That queue is why sophisticated software owners register before they need to sue, not after.

2. Statutory damages and attorney's fees. This is the big one. Under § 412, statutory damages (17 U.S.C. § 504(c): $750 to $30,000 per work, up to $150,000 for willful infringement) and attorney's fees (§ 505) are available only if the work was registered before the infringement began, or within three months of the work's first publication. Miss that window and you are limited to actual damages plus the infringer's profits — often a tiny or unprovable number for software, where the infringer may have paid nothing and earned little directly. The fee-shifting matters just as much: it is what makes a modest infringement economically litigable at all. For how these numbers actually play out, see what an IP case is worth.

3. The presumption of validity. A registration made before publication or within five years after first publication is prima facie evidence of the copyright's validity and of the facts stated in the certificate. 17 U.S.C. § 410(c). In litigation that shifts the burden to the defendant to prove your copyright invalid — a meaningful head start. (As we will see, object-code deposits under the Rule of Doubt forfeit this benefit for the material the examiner could not read.)

4. Access to the Copyright Claims Board. The CASE Act of 2020 created the Copyright Claims Board (CCB), a small-claims tribunal inside the Copyright Office with damages capped at $30,000. To bring a claim you must have registered or at least filed a pending application. For a solo developer or small studio facing a copied app or a scraped codebase, the CCB is a lower-cost forum than federal court — but the registration prerequisite still applies.

A fifth, quieter benefit: registration defeats an "innocent infringer" mitigation argument when paired with proper notice, and it creates a public, searchable record of your authorship and ownership. On the notice piece, see the copyright notice checklist and copyright notice: form, function, and best practices.

Worked example — the missed window. Cardinal Freight, a logistics startup, ships "RouteWeaver 1.0" to its first paying customer in January without registering. In August a departed engineer launches a competing product that reuses Cardinal's route-optimization module. Cardinal registers in September and sues. Because the work was not registered before the infringement began, and September is well past three months after the January publication, § 412 bars statutory damages and fees. Cardinal can still sue — the September registration satisfies § 411(a) — but it must prove actual damages, and the copied module never generated a separate line item of revenue. Had Cardinal registered RouteWeaver in January, before publication, the same suit would have carried a threat of up to $150,000 in willful statutory damages plus fees. The registration would have cost less than a business lunch. This is the single most common and most expensive software-copyright mistake.

Phase 1 — Lock down ownership and clearance before you file

The application asks who authored the work and who claims the copyright. Get those two answers wrong and you have built a registration on sand. The most damaging software-registration errors are ownership errors, and they are almost always avoidable.

  • [ ] Classify each contributor. Code written by an employee within the scope of employment is a work made for hire; the employer is the author and the initial owner as a matter of law. 17 U.S.C. §§ 101, 201(b). "Employee" here is a term of art — the Supreme Court in Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), directs courts to the common-law agency factors (control over the work, source of tools, skill required, tax treatment, benefits, and so on), not the label on the paycheck. A misclassified "contractor" who is really an employee can still produce work-for-hire code, but you do not want to litigate that on the courthouse steps. Run the analysis with the determining work made for hire checklist.

  • [ ] Get contractor code assigned in writing. Independent-contractor code is usually not a work made for hire — software does not fit neatly into any of the nine enumerated categories of commissioned works in § 101, so the specially-commissioned route is generally unavailable. That means the contractor owns the copyright unless there is a signed assignment, and a transfer of copyright ownership "is not valid unless" it is in a writing signed by the owner. 17 U.S.C. § 204(a). An email is thin ice; get a real signature. A well-drafted development agreement contains both a present assignment and a work-for-hire clause as a belt-and-suspenders backstop. For the transactional side, see the IP transactions toolkit.

  • [ ] Sweep up founder and pre-incorporation code. Founders who wrote the first prototype before the company existed own that code personally until they assign it. Have every founder execute a formal assignment to the entity. Diligence in a financing or acquisition will find this gap, and it is far cheaper to fix now than under a signing deadline.

  • [ ] Identify the correct claimant. The claimant is the party that owns the copyright now — either the author or someone who obtained ownership by transfer. If ownership moved by assignment, the application needs a brief transfer statement ("By written assignment"). Name the entity that actually holds the rights, not a convenient affiliate.

  • [ ] Inventory third-party and open-source components. You do not own the libraries you pulled from a package registry, the snippets you copied from a forum, or the framework your app is built on. Those must be disclaimed in the limitation-of-claim field (Phase 3). Building that inventory is also where open-source license obligations surface — copyleft terms that could force disclosure of your own code, attribution requirements, and license incompatibilities. Do the clearance before you launch, not after; see the IP clearance toolkit and the component-by-component treatment in protectable assets in a mobile app.

Why this matters / traps. Naming the wrong claimant, or registering a codebase as if you authored every line when a third of it came from open-source packages, is not a harmless clerical slip. Under 17 U.S.C. § 411(b), a registration certificate can be challenged if it contains information the applicant knew was inaccurate and the inaccuracy, if known, would have caused the Office to refuse registration. The Supreme Court in Unicolors, Inc. v. H&M Hennes & Mauritz, L.P., 595 U.S. 178 (2022), read § 411(b) to require actual knowledge of the inaccuracy — a mistake of law or fact made in good faith does not invalidate the registration. That is reassuring, but it is not a license to be careless: an accused infringer will comb your application for overclaims, and a clean, accurate claimant-and-disclaimer story is worth far more than the hour it takes to get right.

Worked example — the contractor who owned the engine. Meridian Analytics hires a freelance ML engineer to build the inference core of its fraud-detection product. The statement of work says "all deliverables are works made for hire." Two years later, after a falling-out, the engineer licenses the same core to a competitor and claims she still owns it. Because ML code is a literary work and does not fall within any § 101 commissioned-work category, the "work made for hire" recital does nothing — and the SOW contained no assignment. Meridian's copyright in its flagship engine is contested at the worst possible moment. The fix would have been one sentence: a present assignment of all rights under § 204(a), signed. Meridian's registration, filed years earlier naming Meridian as claimant "by written agreement," now rests on an agreement that transferred nothing.

Phase 2 — Fix the version, the publication status, and the application type

Software is a moving target. The thing you register is a specific version, frozen in time, and getting the metadata right up front prevents a delaying inquiry from the examiner and preserves your remedies.

  • [ ] Identify the exact version. Register a named, numbered release — "RouteWeaver, Version 4.2" — not "our app, generally." Each version that adds new copyrightable authorship is a separate work with its own registration. You are photographing the codebase on a particular day.

  • [ ] Determine publication status. A computer program is "published" when copies are distributed, or offered for distribution to a group for further distribution, by sale, license, loan, lease, or rental to the public. This is deceptively tricky for software. Often only the object code is distributed (in a compiled binary or over a network), while the source never leaves the company — so the source frequently remains unpublished even though the product ships. SaaS delivered purely over the network raises hard publication questions the Office has never fully resolved; when in doubt, treat a shipped, generally available product as published and register each release individually.

  • [ ] Choose the application type. Use the Standard Application in the electronic system (eCO) for a single computer program by one owner. If you are registering multiple unpublished programs by the same author, the group registration of unpublished works (GRUW) option may let you cover up to ten works in one filing — but only if they are genuinely unpublished. Published versions generally each need their own application.

  • [ ] Calendar the § 412 deadline. Register before publication, or within three months of first publication, to keep statutory damages and fees on the table. Put the publication date on a calendar the day you ship. For an early-development codebase at real risk of pre-release leakage, consider preregistration (below).

  • [ ] Consider preregistration for high-risk, pre-release code. Software is one of the classes eligible for preregistration under 17 U.S.C. § 408(f) and 37 C.F.R. § 202.16 — the mechanism for works being prepared for commercial distribution that have a history of pre-release infringement in the industry. Preregistration is not a substitute for registration; you must still register within the statutory window after publication. But it lets you begin an infringement suit against someone who leaks or copies the code before you have finished and released it.

Why this matters / traps. The published/unpublished line quietly controls three things at once: the statutory-damages deadline, which group options are available, and the deposit mechanics. Misjudge it and you can blow the § 412 window or file the wrong deposit. The safe default for a commercial product is to treat each generally available release as published and to register it on its own.

Phase 3 — Complete the application and the limitation of claim

This is where you tell the Office exactly what you are and are not claiming. Precision here is your best defense against a § 411(b) challenge later.

  • [ ] Select "computer program" as the type of work. In eCO you will identify the work as a computer program; the underlying statutory category is still the literary work. The application draws on the § 409 contents requirements — title, author, claimant, year of creation, and (if published) date and nation of first publication.

  • [ ] Name authors and claimant; add a transfer statement. List each author and the nature of authorship. If the claimant obtained rights by assignment, add the short transfer statement (for example, "By written assignment"). If the work is a work made for hire, mark it as such and name the employer as author.

  • [ ] Check "computer program" in the Author Created field. Doing so also covers any screen displays the program generates if the same party owns both the code and the displays — you generally do not need a separate claim for the program's own generated screens. (Independently authored artwork, music, or third-party UI assets are a different story; see Phase 6.)

  • [ ] Complete the Limitation of Claim. This is the disclaimer field, and for software it is the heart of an honest application. Exclude:

    • preexisting material that was previously published;
    • preexisting material that was previously registered;
    • material in the public domain;
    • and any third-party material, including open-source components you do not own. Then affirmatively describe the new material covered by this claim (for example, "new and revised computer program code").

  • [ ] Use the "Note to Copyright Office" field to head off inquiries. If the deposit shows copyright notices spanning several years, or the version history is complicated, a short explanatory note ("Codebase developed 2021-2026; this claim covers Version 4.2 authorship added in 2026") can prevent the examiner from pausing your application to ask.

Why this matters / traps. A single registration can cover both new code and preexisting code only if the preexisting code was never published or registered and the same claimant owns both. The instant the preexisting material was published, previously registered, dedicated to the public domain, or owned by anyone else, it must be disclaimed. Registering a codebase that silently incorporates an MIT-licensed library as if you authored the whole thing is exactly the kind of overclaim that a defendant will wave in front of a judge — and, if you knew and it was material, exactly what § 411(b) is aimed at.

Phase 4 — Build the source-code deposit: the first-25-and-last-25 rule

The deposit is the part of software registration that has no analogue in registering a poem or a photograph, and it is where most of the craft lives. The default rule for a program that contains no trade secrets is deliberately partial, so that registration does not force you to publish your entire codebase.

  • [ ] Deposit the first 25 and last 25 pages of source code. For a program with an identifiable beginning, middle, and end, deposit the first 25 and last 25 pages of source code. If the program is 50 pages or fewer, deposit the entire source. If there is no discrete beginning/middle/end (some modular or generated codebases), deposit 50 representative pages.

  • [ ] Always include the page bearing the copyright notice, if the program carries one, and add the title and version to the first page of the deposit so the examiner can match it to the application.

  • [ ] Deposit source, not object, whenever you can. The Office strongly prefers source code, ideally submitted as a PDF. Object code triggers the Rule of Doubt (Phase 6) and forfeits the § 410(c) presumption for the material the examiner cannot read. Screenshots are not code and are not an acceptable substitute for a source or object deposit.

  • [ ] Treat scripting languages as source. For JavaScript, Python, Ruby, and similar interpreted or scripting languages, treat the script as the equivalent of source code and deposit the same number of pages. There is no separate "compiled" artifact to worry about, but the page rules are unchanged.

Why this matters / traps. Those fifty pages are a compromise engineered to give the examiner enough to confirm the presence of copyrightable original expression while keeping the bulk of a large codebase out of the public record. Do not overthink it: for most programs the first-25-and-last-25 rule is straightforward. But remember the consequence — once the registration issues, the deposit becomes public, and anyone can request to inspect the copy you filed. If those fifty pages contain your genuinely secret material, do not file them raw. Use the trade-secret options in Phase 5 instead.

Worked example — the 40-page utility. Priya builds "TideChart," a 40-page open-source-free tidal-prediction library she wants to register before publishing to a package manager. Because the whole program is under 50 pages, she deposits the entire source as a PDF, puts the title and version on the first page, includes the page carrying her (c) 2026 Priya Rao notice, and files a Standard Application listing herself as sole author and claimant. Total public exposure: the complete 40 pages — which she is comfortable with because she is about to open-source it anyway. Registration before publication preserves the full § 412 remedy set from day one.

Phase 5 — Protect trade secrets inside the deposit

Here is the mechanism that makes software registration safe for a proprietary product. If your source contains trade secrets, you do not have to choose between registration and secrecy. You must, however, follow the Office's redaction menu exactly, because the examiner enforces it strictly and will refuse a non-conforming deposit.

  • [ ] State in writing that the code contains trade secrets, then pick one of the approved deposit options:

    • (a) the first 10 and last 10 pages of source code, with nothing blocked out; or
    • (b) the first 25 and last 25 pages of source code with the trade-secret portions redacted, provided the redactions cover less than 50% of the deposited material; or
    • (c) the first 25 and last 25 pages of object code plus at least 10 consecutive pages of source code with no blocked-out portions; or
    • (d) for a program of fewer than 50 pages, the entire source or object code with trade-secret portions redacted, again keeping redactions under 50%; or
    • (e) where there is no discrete beginning/middle/end, 20 to 50 representative pages of source code with redactions under 50%.

  • [ ] Make sure the unredacted portions contain an appreciable amount of copyrightable expression. You cannot black out everything meaningful. The examiner has to be able to see enough genuine original code to confirm that a copyrightable work exists.

  • [ ] Include the portion bearing the copyright notice, if any, and keep the title/version identification on the first page.

Why this matters / traps. The redaction rules are a hard constraint, not a suggestion. Over-redact — block out 50% or more, or strip out so much that no appreciable expression remains — and the Office bounces the deposit, costing you weeks and, if you were racing the § 412 clock, potentially your statutory-damages window. The detailed guidance lives in the Compendium of U.S. Copyright Office Practices § 721 (3d ed. 2021) and the software deposit provisions at § 1509.1(C)(4); see also 37 C.F.R. § 202.20. For the substantive side — what actually qualifies as a trade secret and how the "reasonable measures" requirement of the DTSA and UTSA interacts with a public filing — see trade secret law and the standing up a trade secret protection program checklist. One point worth flagging to clients: filing an unredacted deposit of secret code can undercut the "reasonable measures to keep it secret" element of a later trade-secret claim, so the redaction options are not just a copyright nicety — they protect a parallel body of rights. Audit what is actually secret before you deposit; the trade-secret audit checklist is built for exactly that.

Worked example — registering around the crown jewels. Meridian's fraud engine is 900 pages of source, and its value is a proprietary feature-weighting routine that lives about 400 pages in. Meridian wants the copyright registration's litigation benefits but cannot expose the routine. It chooses option (b): it deposits the first 25 and last 25 pages of source, with the handful of lines implementing the secret weighting redacted — total redaction well under 50% of the fifty pages, and the rest showing plenty of original expression (data-pipeline code, error handling, module structure). Meridian writes a cover statement invoking the trade-secret option. The examiner registers the work; the public deposit reveals ordinary plumbing and nothing of the weighting routine. Meridian keeps both its copyright registration and its trade secret. Had it instead tried to redact 70% of every page, the deposit would have been refused.

Phase 6 — Versions, screen displays, object code, and special cases

Real codebases are messy. This phase handles the recurring wrinkles.

New releases as derivative works

Every meaningful new release is, in copyright terms, a derivative work built on the prior version, and 17 U.S.C. § 103(b) protects only the "material contributed by the author of such work," not the preexisting material.

  • [ ] Register a significant new version as a derivative work, claiming only the new and revised code and disclaiming the previously registered material in the limitation of claim. Keep clean diffs, commit history, and release notes as contemporaneous evidence of exactly what is new.
  • [ ] Deposit for a derivative version: deposit the first 25 and last 25 pages if the new material appears throughout the program, or any 50 pages containing the new or revised material if the new authorship is concentrated rather than spread across the codebase.
  • [ ] Do not over-claim the new version. A minor bug-fix release with no new copyrightable authorship generally does not warrant its own registration; a substantial feature rewrite does. For the doctrine on limiting a derivative claim to what you actually added — and the "thin copyright" and originality traps — see registering derivative works.

Worked example — the version treadmill. RouteWeaver 1.0 is registered in January. In June, the team ships 2.0 with a rewritten scheduling engine — thousands of new lines. Cardinal registers 2.0 as a derivative work, claiming "new and revised computer program code," disclaiming the 1.0 material by reference to the earlier registration number, and depositing 50 pages that include the new engine. Because 2.0's authorship is registered within three months of its own publication, the new engine gets full § 412 protection even though 1.0's window is long closed. The lesson: each release resets the clock for the authorship added in that release. Serious software owners register on a cadence, not once.

Screen displays and graphical user interfaces

  • [ ] Register screen displays with the program on one application when the same party owns both — checking the computer-program box captures the program-generated displays, and no separate claim is needed.
  • [ ] File separately when ownership differs — if the UI artwork was created by a different author or licensed from a third party, it needs its own treatment and must be disclaimed from the program claim.
  • [ ] Remember that interface and expression diverge. Copyright can protect the original artwork, icons, and audiovisual arrangement of a UI, but under Lotus v. Borland and § 102(b) it does not protect the method of operation embodied in a command structure. For UI look-and-feel that is really product design, design patents and trade dress may do more work; see protectable assets in a mobile app and intellectual property strategy for mobile apps.

Object code and the Rule of Doubt

  • [ ] Understand the Rule of Doubt before defaulting to an object-code deposit. When you deposit object code, the examiner cannot read machine language to confirm that copyrightable authorship exists, so the Office registers the claim under the Rule of Doubt — it accepts your assertion but withholds the § 410(c) presumption of validity for that material. See Compendium Ch. 600. You get a registration, but a weaker one for litigation purposes.
  • [ ] Deposit source whenever you can. The whole point of registering is often to walk into court with the validity presumption in your pocket. An object-code-only deposit forfeits exactly that advantage for the unreadable material. Reserve object-code deposits for the trade-secret option (c) above or genuine cases where source is unavailable.

Lost or unavailable source

  • [ ] Request special relief in writing if the source code for the version you are registering no longer exists. Explain the unavailability and, where possible, the overlap between the registered version and an available one. The Office has discretion to accept an alternative deposit under 37 C.F.R. § 202.20(d); make the case in a short cover letter.

HTML and markup

Why this matters / traps. The through-line of Phase 6 is claim only what you can prove and prefer the deposit that keeps your presumption. Object code buys convenience at the cost of the validity presumption. Derivative registrations buy protection for new work but only if you honestly disclaim the old. And the "one application covers the screens" shortcut evaporates the moment a second owner enters the picture.

Timing, filing mechanics, and expedited handling

  • [ ] File electronically through eCO. Electronic filing with a digital deposit is cheaper and faster than paper. Confirm the current fee at copyright.gov (the fee schedule is published in Circular 4); do not rely on a number you remember from last year.
  • [ ] Budget for ordinary processing. Routine examination can take anywhere from a couple of months to the better part of a year, depending on volume and whether the examiner has questions. That lag is precisely why you register before you need to litigate.
  • [ ] Use special handling (expedited processing) only when you qualify. The Office will expedite for a genuine, documented need tied to pending or prospective litigation, a customs matter, or a contract or publishing deadline. You submit a written request explaining the need, a certification that the facts are correct, and an additional fee. See Compendium § 623 and Circular 10. Special handling can compress the timeline to a handful of business days — invaluable when infringement surfaces and you have not yet registered.
  • [ ] Keep a registration record for each version — application, deposit-as-filed, certificate, and the diffs proving what was new. In litigation you will need to authenticate all of it.
  • [ ] Consult the master roadmap for the full mechanics across work types: the registering copyrights roadmap and resource library and the step-by-step registering a copyright with the U.S. Copyright Office guide.

Two statutory footnotes worth knowing. First, the § 408 registration deposit is distinct from the mandatory deposit obligation of 17 U.S.C. § 407, which requires the owner of copyright in a work published in the United States to deposit two complete copies of the best edition with the Library of Congress within three months of publication — a separate requirement that does not by itself affect the validity of your copyright but can draw a demand and penalties. Second, 17 U.S.C. § 117 gives the lawful owner of a copy of a computer program limited rights to make an adaptation or archival copy essential to using the program; it does not enlarge or shrink what you register, but it is part of the statutory backdrop against which software copyright operates.

When registration meets enforcement

Registration is a means, not an end. The reason you built a clean chain of title, disclaimed your open-source components, and filed a conforming deposit is so that when someone copies your code, you can act decisively.

Proving software infringement returns you to the doctrine in the first section. A plaintiff must show ownership of a valid copyright (where the § 410(c) presumption earns its keep) and copying of protected expression. Because direct evidence of copying is rare, plaintiffs typically prove access plus substantial similarity, and courts apply the abstraction-filtration-comparison method of Altai to strip out the unprotectable ideas, merger material, and scenes a faire before comparing the "golden nugget" of protectable expression. Literal copying of code is the easy case; non-literal copying of structure, sequence, and organization is where the filtration does the heavy lifting and where a precise, well-supported registration pays off.

When the infringement is online, the DMCA is the fastest lever — a takedown notice under 17 U.S.C. § 512(c) can pull an infringing repository or app listing quickly, and it does not require a completed registration (though registration remains the gateway to damages if you escalate to suit). For the enforcement toolkit, see copyright enforcement and the DMCA roadmap. For the strategic overview of the four regimes and how copyright fits alongside patent, trade secret, and contract in a software protection stack, see how the law protects software; for the plain-language answers clients ask most, copyright FAQs and the copyright law complete overview.

Common mistakes to avoid

  • "We always meant to register." Waiting until infringement appears forfeits the § 412 window and forces you to sit in the examination queue before you can even sue. Register each release near ship.
  • Naming the wrong claimant. Contractor or founder code that was never assigned means the entity you named does not actually own the copyright. Paper the assignments under § 204(a) first.
  • Registering open-source-laden code as wholly original. Failing to disclaim third-party and open-source components in the limitation of claim is an overclaim that a defendant will exploit under § 411(b).
  • Over-redacting the trade-secret deposit. Blocking out 50% or more, or stripping out all appreciable expression, draws a refusal. Stay under the threshold and leave real code visible.
  • Depositing object code by default. You forfeit the § 410(c) validity presumption for material the examiner cannot read. Prefer source.
  • Forgetting that each version is a separate work. A single 1.0 registration does not cover the new engine you shipped in 3.0. Register the authorship you add.
  • Confusing publication status. Guessing wrong on published-versus-unpublished can blow the statutory-damages deadline and dictate the wrong deposit and group option.
  • Treating screenshots as a code deposit. Images of a running program are not source or object code and will not satisfy the deposit requirement.

Primary authority

Related UpLaw Resources

Related Checklists

Related Guides

Related Articles

Related Toolkits

This checklist is general legal information from UpLaw (uplaw.us), not legal advice. Copyright Office deposit rules, fees, and practices change; confirm current requirements at copyright.gov and consult qualified counsel before filing or litigating.