Legal Protection of Software: Copyrights, Patents, Trade Secrets, and Contracts

Summary: Proprietary software is often a company's single most valuable asset, yet no one legal doctrine fully protects it. This guide explains the four pillars of software protection—copyright, patent, trade secret, and contract law—in plain language, with worked examples that follow a fictional startup's code from the keyboard to the courtroom. It shows what each pillar covers, where each one fails, and how experienced counsel layer them so that one tool's blind spot is another tool's strength. It walks through the governing statutes and the landmark cases that shape them, and it explains who actually owns software and why a missing assignment can quietly sink a deal.

A Lock Is Not a Security System

Imagine a small company called Lumina Logistics. Four engineers spent two years building a routing engine they call RouteWise—software that takes a fleet of delivery trucks, a city's worth of addresses, and a tangle of traffic and weather data, and spits out delivery routes that shave fifteen percent off fuel costs. The math at the heart of RouteWise is genuinely clever. The code that runs it is forty thousand lines long. The interface that dispatchers use is clean and intuitive. There is a trove of customer performance data the system has been tuned on. And the whole thing is now the only reason customers pay Lumina anything at all.

Here is the question that keeps Lumina's founder awake at night: what stops a competitor from taking all of this?

It is a deceptively hard question, because "all of this" is not one thing. It is the clever math. It is the forty thousand lines of code. It is the look and feel of the dispatcher's screen. It is the way the modules fit together. It is the proprietary data. Each of those pieces is valuable in a different way, vulnerable in a different way, and—crucially—protected by a different body of law. Copyright is good at guarding the code as written but stops cold at the underlying idea. Patents can protect the clever method itself, but they are slow, expensive, and require the company to publish the invention to the world. Trade secret law protects whatever Lumina keeps confidential, but evaporates the instant the secret gets out. And contracts can impose almost any restriction the parties agree to—but only against the people who signed them.

Software protection, in other words, is not a single lock. It is a layered security system, and the art of it lies in choosing which layers to use and how to make them reinforce one another. Software is, simultaneously, a literary work (its code is expression), a functional tool (its code does things), a potential trade secret (its code can be kept confidential), and a bundle of contractual rights (its code is licensed on terms). No one doctrine covers all four faces. Counsel must select and combine protections the way an architect combines materials—each chosen for a particular strength, each compensating for the others' weaknesses. According to the U.S. Patent and Trademark Office, intellectual-property-intensive industries account for more than forty percent of U.S. economic output and support tens of millions of jobs, and software sits squarely at the center of that economy (USPTO, Intellectual Property and the U.S. Economy). For a company like Lumina, getting the protection strategy right is not a legal nicety. It is the difference between owning a defensible business and owning a head start that any well-funded rival can erase.

This article walks through the four pillars of software protection—copyright, patent, trade secret, and contract—and then shows how they fit together. We will follow RouteWise through each one. Along the way we will look at the statutes that govern the field and the landmark court decisions that interpret them, and we will translate the doctrine into the practical choices a business actually has to make. If you want the shorter, more general comparison of the IP regimes that underlie all of this, our companion piece on copyright vs. trademark vs. patent vs. trade secret is a good place to start. This guide goes deeper, and it goes deep specifically on software.

First, What Are We Even Protecting?

It is tempting to think "software" means "the code." The law's formal definition encourages that narrow view. 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). That captures source code—the human-readable instructions a programmer types—and object code, the machine-readable form the computer actually executes. But it barely touches what makes software commercially valuable.

In the real world, "software" is a sprawling thing. RouteWise is not just forty thousand lines of code. It includes the operating logic, yes, but also the architecture (how the pieces are organized and talk to one another), the data structures that hold information in memory, the application programming interfaces (APIs) that let other systems plug in, the user interface the dispatchers see, the user manuals, the technical specifications, the test suites, and the libraries the engineers reused. Much of the value lives in the non-literal elements—the structure, the design, the overall feel—rather than in any particular line of code.

This matters because of how theft actually happens. A departing engineer who copies the literal source code is committing a fairly obvious wrong. But a sophisticated competitor rarely does that. Instead, the competitor studies how RouteWise behaves, reverse-engineers its logic, mimics its interface, and rebuilds something that does the same thing in different words. When that happens, the narrow statutory definition of "computer program" is cold comfort. The code was never copied; the idea was taken. Whether that is unlawful depends entirely on which protection Lumina chose, and how well its lawyers built it.

The practical takeaway is that effective protection begins with decomposition—breaking software into its parts. Practitioners and courts routinely separate a program into its literal elements (source and object code) and its non-literal elements (structure, sequence, organization, data flow, interfaces, and the like). This is not an academic exercise. It is closer to triage: each part of the program gets routed to whichever legal tool protects it best. The literal code goes to copyright. The genuinely inventive method may go to patent—or to trade secret. The confidential algorithm and architecture go to trade secret. And anything the statutes leave exposed gets wrapped in a contract. Decomposition is the first move in every serious software-protection strategy, and it maps directly onto the legal test courts use to decide what copyright actually covers—a test we will reach shortly.

Pillar One: Copyright — Broad, Automatic, and Limited

Why copyright is the default

Copyright is the workhorse of software protection, and it earns that role by being almost effortless to obtain. The Copyright Act protects any "original work of authorship fixed in a tangible medium of expression" (17 U.S.C. § 102(a)). Software clears that bar the moment it is written. Source code and object code are both treated as "literary works," and protection attaches automatically the instant the file is saved to a drive. The Ninth Circuit confirmed that object code—even though no human reads it for pleasure—is copyrightable subject matter in Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510, 1519–20 (9th Cir. 1992).

There is no form to file, no fee to pay, and no notice to affix as a precondition of basic protection. Because the United States is a party to the Berne Convention, copyright arises without any formality whatsoever. When Lumina's engineers saved the first working build of RouteWise, the company already owned a copyright in the code—whether or not anyone realized it. That automatic, zero-cost coverage is why copyright is the floor beneath every software-protection plan.

What copyright actually gives you

Owning a copyright means owning a bundle of exclusive rights. For software, the relevant rights under 17 U.S.C. § 106 are the rights to reproduce the work, to prepare derivative works (new versions, translations, bug-fixed releases), to distribute it (by sale, license, or rental), and to publicly display or perform outputs the software generates. Each right stands on its own. Lumina can keep the right to make copies while licensing the right to distribute, or grant a customer the right to use one copy while reserving everything else. That divisibility is what makes software licensing possible in the first place; for how these rights play out in a license, see our guide on drafting software license agreements and our broader overview of software licensing agreements.

The hard part: separating expression from function

Here is where software copyright becomes genuinely difficult, and where most disputes are won or lost. Copyright protects expression, not ideas. A novel is expressive; a mousetrap is functional; software is both at once. The Copyright Act draws the line explicitly: copyright does not extend to "any idea, procedure, process, system, method of operation, concept, principle, or discovery," even when those things are embodied in a copyrightable work (17 U.S.C. § 102(b)). So copyright protects the way RouteWise's code is written, but not the method it implements. If a competitor independently writes its own code to perform the same routing logic, it has copied an idea, not an expression—and infringed no copyright at all.

The Federal Circuit captured the difficulty plainly, observing that deciding which features of a program copyright protects is "typically more difficult than determining more traditional copyrightable subject matter" (Oracle America, Inc. v. Google Inc., 750 F.3d 1339, 1354 (Fed. Cir. 2014)). To do that sorting, the federal courts have developed competing tests. A practitioner needs to know which one governs, because the same feature can be protected in one part of the country and unprotected in another.

The abstraction-filtration-comparison test. This is the dominant framework, set out by the Second Circuit in Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992). It works in three steps. First, abstraction: the court mentally peels the program apart into layers, from its most general purpose down through its architecture, its modules, its algorithms, and finally its literal code. The Tenth Circuit identified at least six such layers in Gates Rubber Co. v. Bando Chemical Industries, Ltd., 9 F.3d 823, 835 (10th Cir. 1993). Second, filtration: at each layer the court removes everything that copyright cannot protect—pure ideas, facts, elements dictated by efficiency (the merger doctrine, which holds that when there is only one practical way to express an idea, the expression "merges" with the idea and is not protected), standard programming conventions (scènes à faire), features forced by external constraints like hardware compatibility or industry standards, and anything in the public domain. Third, comparison: whatever original expression survives filtration is the protectable core, and the court compares it to the accused work to decide whether infringement occurred (Altai, 982 F.2d at 706–11). This test now controls in the Second, Fifth, Sixth, Ninth, Tenth, Eleventh, and Federal Circuits and has been borrowed by district courts elsewhere.

To make this concrete, suppose Lumina sues a rival, FleetFox, claiming FleetFox copied RouteWise's structure. A court applying Altai would strip away the parts of RouteWise that any competent programmer would have written the same way—the standard database calls, the obvious efficiency-driven choices, the open-source libraries everyone uses, the interface conventions dictated by the operating system. After all of that is filtered out, the court looks at what is left: the genuinely original architectural choices Lumina's engineers made when they had real options. If FleetFox copied those, Lumina wins. If the only similarities are in the filtered-out, unprotectable layers, Lumina loses—no matter how similar the two programs feel.

The method-of-operation test. The First Circuit took a blunter approach in Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807, 815–16 (1st Cir. 1995). It held that functional features of a program—its methods of operation, procedures, and systems—are categorically outside copyright, no matter how much creativity went into designing them. There, the menu command hierarchy of the Lotus 1-2-3 spreadsheet (the structure of commands like "Copy," "Print," "Quit") was held to be an uncopyrightable method of operation, even though the designers had made plenty of creative choices. The Supreme Court took the case but split four-to-four, leaving the First Circuit's rule standing without creating nationwide precedent (Lotus Development Corp. v. Borland International, Inc., 516 U.S. 233 (1996)).

The inherent-necessity test. The Third Circuit's older test, from Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc., 797 F.2d 1222, 1248 (3d Cir. 1986), runs in the opposite direction. It treats a program as having one "idea"—its overall purpose—and deems everything not strictly necessary to that purpose to be protectable expression. This approach protects far more, and has been widely criticized for sweeping functional elements into copyright. It is largely discredited, but it remains technically the law in the Third Circuit, which is one more reason the governing circuit matters so much.

The practical lesson is uncomfortable: the scope of Lumina's copyright depends partly on geography. A feature that is protected expression under Altai in New York may be an unprotectable method of operation under Lotus in Boston. Companies that operate nationwide cannot assume their copyright covers the same ground everywhere—and a defendant with a choice of forum will fight to litigate in the circuit whose test cuts in its favor.

The Google v. Oracle saga

No discussion of software copyright is complete without the decade-long fight between Oracle and Google over the Java APIs—a case that illustrates both the idea/expression problem and a critical escape hatch we will discuss in a moment. Google had reused roughly 11,500 lines of "declaring code" from the Java SE API so that developers could use familiar Java commands when writing Android apps. Oracle, which owned Java, sued. The Federal Circuit held that the API code was copyrightable expression (Oracle, 750 F.3d 1339). But when the dispute finally reached the Supreme Court, the Court sidestepped the copyrightability question entirely and decided the case on fair use instead, holding that Google's reuse of the interface—to let programmers deploy their existing skills on a new platform—was a fair use as a matter of law (Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021)). The decision is a reminder that even where software is copyrightable, the doctrine of fair use can leave room for competitors to reuse functional interface elements for the sake of interoperability—a recurring theme that surfaces again in trade secret and DMCA analysis below.

Registration: optional, but you will regret skipping it

Copyright protection is automatic, but the right to enforce it effectively is not. To sue for infringement of a U.S. work in federal court, the copyright must first be registered with the U.S. Copyright Office (17 U.S.C. § 411). And the timing of registration determines which remedies are available. If a software owner registers before the infringement begins, or within three months of first publication, it becomes eligible for statutory damages (up to $150,000 per work for willful infringement) and attorneys' fees (17 U.S.C. § 412)—remedies that are often far more valuable, and far easier to recover, than proving exactly how much money the infringement cost. Registration within five years of publication also creates a legal presumption that the copyright is valid (17 U.S.C. § 410(c)), and a recorded registration lets the owner ask U.S. Customs to block infringing imports.

The statutory-damages point is worth dwelling on, because it changes the economics of enforcement in a way that pure copyright theory obscures. In an ordinary infringement case the plaintiff must prove its actual damages or the infringer's profits—an expensive, fact-intensive exercise that can be hard to win even when the copying is blatant, because tracing lost sales to a specific act of infringement is genuinely difficult. Suppose FleetFox launches a copycat product and Lumina never registered. Lumina must first register, then sue, and can recover only its provable actual damages—which, for a young company, may be small and hard to quantify. Had Lumina registered RouteWise within three months of launch, it could instead elect statutory damages and force FleetFox to pay Lumina's legal bills, transforming the economics of the lawsuit. A competitor weighing whether to copy faces a very different risk calculus when the target holds timely registrations, and that credibility often produces a settlement—or a quiet cessation—without a trial. The catch is the timing requirement: the leverage exists only for companies that register early, as a matter of routine, rather than scrambling after they discover a problem. Building registration into the release process, rather than treating it as a litigation afterthought, is what converts copyright from a theoretical right into a practical deterrent. The few hundred dollars of timely registration is one of the highest-leverage moves in all of software protection; our step-by-step walkthrough on how to register a copyright with the U.S. Copyright Office and our deeper guide to copyright registration of computer programs cover the mechanics.

Registration does create one genuine tension, though. The Copyright Office requires the applicant to deposit at least part of the code, and deposits become part of the public record—exactly the opposite of what a company wants for code it is also trying to keep secret. The Office solves this with special deposit options for computer programs. An applicant may deposit the first and last twenty-five pages of source code with the trade-secret portions blacked out; or the first and last ten pages with nothing redacted; or a mix of object code and source code; and for short programs, the entire source with secrets blocked out. The redacted portions must be proportionately smaller than what remains, and the visible code must show an appreciable amount of original work. The mechanics are spelled out in the Copyright Office's Circular 61. These accommodations exist precisely because the Office understands that software developers live at the intersection of copyright and trade secret, and forcing them to choose would undermine both. For Lumina, this means it can register—and gain the statutory-damages leverage—while keeping its most sensitive code out of the public file.

The DMCA: a fence around the fence

Many software companies protect their products with technical measures—license keys, encryption, activation servers, digital rights management. The Digital Millennium Copyright Act backs those measures with legal force. The DMCA makes it unlawful to circumvent a technological protection measure that controls access to a copyrighted work (17 U.S.C. § 1201), to traffic in tools designed for circumvention, or to strip out or falsify copyright management information (17 U.S.C. § 1202). Violations carry civil liability (17 U.S.C. § 1203) and, in willful commercial cases, criminal penalties (17 U.S.C. § 1204).

The striking feature of the DMCA is that it can apply even where no copyright infringement occurs. In MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928, 943–55 (9th Cir. 2010), a company sold a bot that automated play in the game World of Warcraft by getting past Blizzard's anti-cheat system. The Ninth Circuit held that circumventing the access control violated the DMCA's anti-circumvention rule independently of whether the underlying use infringed Blizzard's copyright. For Lumina, that means a license-key system protecting RouteWise is not just a practical speed bump; cracking it is its own violation of federal law.

The DMCA is not absolute. It expressly permits circumvention for reverse engineering aimed at interoperability (17 U.S.C. § 1201(f)), for good-faith encryption research (§ 1201(g)), and for security testing (§ 1201(j)). The Librarian of Congress also grants renewable three-year exemptions for particular categories of works—the same triennial process that, for example, has at times exempted the unlocking of cell phones. And the DMCA's better-known notice-and-takedown system gives copyright owners a fast way to get infringing copies pulled from online platforms; our guide on how to file a DMCA takedown notice and respond to one walks through that process.

Copyright's blind spot

For all its breadth and convenience, copyright has one large blind spot: it does nothing against independent creation. If FleetFox never sees a line of RouteWise's code and writes its own routing engine from scratch that does exactly the same thing, copyright offers Lumina no remedy at all. Copyright forbids copying; it does not grant a monopoly on functionality. To cover that gap—to stop even an honest, independent competitor from practicing the same method—Lumina has to look to patents.

Pillar Two: Patent — Powerful, Expensive, and Public

A higher bar, a broader shield

If copyright protects how software is written, a patent protects what it does. A utility patent gives its owner the right to stop everyone else from making, using, selling, offering to sell, or importing the patented invention for the life of the patent (35 U.S.C. § 271). The defining feature—the one copyright lacks—is that a patent reaches independent creation. It does not matter whether the infringer ever heard of the patent holder; if they practice the claimed invention, they infringe. That makes patents the most powerful tool in the software arsenal, and also the slowest, costliest, and hardest to obtain. For RouteWise's routing algorithm, this is the crucial property: copyright would not stop a rival who independently wrote different code that performs the same novel optimization, but a patent would. Our overview on patent basics covers the fundamentals; what follows focuses on the software-specific wrinkles.

The eligibility gauntlet: Alice and its aftermath

A software patent must satisfy all the usual requirements: it must claim eligible subject matter, be useful, be novel, be nonobvious to a person of ordinary skill, and be described clearly enough to teach others how to build it (35 U.S.C. §§ 101–103, 112). For software, the eligibility requirement under § 101 has become the great obstacle, thanks to two Supreme Court decisions.

In Bilski v. Kappos, 561 U.S. 593 (2010), the Court refused to ban business-method patents outright but warned that abstract ideas are not patentable. Four years later, in Alice Corp. Pty. Ltd. v. CLS Bank International, 573 U.S. 208 (2014), it announced the two-step test that now governs every software patent. Step one asks whether the claim is "directed to" a judicial exception—an abstract idea, a law of nature, or a natural phenomenon. Step two asks whether the claim nevertheless adds an "inventive concept"—something "significantly more" than the abstract idea itself, considered both individually and as an ordered combination, rather than mere instructions to perform the idea on a generic computer.

The effect was seismic. Claims that did nothing more than take a known business practice and say "do it on a computer" began failing in droves. The Federal Circuit drove the point home in Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 (Fed. Cir. 2014), invalidating a patent on the idea of showing an advertisement before delivering online content. The USPTO's own data showed a steep jump in eligibility rejections for software applications after 2014, with allowance rates only partially recovering as applicants learned to draft around the new rule.

But Alice did not kill software patents—it disciplined them. The line that emerged is between claims that recite an abstract goal and claims that recite a concrete technological improvement. In DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014), the Federal Circuit upheld claims directed to a specific technical solution to a problem that only existed because of how the internet works, and in Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016), it held that a claim to a self-referential database structure was eligible at step one because it improved the functioning of the computer itself, rather than just using the computer as a tool. The USPTO has folded these distinctions into its own examination framework: under the agency's 2019 subject-matter-eligibility guidance, an examiner first asks whether a claim recites a judicial exception (Step 2A, Prong 1) and then whether the exception is "integrated into a practical application" (Step 2A, Prong 2) before reaching the inventive-concept inquiry of Step 2B (MPEP § 2106). That guidance does not override the courts—as the Federal Circuit noted in In re Rudy, 956 F.3d 1379 (Fed. Cir. 2020), agency guidance that diverges from precedent yields to the case law—but in practice it shapes how most software applications are examined.

For Lumina, this is the decisive question. A patent claim that says "a method of optimizing delivery routes using a computer" is dead on arrival—that is an abstract idea on a generic machine. But a claim describing the specific technical mechanism by which RouteWise restructures route calculations to reduce processing load and produce results that earlier systems could not, framed as an improvement to how the computing system operates, has a real chance. Whether software is patentable after Alice is less about the field and more about the drafting; we treat the strategy at length in patent eligibility after Alice. Before spending heavily on prosecution, it is also worth running a freedom-to-operate analysis to confirm the path is clear, and when the office issues the eligibility rejection it so often does, the response strategy matters—see responding to patent office actions.

Patent or trade secret? The choice you cannot unwind

This is also the point at which Lumina faces one of the most consequential strategic decisions in all of software IP: whether to patent the routing algorithm at all, or to keep it as a trade secret instead. For a given invention, the two are largely mutually exclusive—patenting requires publishing the invention, which destroys its secrecy, so Lumina generally cannot both patent the method and hold it as a secret.

The decision turns on a handful of factors. A patent's great advantage is precisely that it reaches independent creation: even a competitor who reinvents the same optimization on its own is excluded for the patent's twenty-year term. A trade secret offers no such protection—an independent inventor owes Lumina nothing—but it has compensating virtues: it is far cheaper, it never expires so long as secrecy holds, and it requires no public disclosure that teaches competitors how the method works. The choice therefore hinges on detectability and independent-invention risk. If RouteWise's routing advantage can be kept entirely server-side, never shipped to a customer's machine, and is hard for outsiders to reverse-engineer or independently derive, a trade secret may protect it indefinitely and for free. But if competitors are likely to reach the same method on their own, or if the advantage is observable in the product's behavior and could be reverse-engineered, the patent's power to exclude independent creators may justify its cost and its disclosure.

Many sophisticated software companies split the difference across a portfolio—patenting inventions that are detectable or independently derivable, while keeping as trade secrets the implementation details and optimizations competitors are unlikely to reproduce. For Lumina's single most important algorithm, this is a decision to make deliberately and early, because it cannot be unwound: once the patent application publishes, the secret is gone, and once the method ships in a reverse-engineerable form, the patent may be the only protection left.

The disclosure trade-off: do you have to hand over the code?

Patents come with a bargain: in exchange for the right to exclude, the inventor must teach the public how to practice the invention. The application must describe the invention well enough to enable a skilled person to make and use it, and must disclose the best mode of carrying it out (35 U.S.C. § 112(a)). To founders, this sounds alarming—does patenting RouteWise mean publishing its source code?

It does not. The USPTO routinely grants software patents claimed in functional terms, without any source code, as long as the application describes the steps clearly enough that a competent programmer could write the code from the description. The Federal Circuit blessed this practice in Fonar Corp. v. General Electric Co., 107 F.3d 1543, 1549 (Fed. Cir. 1997), reasoning that for software the best mode is generally the functional description rather than the literal code. Functional claiming is a powerful drafting tool—it can capture an inventive algorithm broadly without tying it to one hardware implementation—but it has to be handled with care: claims that recite a function without disclosing enough of the corresponding structure or algorithm risk rejection for lack of written description or indefiniteness, or being construed as narrow "means-plus-function" claims under § 112(f). So Lumina can patent the method RouteWise uses while keeping the actual implementation confidential. The catch is subtler: the published functional description may give competitors enough of a roadmap to design around the claims—to build something that achieves a similar result without literally infringing.

Patenting also buys some breathing room before anything becomes public. Applications are held in confidence for eighteen months after filing (35 U.S.C. § 122(a)), and an applicant who certifies that no foreign counterpart will be filed can keep the application secret until the patent actually issues. If the applicant abandons the application before the eighteen-month window closes, it stays permanently unpublished—useful for a company that files, learns something, and changes course. For inventions where the inventive contribution comes partly from a machine, the harder question of who counts as an inventor is taken up in our piece on AI-generated inventions, and for the licensing obligations that attach to standardized technologies, see our work on standard-essential patents and FRAND licensing.

The cost reality

None of this is cheap or fast. Drafting and prosecuting a software patent typically runs into the tens of thousands of dollars and takes years, and enforcement is in a category of its own. According to the American Intellectual Property Law Association's litigation survey, the median cost of patent litigation with several million dollars at stake runs well past two million dollars through trial. A patent is therefore a deliberate investment, justified when the invention is genuinely novel, the competitive threat is real, and the value of stopping even independent competitors outweighs the price. For a company that licenses rather than litigates its patents, our guide on how to license your patent covers valuation and terms.

Pillar Three: Trade Secret — The Quiet Default

The protection almost everyone actually relies on

Copyrights and patents get the headlines, but the form of protection most software companies lean on hardest is the quietest one. Nearly every software business keeps its source code confidential, and confidential source code that has commercial value precisely because it is not public is, by definition, a trade secret. There is no application, no fee, no government examination, and no public disclosure. If the information is not generally known, derives economic value from its secrecy, and is guarded with reasonable security, it is protected—automatically and indefinitely.

For Lumina, this is the default state of RouteWise's code. The moment the engineers stored it in a private repository that only the team could access, and so long as Lumina treats it as confidential, the source code is a trade secret. Our companion guides on building a trade secret protection program from scratch and the broader protection of trade secrets lay out how to operationalize this for a real company.

Two layers of law

Trade secrets enjoy protection at both the federal and state levels. Federally, the Defend Trade Secrets Act of 2016 (DTSA) amended the Economic Espionage Act (18 U.S.C. §§ 1831–1839) to create a civil cause of action for trade secret misappropriation, giving owners direct access to federal court. At the state level, every state protects trade secrets, and the great majority—forty-eight states plus the District of Columbia and the U.S. Virgin Islands—have adopted a version of the Uniform Trade Secrets Act (UTSA). New York is the notable holdout, relying on common law. Because the DTSA supplements rather than replaces state law, a plaintiff like Lumina can usually plead both at once, combining a federal forum with familiar state remedies—a real procedural advantage when the misappropriator and the evidence are scattered across state lines.

What counts—and why it fills copyright's gap

The DTSA and UTSA define a trade secret in substantially the same way: information that derives independent economic value from not being generally known or readily ascertainable by proper means, and that the owner protects with reasonable secrecy measures (compare UTSA § 1(4) with 18 U.S.C. § 1839(3)). For software, that net is wide. It can cover source code, algorithms, data structures, architecture documents, flow charts, programmer notes, build scripts, test protocols, configuration files, and even the negative know-how of which approaches the team tried and abandoned.

The most important thing about trade secret law is what it protects that copyright cannot. Recall that § 102(b) of the Copyright Act flatly excludes ideas, procedures, processes, systems, and methods of operation. Trade secret law has no such exclusion. The clever routing math at the heart of RouteWise—the very thing copyright refuses to protect because it is an "idea" or "method"—is fully protectable as a trade secret, provided Lumina keeps it confidential. This is why copyright and trade secret are natural partners: trade secret picks up exactly where copyright drops off.

The price of secrecy: "reasonable measures"

There is a catch, and it is an ongoing one. Trade secret protection is conditioned on the owner taking "reasonable measures" to keep the information secret, and courts assess that under the totality of the circumstances. A company that calls something a trade secret but leaves it lying around loses the protection. Reasonable measures for software typically combine four kinds of safeguards: physical security (controlled access to facilities and devices), technical security (encryption, permission-based code repositories, access logging, multifactor authentication), organizational measures (classifying and labeling confidential materials, enforcing need-to-know access), and contractual measures (confidentiality and invention-assignment agreements with every employee and contractor, NDAs with outside parties, and restrictive license terms for anyone who touches the code).

Consider how this plays out at Lumina. If the company stores RouteWise's source on a private repository with role-based permissions, requires every engineer to sign a confidentiality and invention-assignment agreement, marks its architecture documents "Confidential," and logs who accesses what, it has a strong claim that it took reasonable measures. If, instead, the founder emails the full codebase to a prospective investor with no NDA, posts revealing snippets to a public forum to ask for debugging help, and lets former contractors keep their repository access, a court may well find the secret was not reasonably protected—and once that finding is made, the protection is gone, even against a thief. Sound NDAs are the connective tissue here; see our guide on drafting enforceable non-disclosure agreements for technology transactions.

Modern work patterns make this harder. When engineers work from home on personal laptops, and code lives in cloud repositories reachable from anywhere, the "reasonable measures" question takes on new dimensions; we examine those pressures in trade secrets in the age of remote work and cloud computing. And because a single security breach can expose a company's entire crown-jewel codebase at once, incident response is now part of trade secret hygiene—a subject we address in cybersecurity incident response and IP protection.

Forever, but fragile

Trade secret protection has a remarkable upside: it can last forever. There is no expiration date, no renewal fee, no twenty-year clock. The Coca-Cola formula has been a trade secret for well over a century. RouteWise's algorithm could, in principle, be protected as long as Lumina exists and keeps it secret.

But that durability is brittle. The protection vanishes the instant the information becomes generally known—whether through the owner's own careless disclosure, a failure to maintain security, lawful reverse engineering, or independent development by someone else. Like copyright, and unlike a patent, trade secret law offers no protection against independent creation: if FleetFox writes its own routing engine without ever touching Lumina's secret, there is no misappropriation, even if the two engines are functionally identical. And reverse engineering—legitimately taking apart a lawfully obtained product to learn how it works—is generally a proper means of acquiring information, which means trade secret law alone will not stop a competitor who buys RouteWise and pulls it apart. (This is exactly the gap that contract law, discussed next, can close.)

What happens when someone steals it

When misappropriation does occur—say a departing Lumina engineer copies the source code and takes it to FleetFox—the remedies are substantial. Both the DTSA and the UTSA authorize injunctions, actual damages (including the defendant's unjust enrichment), reasonable royalties, exemplary damages up to twice the actual amount for willful and malicious misappropriation, and attorneys' fees for bad-faith or willful conduct. The DTSA adds a remedy with no state-law analog: in extraordinary circumstances, a court can issue an ex parte seizure order (18 U.S.C. § 1836(b)(2)), directing law enforcement to seize property to stop a stolen secret from being disseminated—before the defendant even knows a lawsuit exists. It is a powerful and tightly cabined tool, reserved for the cases where the secret would otherwise be gone before ordinary process could catch up.

Pillar Four: Contract — Building Walls Where the Statutes Stop

Raising the floor above the statutory baseline

The three statutory regimes set a baseline. Contracts raise it. Through careful drafting, a software owner can impose restrictions that go well beyond—and sometimes well around—what the IP statutes provide. This is the pillar with the most flexibility, because the parties can agree to almost anything, subject to the outer limits of contract law and public policy.

The single most important contractual move in software is the decision to license rather than sell. This sounds like a formality. It is not. Several of copyright's most significant limitations apply only to the owner of a copy. The first sale doctrine (17 U.S.C. § 109) lets the owner of a lawfully made copy resell it. The fair use provision (17 U.S.C. § 107) permits some reverse engineering. And § 117 lets the owner of a copy make essential-step and archival copies. But if the software is licensed, the user never becomes the owner of a copy—so the argument runs that these owner-only limitations do not apply.

The Ninth Circuit accepted exactly this reasoning in Vernor v. Autodesk, Inc., 621 F.3d 1102, 1110–13 (9th Cir. 2010). Autodesk distributed its software under a license that restricted transfer and use; the court held that this made the user a licensee, not an owner, so the user could not invoke the first sale doctrine to resell the software. And in Bowers v. Baystate Technologies, Inc., 320 F.3d 1317, 1326 (Fed. Cir. 2003), the Federal Circuit held that a license could contractually prohibit reverse engineering that fair use would otherwise allow. This is the move that closes the reverse-engineering gap in trade secret law: a competitor who buys RouteWise can lawfully reverse-engineer it under trade secret principles, but if the purchase came with a license forbidding reverse engineering, doing so is a breach of contract.

What a good software license accomplishes

A well-drafted software license grants narrow rights and imposes broad restrictions. Typical terms confine the customer to a specific number of users, a defined territory, and a permitted field of use; forbid copying, modification, and redistribution; bar reverse engineering and decompilation; and impose confidentiality obligations that survive the agreement. For the drafting details, our software license agreement review checklists and our deeper guide on drafting software license agreements are the practical companions to this section.

Increasingly, companies sidestep the whole problem architecturally by delivering software as a hosted service. The rise of software-as-a-service has quietly become one of the most effective protection strategies available—almost as a byproduct of the business model. If RouteWise runs on Lumina's servers and customers merely access it over the internet, the customer never receives a copy of the code at all. That single architectural choice forecloses an entire category of risk: there is no copy for the customer to resell (mooting the first-sale question), no copy to reverse-engineer (shrinking the trade-secret exposure that reverse engineering creates), and no copy to redistribute. The code's status as a trade secret is dramatically easier to maintain when it never leaves Lumina's infrastructure, and the "reasonable measures" inquiry becomes correspondingly simpler. The trade-off is that SaaS shifts the legal center of gravity toward different terrain—data security, service-level commitments, the handling of customer data—which is why a hosted-product agreement reads so differently from a traditional on-premise license. But from the narrow standpoint of protecting the code itself, delivering software as a service rather than a product is often the single most powerful protective decision a company can make, because it removes the copy on which every copying-based risk depends.

Covenants, conditions, and the difference that decides cases

Sophisticated licensors do something subtle and important: they structure the license so that a violation triggers not just a contract claim but a copyright (or patent) claim. The trick lies in distinguishing three kinds of terms. A covenant is a promise; breaking it gives rise to a breach-of-contract claim. A condition is a requirement attached to the grant of the license itself; breaking it means the license never applied to that conduct, so the user is now an infringer. A scope limitation marks the outer edge of what the license permits; stepping outside it is likewise infringement, not mere breach.

Why does this matter so much? Because infringement remedies are far more potent than contract remedies. Breach of a covenant yields ordinary contract damages. Exceeding a condition or scope limitation exposes the violator to copyright's arsenal—injunctions, statutory damages, attorneys' fees, impoundment. The Federal Circuit confirmed that license conditions are enforceable as copyright conditions, not just contract terms, in Jacobsen v. Katzer, 535 F.3d 1373, 1380–83 (Fed. Cir. 2008), a case about an open-source license whose terms the court treated as conditions on the copyright grant. For Lumina, the lesson is to draft the RouteWise license so that the restrictions it cares about most—no reverse engineering, no exceeding the user count, no redistribution—are written as conditions on the grant, not mere side promises.

This drafting discipline is doubly important when open-source components are involved, because the same condition-versus-covenant logic governs whether a company's failure to follow an open-source license is a mere breach or a copyright infringement. Modern software is assembled, not written from scratch, and most of it now contains open-source components; understanding how those licenses operate is a discipline in itself, covered in our overview of open source software. The interplay of open-source obligations with proprietary restrictions is a genuine minefield, mapped in open-source licensing landmines in enterprise software development and the practical open source compliance checklists.

Contract claims are not swallowed by copyright

One might worry that federal copyright law "preempts" these contract claims—that because the subject matter is copyrightable, only copyright law can govern. It does not. Section 301 of the Copyright Act preempts only state claims equivalent to copyright, and a contract claim is not equivalent: it requires proof of extra elements—an agreement, mutual assent, consideration—that copyright infringement does not, and it runs only against the counterparty rather than the world. The Seventh Circuit established this in ProCD, Inc. v. Zeidenberg, 86 F.3d 1447, 1454–55 (7th Cir. 1996), enforcing the restrictions in a shrinkwrap license as ordinary contract terms not preempted by copyright, and the Federal Circuit gathered the supporting authority in Bowers, 320 F.3d at 1324–25. So Lumina can enforce its license terms as contract, even where the underlying conduct also touches copyrightable material.

The one inherent limit of contract is the flip side of its power: it binds only the people who agree to it. A license stops Lumina's customers and partners from doing forbidden things, but it does nothing against a stranger who never signed. For protection that "runs against the world," Lumina still needs its statutory rights. That complementarity—contract against counterparties, statutes against everyone—is the whole point of layering.

Beyond the Four Pillars

Two further bodies of law often round out a software-protection strategy.

The Computer Fraud and Abuse Act (CFAA), 18 U.S.C. § 1030, forbids unauthorized access to protected computer systems and provides a civil remedy for certain violations (18 U.S.C. § 1030(g)). For a software owner, it offers a cause of action against someone who breaks into the systems that house source code, repositories, or confidential development environments. The reach of the CFAA turns on the contested phrase "exceeds authorized access," which the Supreme Court narrowed in Van Buren v. United States, 593 U.S. 374 (2021): the Act covers people who access areas of a system they were never allowed into, but not people who misuse information they were authorized to obtain. The Ninth Circuit then held that scraping data a website makes publicly available does not, without more, violate the CFAA (hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022)). Together these decisions reshaped how much legal weight a company's technical access controls actually carry, a subject we unpack in data scraping after hiQ v. LinkedIn.

Software owners can also draw on state-law tort claims—trespass to chattels (for unauthorized intrusion into computer systems), unjust enrichment, unfair competition, and tortious interference with contracts or business relationships. These are usually pleaded as supplements to the federal and contract claims, and their elements vary from state to state. They rarely carry a case on their own, but they can add pressure and reach conduct the headline claims miss.

Who Actually Owns the Software?

All of this protection is worthless if the company does not actually own the rights. Ownership is where many otherwise careful businesses stumble, and software is especially prone to the problem because it is so rarely built by a single hand.

Copyright ownership and the work-made-for-hire trap

Copyright vests automatically in the author—the person who creates the work (17 U.S.C. § 201(a)). For code written by an employee within the scope of employment, the work-made-for-hire doctrine treats the employer as the author from the start, with no assignment needed (17 U.S.C. § 101). So the code Lumina's salaried engineers write on the job belongs to Lumina automatically.

The danger lies with independent contractors. A specially commissioned work qualifies as a work made for hire only if it falls within one of nine narrow statutory categories and is covered by a signed agreement saying so—and "computer program" is not one of the nine categories. The Supreme Court explained the framework in Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989): unless the creator is a true common-law employee, the commissioning party gets work-for-hire status only by fitting the work into a statutory category (like an audiovisual contribution, a translation, or a compilation) and getting it in writing. For raw source code commissioned from a freelancer, none of that reliably applies.

The consequence catches companies off guard. Suppose Lumina, early on, hired a contractor to build RouteWise's first prototype and paid the invoices but never got a written assignment. Lumina may not own that code at all—the contractor may. Years later, when an acquirer's lawyers conduct due diligence before buying Lumina, they will find the gap, and the deal may stall while everyone scrambles to chase down a contractor for a signature that should have been obtained on day one. The fix is simple and should be universal: every contractor agreement should include a present assignment of all IP rights (a belt-and-suspenders clause that operates even when work-for-hire status fails), and every employee should sign a confidentiality and invention-assignment agreement at hire. Our guide on employee invention assignment agreements covers the drafting in depth.

Patent ownership

Patents follow a parallel logic, and they are arguably less forgiving, because no work-for-hire concept reaches patents at all. Under the America Invents Act, the applicant may be the inventor, an assignee, or someone with a sufficient proprietary interest (35 U.S.C. §§ 115, 118). In practice, employment agreements and contractor IP-assignment clauses route patent rights to the company. But absent a written assignment, patent rights default to the individual inventor—and a single un-assigned co-inventor can cloud title to an entire patent. Like the copyright contractor problem, this is a quiet risk that surfaces at the worst possible moment, usually in the middle of a financing or an acquisition. The cure is the same: get the assignments in writing, early, from everyone. For Lumina, the most elegant layered protection is worthless if the engineer who wrote the routing algorithm never assigned it.

Putting It Together: One Asset, Four Tools

No single pillar protects RouteWise. Each has a strength that covers another's weakness. Copyright is automatic and cheap but yields to independent creation. Patents stop independent creation but cost a fortune and require public disclosure. Trade secrets cost nothing and last forever but die the moment the secret escapes or someone reverse-engineers it. Contracts can forbid almost anything but bind only the people who sign. The following table lays the four side by side.

A decision framework, applied to RouteWise

The way to use that table is not to pick one column but to reason through five questions and let them point to a combination.

First, decompose the asset. Lumina separates RouteWise into its literal code, its non-literal architecture, its dispatcher interface, its underlying routing algorithm, and its proprietary training data. Each piece is a candidate for a different primary protection: copyright for the code and interface, patent or trade secret for the algorithm, trade secret for the data, contract over all of it.

Second, look at the business model. RouteWise is sold to enterprise customers under negotiated agreements, not shrinkwrapped to the public, and increasingly delivered as a hosted service. That favors a SaaS-and-license approach in which customers never receive the code, copy-based risks largely disappear, and the license can carry strong confidentiality and anti-reverse-engineering conditions. Software sold as shrinkwrap to the public faces a different risk profile, and the distribution model dictates which statutory limitations apply and how effectively contract can supplement them.

Third, name the real threat. Lumina's biggest fear is not a stranger downloading a pirate copy; it is a departing engineer walking out with the algorithm, or a well-funded rival independently building the same capability. The first threat points to trade secret and contract (confidentiality and invention-assignment agreements, access controls); the second points to patent, because only a patent stops an honest independent competitor.

Fourth, weigh enforcement. Copyright cases need access and substantial similarity; patent cases need claim construction and deep pockets; trade secret cases need proof that a protectable secret existed and was misappropriated; contract cases are the most straightforward but reach only signatories. Lumina, a young company, leans toward the protections that are cheaper to establish and enforce—copyright registration and trade secret—while reserving patenting for the one or two features genuinely worth the investment.

Fifth, layer deliberately. The strongest posture uses all four. Lumina registers the copyright in RouteWise within three months of launch to unlock statutory damages and fees, depositing redacted code to preserve secrecy. It files a carefully drafted patent application on the specific technical improvement at the heart of the routing engine, claiming it functionally so the source stays confidential. It maintains the full codebase and the algorithm as trade secrets behind access controls, classification, and signed agreements with everyone who touches them. And it wraps customer relationships in a license—ideally a SaaS arrangement—whose key restrictions are written as conditions on the grant, preserving the option to sue for infringement, not just breach. The result is a mesh: if any one protection fails in a given situation, another is positioned to catch the fall. For companies that want a structured assessment of where their own coverage is thin, the mobile-specific version of this analysis appears in our guide on protecting your mobile app.

The layers in action: three different copycats

To see why the layering matters, imagine three different threats to Lumina, each defeated by a different pillar.

In the first, FleetFox hires away a Lumina engineer who copies the source code on his way out and uses it to stand up a rival product quickly. Here the live protections are trade secret (the misappropriated source) and copyright (the literal copying), backed by the contract the engineer signed. Lumina can seek an injunction and damages under the DTSA, and its timely registration unlocks statutory damages for the copying. Patent is largely beside the point, because the wrong is the taking of the actual code, not the practice of the invention.

In the second, FleetFox never touches Lumina's code but, studying the published product, independently writes its own implementation of the same novel routing optimization. Now trade secret and copyright are powerless—there was no misappropriation and no copying—and only the patent stands in the way, because it alone reaches independent creation.

In the third, a licensed customer reverse-engineers the platform to extract its methods and build a competing tool. Here the contract does the work: the license's condition prohibiting reverse engineering, enforceable after Bowers, converts the customer's conduct into a breach (and, because it is a condition rather than a mere covenant, potentially an infringement), while the hosted-delivery model may have prevented the customer from obtaining a copy to reverse-engineer in the first place.

Three attacks, three different pillars—and a company relying on any one alone would have lost at least one of these confrontations. That is the entire argument for building all four locks into the same door.

The Ground Is Still Moving

The legal protection of software is not settled doctrine that sits still. Several developments are actively reshaping it.

Generative AI. As AI tools write more and more code, three questions are moving from theoretical to urgent: whether code generated largely by AI is copyrightable, who owns inventions an AI helps produce, and whether training AI on copyrighted software is itself infringement. The Copyright Office has taken the position that works generated entirely by AI without meaningful human creative control are not registrable (U.S. Copyright Office, Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence). The litigation over AI training data is unfolding now, and we track it in copyright infringement claims against generative AI and survey the broader terrain in artificial intelligence key legal issues.

Open source everywhere. Modern software is assembled, not written from scratch, and most of it now contains open-source components. Copyleft licenses such as the GPL can require a company to distribute its own source code downstream; permissive licenses such as MIT and Apache demand less but still carry conditions. A compliance slip can cost a company its license rights and expose it to infringement claims—the cautionary tales are collected in open-source licensing landmines.

Scraping and access controls. After Van Buren and hiQ, a company can no longer assume that a technical barrier translates into a legal one. Software firms that rely on access controls to fence off their platforms have to ask whether those controls actually create legal rights or merely practical friction; the analysis is in data scraping after hiQ v. LinkedIn.

Platform liability. Section 230 of the Communications Decency Act currently shields platforms from much liability for what their users do, including users' IP infringement. Proposals to reform it would change the calculus for any company that hosts third-party content, a shift we examine in Section 230 reform and platform liability.

A Short, Practical Word on Getting Started

If the four-pillar framework feels abstract, the on-ramp is concrete. A company that protects software well tends to do the same handful of things. It secures ownership at the front door, with work-for-hire and present-assignment language in every employee and contractor agreement before any code is written. It registers copyrights early—within three months of release—using redacted deposits so registration does not give away the secret. It marks and access-controls its confidential materials so the "reasonable measures" box is genuinely checked, not just claimed. It evaluates, honestly and before spending, whether any feature is inventive enough to survive Alice and valuable enough to justify a patent—and makes the patent-versus-trade-secret call deliberately, knowing it cannot be unwound. And it distributes through licenses, not sales, with the restrictions it cares about most written as conditions on the grant and confidentiality obligations that outlive the term. None of these steps is exotic. Together they convert a pile of code into a defensible asset.

Frequently Asked Questions

Is my software automatically protected, or do I have to file something? Copyright is automatic—it attaches the instant the code is fixed in a file, with no filing required. But to sue for infringement you must register with the Copyright Office (17 U.S.C. § 411), and to obtain the most valuable remedies—statutory damages and attorneys' fees—you must register before the infringement or within three months of publication (17 U.S.C. § 412). Trade secret protection is likewise automatic but conditioned on your taking reasonable measures to keep the information secret. Patents, by contrast, require a formal application and examination by the USPTO.

Should I patent my algorithm or keep it a trade secret? You generally cannot do both, because patenting publishes the invention and destroys its secrecy. Patent if the advantage is detectable in your product, easily reverse-engineered, or likely to be independently invented by a competitor—because only a patent stops independent creation. Keep it a trade secret if it can stay confidential (for example, running only on your servers) and is hard to reverse-engineer, in which case it can last indefinitely and cost nothing. Many companies do both across a portfolio: patent the detectable inventions, keep the hidden implementation details secret.

Does patenting my software mean I have to publish my source code? No. The USPTO routinely grants software patents claimed in functional terms, without source code, as long as the application describes the steps clearly enough for a skilled programmer to implement them (Fonar Corp. v. General Electric Co., 107 F.3d 1543 (Fed. Cir. 1997)). The application does publish a functional description of the invention, which competitors can study to design around your claims—but your literal source code stays confidential.

Can a competitor legally reverse-engineer my software? Often, yes—under trade secret law, reverse engineering a lawfully obtained product is generally a "proper means" of acquiring information. The way to stop it is by contract: a license that prohibits reverse engineering, enforced as a condition on the grant, converts the act into a breach (and potentially infringement), as the Federal Circuit held in Bowers v. Baystate Technologies, 320 F.3d 1317 (Fed. Cir. 2003). Delivering software as a hosted service, so the customer never receives a copy, removes the opportunity altogether.

We hired a freelancer to write our code. Do we own it? Maybe not. "Computer program" is not among the nine categories of specially commissioned works that can qualify as works made for hire, so a contractor's code is not automatically yours—even if you paid for it (Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989)). You own it only if the contractor signed a present assignment of IP rights. This gap is a frequent and avoidable problem that surfaces during acquisitions. Fix it with a written assignment in every contractor agreement.

Why register a copyright if protection is automatic? Because registration unlocks the leverage. It is a prerequisite to suing, and timely registration makes statutory damages (up to $150,000 per work) and attorneys' fees available without proving your actual losses—remedies that often make litigation economically credible and drive settlements. The cost is modest; the strategic value is large.

Conclusion

Software protection is not a single lock but a layered security system, and the layers exist because each one, alone, has a gap. Copyright is broad, automatic, and cheap, but it bows to independent creation and struggles to separate protected expression from unprotected function. Patents reach even independent competitors, but they are slow, costly, and public. Trade secrets cost nothing and can last forever, yet they shatter the moment secrecy fails or a product is lawfully reverse-engineered. Contracts can impose almost any restriction a business can imagine, but only on the people who agree to them. Copyright's blind spot is the patent's strength; the patent's disclosure cost is the trade secret's advantage; the trade secret's reverse-engineering vulnerability is the contract's to close; and the contract's narrow reach is exactly what the statutory rights, which run against the world, are for.

The skill—the part that separates a checklist from a strategy—is fitting these tools to a specific company's technology, business model, and threats, so that the pieces reinforce rather than merely coexist. That demands more than expertise in any one IP discipline. It demands an understanding of how the software is built, how it is sold, and where its value really lives. For a business whose advantage rests on proprietary code, that understanding is not a luxury. It is the foundation of the business itself.

For help designing a software-protection program tailored to your technology and your business model, contact our intellectual property and technology practice.

Related Articles

• Copyright vs. trademark vs. patent vs. trade secret: a practical guide
• Copyright registration of computer programs
• Patent eligibility after Alice: strategies for protecting software and business-method innovations
• Protection of trade secrets
• Building a trade secret protection program from scratch
• Drafting software license agreements: key terms and negotiation points
• Software licensing agreements
• Open source software
• Open-source licensing landmines in enterprise software development
• Employee invention assignment agreements
• Protecting your mobile app: a comprehensive IP strategy guide
• Data scraping after hiQ v. LinkedIn

Selected Authorities

17 U.S.C. §§ 101, 102(a)–(b), 106, 107, 109, 117, 201, 301, 410–412, 1201–1204; 35 U.S.C. §§ 101–103, 112, 115, 118, 122(a), 271; 18 U.S.C. §§ 1030, 1831–1839. Computer Associates Int'l v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992); Gates Rubber Co. v. Bando Chem. Indus., Ltd., 9 F.3d 823 (10th Cir. 1993); Lotus Dev. Corp. v. Borland Int'l, Inc., 49 F.3d 807 (1st Cir. 1995), aff'd by an equally divided Court, 516 U.S. 233 (1996); Whelan Assocs. v. Jaslow Dental Lab., Inc., 797 F.2d 1222 (3d Cir. 1986); Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992); Oracle America, Inc. v. Google Inc., 750 F.3d 1339 (Fed. Cir. 2014); Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021); Alice Corp. v. CLS Bank Int'l, 573 U.S. 208 (2014); Bilski v. Kappos, 561 U.S. 593 (2010); Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709 (Fed. Cir. 2014); DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014); Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016); In re Rudy, 956 F.3d 1379 (Fed. Cir. 2020); Fonar Corp. v. General Electric Co., 107 F.3d 1543 (Fed. Cir. 1997); MDY Indus., LLC v. Blizzard Entm't, Inc., 629 F.3d 928 (9th Cir. 2010); Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010); Bowers v. Baystate Techs., Inc., 320 F.3d 1317 (Fed. Cir. 2003); Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008); ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996); Van Buren v. United States, 593 U.S. 374 (2021); hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022); Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989). Defend Trade Secrets Act of 2016; Uniform Trade Secrets Act. U.S. Copyright Office, Circular 61; U.S. Copyright Office, Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence; USPTO, Intellectual Property and the U.S. Economy; MPEP § 2106.

This article is for general informational purposes only and does not constitute legal advice, nor does it create an attorney-client relationship. The law in this area is complex, varies by jurisdiction, and continues to evolve; the discussion here may not reflect the most recent developments. Readers should consult qualified intellectual-property counsel about their specific circumstances before acting.