Software: Patent vs. Copyright

Founders constantly ask which one they “need” for their software, as if it were a single choice. It isn’t. Patent and copyright are not competing options for the same asset — they cover different layers of the same product, and the smart move is knowing exactly where each one starts and stops.

What does copyright actually protect in software?

Copyright protects original works of authorship fixed in a tangible medium — and courts have long treated computer code as a literary work. That means the moment you write and save source code (or compile it into object code), copyright exists automatically. No filing, no fee, no examiner.

But copyright protects the expression, not the idea or function. This is the single most misunderstood point in software IP. The governing statute, 17 U.S.C. § 102(b), is blunt: copyright protection never extends to “any idea, procedure, process, system, method of operation, concept, principle, or discovery.” So copyright covers:

• The literal code you wrote — line by line, source and object.
• Non-literal elements like the structure, sequence, and organization of a program, to the extent they are creative rather than dictated by function.
• Creative UI text, graphics, and audio bundled with the software.

What it does not cover is the thing your users actually care about: what the program does. A competitor can run your app, understand its features, and write brand-new code that does the exact same job. That’s not infringement — it’s how the software industry works.

Where does copyright stop — the idea/expression line?

Two doctrines police the boundary between protectable expression and unprotectable function, and both matter enormously for code.

The first is the rule from Baker v. Selden (1879), the foundational Supreme Court case establishing that copyright protects the description of a system but not the system itself. Applied to software: your code is protected, but the method it implements is not.

The second is the merger doctrine. When there is only one way — or only a handful of ways — to express a particular function, expression is said to “merge” with the idea, and that expression loses copyright protection. In code, if a routine has to be written a certain way to work, copyright won’t lock it up.

The most important modern application is Google LLC v. Oracle America (2021). Google copied roughly 11,500 lines of declaring code from the Java SE APIs to build Android. The Supreme Court assumed (without deciding) that the code was copyrightable, then held that Google’s reuse was fair use — heavily weighing that the copied declarations were functional interface code that let programmers reuse skills they already had. The practical lesson: functional interface elements of software get thin, fragile copyright protection, and reuse of APIs to enable interoperability can be defensible. If your moat is “we own our API,” copyright is a weak place to stand.

For how these principles play out in real infringement disputes, browse our copyright case archive.

What does a software patent protect?

A patent protects the functional invention — the process, method, machine, or system — regardless of how the code is written. If copyright is about how you said it, a patent is about what it does. A utility patent gives you the right to exclude others from making, using, or selling the invention for 20 years from the filing date, and — critically — it protects you even against someone who independently invents the same thing. Copyright never does that.

Software inventions are typically claimed three ways: as a method (the steps performed), as a system (a computer configured to perform them), and as a non-transitory computer-readable medium storing the instructions. This lets a patent reach the algorithm or technique itself, not just one implementation of it.

The catch is that getting a software patent is genuinely hard and expensive. Expect years in prosecution at the USPTO and, all-in, commonly $10,000–$20,000+ in attorney and government fees for a single utility patent (small- and micro-entity discounts of 60% and 80% apply to many USPTO fees). And before any of that, your invention has to clear the eligibility gate — which is where most software applications die.

Why is software patent eligibility so hard — the Alice problem?

Patent eligibility is governed by 35 U.S.C. § 101, and abstract ideas are one of the judge-made exceptions to what can be patented. The controlling case is Alice Corp. v. CLS Bank International (2014), where the Supreme Court held that taking an abstract idea — there, a scheme for mitigating settlement risk — and simply implementing it on a generic computer is not patent-eligible.

Courts and USPTO examiners now apply the two-step Alice/Mayo framework:

1. Step one: Is the claim “directed to” a patent-ineligible concept — an abstract idea, law of nature, or natural phenomenon? Business methods, mathematical formulas, and “organizing human activity” often trip this wire.
2. Step two: If yes, does the claim add an “inventive concept” — something significantly more than the abstract idea itself? Reciting generic computer components doing generic computer things is not enough.

The dividing line, refined in later Federal Circuit cases like Enfish v. Microsoft and DDR Holdings v. Hotels.com, is whether the claim describes a concrete technical improvement to how a computer or network functions — a faster database structure, a better memory-management technique, a specific improvement to network security — versus merely automating a task a human could do. Inventions rooted in a real technical advance pass far more often than software that just digitizes an existing business process.

We go deep on how this eligibility bar applies to app-based inventions in can you patent an app?, and on the broader subject-matter question in what is patentable.

Is a trade secret the better option for software?

Often, yes — especially for back-end logic. A trade secret protects any valuable information you keep confidential, including source code, algorithms, model weights, and architecture. It costs nothing to “file,” can last forever, and sidesteps the entire Alice problem because there’s no eligibility test.

The trade-offs:

• Trade secret gives you no protection against reverse engineering or independent discovery — so it’s ideal for server-side code your users never see, and risky for logic that ships in a client binary.
• Protection depends on reasonable measures to keep the information secret: access controls, confidentiality agreements, and IT security. Lose the secrecy, lose the right.
• Patenting publishes the invention; you generally can’t do both for the same feature. Choosing a patent means choosing disclosure.

Because so much software value lives in code that never leaves your servers, trade secret protection plus tight controls is frequently the strongest single layer. Our companion guide, how to protect source code, covers the confidentiality mechanics, and patent vs. trade secret walks through the strategic fork in detail.

How do you layer patent, copyright, and trade secret together?

Real software products don’t pick one form of protection — they stack them so each covers a different attack:

• Copyright stops a competitor from copying your actual code. Register key releases with the Copyright Office early (see below), because copyright is your cheapest and most automatic layer.
• Trade secret protects the confidential internals — server-side algorithms, training data, architecture — that never ship to users.
• Patents protect the specific technical inventions worth the cost and disclosure, and are your only defense against a rival who independently builds the same functionality.
• Contracts and licenses — invention-assignment agreements, NDAs, and end-user license terms — knit the whole thing together and make sure your company actually owns what its engineers and contractors create.

A concrete example: a company might keep its ranking algorithm as a trade secret on the server, patent a genuinely novel data-compression technique, hold copyright in the entire codebase, and register copyright in each major release. Copying the code infringes copyright; cloning the compression method infringes the patent; a leak of the algorithm is misappropriation. One of these layers alone would leave large gaps.

Open-source components change this calculus, because the licenses you pull in carry obligations that can affect your own IP. We cover that interaction in open-source licensing for startups, and the full stack is mapped in our software IP pillar guide.

Should you register your software copyright?

Copyright exists automatically, so why register? Because registration is what gives copyright teeth:

• You cannot file an infringement lawsuit until the work is registered (or the application is acted on) — the rule the Supreme Court confirmed in Fourth Estate v. Wall-Street.com (2019).
• Registering before infringement begins, or within three months of publication, unlocks statutory damages (up to $150,000 per work for willful infringement) and attorney’s fees under 17 U.S.C. §§ 412, 504, and 505. Without early registration you’re limited to actual damages, which are notoriously hard to prove for code.
• Registration is cheap — commonly $45 to $65 online through the Copyright Office’s eCO system.

The wrinkle for software is that registration normally requires depositing part of your source code, which can expose trade secrets. The Copyright Office allows special relief — depositing redacted code (for example, the first and last 25 pages with confidential portions blacked out) — so you can register without publishing your crown jewels. Talk to counsel about the right deposit strategy before you file.

The bottom line

Patent versus copyright is the wrong frame for software. Copyright protects the code you wrote; a patent protects the invention behind it; a trade secret protects what you keep hidden — and a serious product usually needs all three, plus airtight ownership contracts. Copyright is automatic and cheap, so register your important releases. Patents are powerful but must survive the Alice eligibility gauntlet and real cost, so reserve them for genuine technical advances. Trade secrets carry the load for server-side logic. Map your product to these layers deliberately, and you close the gaps that catch companies who assumed one form of protection covered everything.

This guide is general education, not legal advice, and does not create an attorney-client relationship. Software IP strategy turns on your specific code, architecture, and business model, and patent eligibility is a fast-moving area of law — consult an attorney licensed in your jurisdiction before acting.