Why an App Is a Stack, Not a Thing

Picture a founder—call her Maya—who has just shipped "Larkspur," a meditation app with a calming purple wordmark, hand-drawn breathing animations, an original ambient soundtrack, a clever algorithm that adapts session length to your heart-rate variability, and a back-end full of anonymized user data. Maya thinks of Larkspur as one thing: "my app." When a near-identical clone called "Larkspar" appears in the App Store three months later, she discovers the painful truth at the center of this entire field.

There is no single legal right called "app." Intellectual property law does not see Larkspur the way Maya does. It sees a stack—a layered assembly of distinct assets, each protected (or not protected) by a different body of law, each with its own requirements, its own duration, and its own enemies. The code is one asset. The purple wordmark is another. The breathing animations are a third. The soundtrack is a fourth. The adaptive algorithm is a fifth. The data is a sixth. The open-source library Maya pulled in to render charts is a seventh—and that one might actually impose obligations on her rather than rights for her.

The single most useful mental move in app IP is to stop asking "Is my app protected?" and start asking, layer by layer, "What is this layer, what does it embody, and which tool fits it?" Copyright protects original expression. Patents protect novel, non-obvious, useful invention. Trademark protects source-identifying brands. Trade secret protects valuable secret information. Contract—your terms of service, your developer agreements, your licenses—protects whatever the parties agree it protects. Get the mapping right and you can shut down a clone, license confidently, and survive due diligence in an acquisition. Get it wrong and you find yourself, like Maya, holding a cease-and-desist letter that asserts rights you never actually secured.

This guide is that map. We will walk the full stack—source and object code, the contested middle ground of APIs, the user interface and "look and feel," graphics and audio, the name and icon, novel functionality and algorithms, databases and data, trade secrets, and third-party and open-source components. Along the way we will deal with the two ownership questions that sink more app companies than any infringement ever does (work made for hire versus contractor assignment), and the constraints that Apple's and Google's developer agreements quietly impose on everything above. By the end you should be able to take any app—yours, a client's, an acquisition target's—and produce a clean inventory of what is protectable, by what tool, and in what priority. For a strategy-first companion that turns this inventory into an offensive and defensive plan, see Protecting Your Mobile App: A Comprehensive IP Strategy Guide; for the post-launch operational checklist, see Legal Considerations After Developing a Mobile App.

A note on tone before we dig in: this is a long article because apps are genuinely multi-layered, but you can read it as a stack. Each section stands on its own. Skip to the layer you care about, then come back for the ownership and app-store sections, which apply to everything.

The Four (Really Five) Tools, in Plain Language

Before the layers, the toolbox. Four IP regimes do most of the work, and a fifth—contract—glues them together.

Copyright protects original works of authorship fixed in a tangible medium—17 U.S.C. § 102(a). For apps, that means the code, the artwork, the sounds, the text, the videos. Protection is automatic the moment you fix the work; you do not need to register to own a copyright. But you generally must register before you can sue for infringement of a U.S. work, a rule the Supreme Court made strict in Fourth Estate Public Benefit Corp. v. Wall-Street.com, LLC, 586 U.S. 296 (2019), which held that registration occurs only when the Copyright Office acts on your application, not when you mail it. Copyright is cheap, broad, and long—but it protects only expression, never the underlying idea, system, or function. That last limitation, the idea/expression dichotomy of § 102(b), is the hinge on which most app copyright fights turn.

Patents protect new, useful, and non-obvious inventions—a process, machine, manufacture, or composition of matter—under 35 U.S.C. §§ 101, 102, and 103. Utility patents can cover genuinely novel app functionality, but software claims must survive the eligibility gauntlet of Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014). Design patents, a separate creature under 35 U.S.C. § 171, protect the ornamental appearance of an article of manufacture—and yes, that includes the look of a graphical user interface. Patents are expensive, slow, and territorial, and they expire (twenty years from filing for utility patents; fifteen years from grant for design patents).

Trademark protects words, logos, sounds, and other indicators that identify the source of goods or services and distinguish them from competitors—the Lanham Act, 15 U.S.C. § 1051 et seq. Trademark protects "Larkspur" the brand and the leaf-and-wave icon, not the app's functionality. Rights arise from use in commerce, strengthen with federal registration, and last indefinitely so long as you keep using and policing the mark. For the deep background, see Trademark Basics and the four-part series beginning with Trademark Overview: The Subject Matter of Trademark Law.

Trade secret protects information that derives independent economic value from being secret and that you take reasonable steps to keep secret—the federal Defend Trade Secrets Act, 18 U.S.C. § 1836, and the state-law Uniform Trade Secrets Act adopted in most states. It is the only regime with no fixed term: it lasts as long as the secret does. It is also the most fragile, because the moment the secret is lawfully reverse-engineered or independently developed, the protection evaporates. See Protection of Trade Secrets.

Contract—the fifth tool—is the connective tissue. Your end-user license agreement, terms of service, privacy policy, developer agreements, NDAs, and open-source licenses define, by private agreement, who may do what with your app and its data. Contract often protects what IP law cannot, and it is frequently the most enforceable weapon you have against scrapers, bot operators, and disloyal contractors.

A single app touches all five. The art of app IP is knowing which tool to reach for at each layer—and recognizing where two or three overlap on the same asset. The overarching comparison lives in Copyright vs. Trademark vs. Patent: Understanding the Three Pillars of IP and, with a software focus, in Legal Protection of Software: Copyrights, Patents, Trade Secrets, and Contracts.

Layer 1: Source Code and Object Code

The beating heart of every app is its code, and the foundational good news is that code is copyrightable. This was not always obvious. In the late 1970s, lawmakers genuinely debated whether a program—a functional set of instructions to a machine—could be a "work of authorship" at all. The National Commission on New Technological Uses of Copyrighted Works (CONTU) recommended in 1978 that programs be protected, and Congress amended the Copyright Act in 1980 to add the § 101 definition of a "computer program" and § 117's limited use rights. Then the Third Circuit settled the harder question in Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3d Cir. 1983): copyright protects not only human-readable source code (the C++, Swift, Kotlin, or JavaScript a developer types) but also machine-readable object code (the compiled binary the device executes), and it protects programs embedded in ROM. (A "compiler," for the layperson, is a translator that converts source into object code; "object code" is the executable result.)

So the literal text of Larkspur's code—every function, every class, every line—is protected by copyright the instant it is written and saved. If "Larkspar" copied those lines, that is straightforward infringement.

But two principles cabin this protection, and both matter enormously in practice.

First, the idea/expression dichotomy of 17 U.S.C. § 102(b): copyright protects the expression of an idea, never the idea, process, system, or method of operation itself. The Supreme Court's foundation here is Baker v. Selden, 101 U.S. 99 (1879)—a bookkeeping case—but its descendants govern code. A competitor who reads your app's functionality and writes wholly original code to achieve the same result has not infringed your copyright, because they took the unprotected idea, not your protected expression. This is why copyright cannot stop a clone that is built from scratch; it can only stop copying.

Second, courts filter out elements dictated by function, efficiency, or external constraints under the "abstraction-filtration-comparison" test crystallized in Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992). Code structures that are the only practical way to accomplish a task ("merger"), or that are standard programming practice ("scènes à faire"), or that are dictated by the hardware or by interoperability requirements, are filtered out before the court compares the works. What remains—the genuinely expressive, discretionary choices—is what copyright protects.

The practical upshot for Maya: copyright reliably protects against literal copying of Larkspur's code (a clone team that decompiled and reused her binaries) and against close non-literal copying of distinctive structure. It does not protect against a competitor who studies what Larkspur does and reimplements it cleanly. For that, she needs patents (if the functionality is novel) or trade secret (if she can keep the method hidden) or a head start in the market.

Registering the Code—and the Trade-Secret Problem

To sue, register. The Copyright Office has a registration class for computer programs, and the mechanics—including the all-important deposit rules—are covered in depth in Copyright Registration of Computer Programs. The single most important wrinkle for app developers is this: ordinary registration requires depositing identifying portions of the source code, which would publicly expose it. The Office anticipated exactly this tension. Under its long-standing "special relief" and rule-of-doubt practices (37 C.F.R. § 202.20), you can register while protecting confidential material—for example, by depositing the first and last 25 pages with trade-secret portions blacked out, or depositing object code under the rule of doubt. This lets you preserve a trade-secret claim in the very code you are registering for copyright. It is a rare and valuable instance of two IP regimes cooperating on the same asset, and it is a routine part of a well-run registration. For the broader registration walkthrough, see How to Register a Copyright with the US Copyright Office and Copyright Registration: A Comprehensive Guide.

Layer 2: The API Question—Google v. Oracle and Interoperability

Now to the layer that produced one of the most consequential software-copyright decisions of the century. An API—application programming interface—is, in plain terms, the set of names, calls, and conventions that lets one piece of software talk to another. Think of it as a published list of commands: a developer who wants Larkspur to read a step count types a particular method name with particular arguments, and the platform understands. The question that haunted the industry for a decade is whether that declaring code—the names and structure of the calls—is copyrightable, and if so, whether reusing it to build a compatible platform is infringement or fair use.

In Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021), the Supreme Court resolved the immediate fight. Google had copied roughly 11,500 lines of declaring code from the Java SE API to build the Android platform, so that the world's Java programmers could write Android apps using familiar calls. Oracle sued for billions. The Court assumed without deciding that the declaring code was copyrightable, then held that Google's reuse was fair use as a matter of law under 17 U.S.C. § 107. The reasoning is worth understanding because it shapes how every app developer should think about interoperability: the Court emphasized that the declaring code was inherently bound up with the uncopyrightable idea of organizing tasks and with the investment of the programmers who had learned the system; that Google took only what was needed to let those programmers carry their skills to a new, transformative platform (smartphones); and that enforcing Oracle's claim would let it hold the key to a lock it did not invent—the accumulated know-how of a developer community.

What does this mean for app builders? Three things.

First, reusing interface code for genuine interoperability has strong fair-use protection—but it is a fact-bound, four-factor analysis, not a safe harbor. Google v. Oracle turned on the transformative, interoperability purpose and the small, functional slice copied. Lift an entire creative codebase and call it "API reuse," and you will lose.

Second, the Court pointedly did not hold that APIs are uncopyrightable. It dodged that question. So a developer who wants certainty cannot assume declaring code is free for the taking; the safest posture is to reimplement interfaces independently or rely on documented, licensed, or open-standard APIs.

Third, the decision is a reminder that fair use is the great escape valve of software copyright, and it cuts both ways. If Larkspur exposes its own API for third-party integrations, Maya should understand that a competitor's interoperable reuse of her interface may well be defensible, even as her implementation code remains fully protected. For the broader fair-use map—including Andy Warhol Foundation v. Goldsmith, 598 U.S. 508 (2023), which tightened the "purpose and character" inquiry the year after Oracle—see Copyright Overview.

Layer 3: The User Interface and "Look and Feel"

Here is where Maya's frustration peaks, because the thing that feels most like Larkspur—its overall look and feel, the way it flows, the experience—is the hardest layer to protect. "Look and feel" is not a legal category; it is a marketing phrase that has to be cashed out into actual rights, and the cash-out is partial.

Start with what can be protected. The specific creative elements of an interface—the actual icons, the original illustrations, the particular arrangement of an animated splash screen, the unique copy and microcopy—are copyrightable expression like any other artwork or text, and we treat them in the next layer. The arrangement and selection of screen elements can earn thin "compilation" copyright if it reflects original, non-obvious authorial choices, though copyright will not reach the parts dictated by function or by platform conventions.

But the overall "feel"—the idea of a calming, swipe-driven meditation flow, the general scheme of progressive sessions, the basic metaphor of a breathing circle—is largely unprotectable by copyright. This is the lesson of the great GUI cases of the 1990s. In Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994), Apple tried to use copyright to stop Windows from adopting the desktop "look and feel" of the Macintosh—overlapping windows, icons, a trash can. The Ninth Circuit applied filtration, stripped out the elements that were licensed, functional, or standard, and found the remaining protectable expression too thin to support an infringement claim absent virtual identity. 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), went further and held a software menu command hierarchy an uncopyrightable "method of operation" under § 102(b). The through-line: copyright will not let you monopolize a way of operating a program, only your particular expressive rendering of it.

So how do you protect look and feel? Three other tools, used together.

Trade dress. The "total image and overall appearance" of a product can function as a trademark if it identifies source. App trade dress is real but demanding. Under Two Pesos, Inc. v. Taco Cabana, Inc., 505 U.S. 763 (1992), and Wal-Mart Stores, Inc. v. Samara Bros., 529 U.S. 205 (2000), product-design trade dress is never inherently distinctive—you must prove secondary meaning, i.e., that consumers have come to associate that look with you as the source. And under TrafFix Devices, Inc. v. Marketing Displays, Inc., 532 U.S. 23 (2001), the look must be non-functional: if a UI arrangement exists because it works better, not because it signals source, trade dress fails. App trade dress therefore protects, at best, a distinctive, well-known, non-functional visual identity (think the unmistakable, source-identifying look of a famous app) after it has accrued recognition—not the brand-new app's general layout. For the mechanics and limits, see The Intricate World of Trade Dress Protection: Balancing Brand Identity and Functional Design and the design-patent comparison in Design Patents vs. Trade Dress: Two Ways to Protect How a Product Looks.

Design patents on the GUI. This is the most underused tool in app IP, and it is powerful—see the next subsection.

Contract and the platforms. App-store policies prohibit copycats that create consumer confusion, and a well-pleaded trademark/trade-dress complaint to Apple or Google can get a clone pulled faster than any lawsuit. More on the platforms below.

Design Patents for Graphical User Interfaces

Most developers do not realize that the ornamental appearance of an on-screen interface can be patented. The USPTO has issued design patents on GUIs, icons, and animated screen transitions since the late 1990s, and they are claimed as "a display screen or portion thereof with a graphical user interface" depicted in the drawings (the dashed lines show unclaimed context; the solid lines show the claimed design). A design patent under 35 U.S.C. § 171 protects the way the interface looks, not what it does—which makes it a precise weapon against a clone that copies your distinctive visual design.

Why does this matter so much? Because of remedies. Design-patent infringement carries a unique statutory damages provision, 35 U.S.C. § 289, that lets the patent owner recover the infringer's total profit on the "article of manufacture" to which the design is applied. That provision drove the decade-long Apple Inc. v. Samsung Electronics Co. saga over smartphone designs. The Supreme Court, in Samsung Electronics Co. v. Apple Inc., 580 U.S. 53 (2016), held that the "article of manufacture" need not be the entire end product—it can be a component—and remanded to determine which article the design was applied to. The case is essential reading for anyone whose visual design is a competitive asset, and it underscores that design patents are not a footnote; they can be the highest-stakes claim in the stack.

Design patents are comparatively fast and cheap to obtain (no twenty-year prosecution slog), and the infringement test is the accessible "ordinary observer" standard of Egyptian Goddess, Inc. v. Swisa, Inc., 543 F.3d 665 (Fed. Cir. 2008) (en banc)—would an ordinary observer, familiar with the prior art, be deceived into thinking the accused design is the patented one? Note that the obviousness analysis for design patents was significantly reworked in LKQ Corp. v. GM Global Technology Operations LLC, 102 F.4th 1280 (Fed. Cir. 2024) (en banc), which discarded the rigid Rosen-Durling test in favor of the flexible Graham framework—raising the bar somewhat for getting and keeping design patents. For the deep dive, see The LKQ Decision: A Seismic Shift in Design Patent Obviousness Analysis, the head-to-head in Design Patents v. Utility Patents: Key Differences, and litigation specifics in Patent Litigation: Design Patents.

The strategic takeaway: if Larkspur's breathing-circle screen or its distinctive home layout is a genuine differentiator, Maya should file design patent applications on those screens early. Design patents are the closest thing app law offers to direct protection of the visual "feel," and they are routinely overlooked until a clone appears and it is too late to file (a U.S. design application must generally be filed within one year of first public disclosure under the § 102(b) on-sale/public-use bar).

Layer 4: Graphics, Sound, and Audiovisual Content

This layer is the friendliest to developers, because it is squarely within copyright's comfort zone. Larkspur's hand-drawn breathing animations are pictorial and graphic works. Its original ambient soundtrack is a sound recording (and the underlying composition is a separate musical work). The animated session sequences are audiovisual works. Each is independently copyrightable as soon as it is fixed, and each can be registered—sometimes the whole app's content can be captured efficiently in a small number of registrations.

A few practical points sharpen this layer.

Register the content, not just the code. It is common for developers to register only the program and forget the artwork and audio, which are often the elements a clone copies most blatantly because they are the most visible. A clone that lifts your icon set, your character art, or your jingle is committing textbook copyright infringement of those specific works. Register them.

Watch the music chain of title. If Larkspur licensed a track rather than commissioning original music, Maya needs a license that actually covers an app's reproduction and public-performance uses across platforms and territories—and she needs both the composition and the sound-recording rights, which are usually owned by different parties. App music is a frequent source of takedown trouble. The streaming-and-licensing ecosystem is its own world; for orientation, see Music Licensing in the Streaming Era: Mechanical Royalties, the MLC, and Direct Licensing Deals.

Stock and AI-generated assets carry strings. Stock-image and stock-audio licenses come with use restrictions (number of installs, redistribution limits, no-trademark-use clauses) that quietly cap how the asset may appear in a commercial app. And assets generated purely by AI raise an authorship problem: the Copyright Office's 2023 guidance and the courts (see Thaler v. Perlmutter, on the human-authorship requirement) hold that material generated without sufficient human creative control is not copyrightable. If a chunk of Larkspur's art was machine-generated, that chunk may be unprotectable—and Maya should disclaim it on her registration to avoid a defective application.

Characters can be protectable. If Larkspur features an original animated guide character with a distinctive name, appearance, and personality, that character may enjoy copyright protection (and the name and look may also function as a trademark). The interplay of these regimes around fictional characters is genuinely fun; see Intellectual Property Disputes Concerning Superheroes.

Layer 5: The App Name and the Icon—Trademark and Trade Dress

The name "Larkspur" and the leaf-and-wave icon are not copyright assets and not patent assets. They are trademarks—source identifiers—and they may be the single most valuable layer Maya owns, because while code can be reimplemented and even patents expire, a strong brand compounds in value indefinitely.

The core rules are familiar from general trademark law but have app-specific edges.

Distinctiveness determines strength. Marks fall on the Abercrombie spectrum from generic (never protectable) through descriptive (protectable only with secondary meaning) to suggestive, arbitrary, and fanciful (inherently distinctive and strongest). "Meditation App" is generic and worthless as a mark; "Larkspur" for a meditation app is arbitrary and strong. Founders constantly choose descriptive names ("QuickCalm," "SleepEasy") that are weak and crowded; an arbitrary or coined name is both legally stronger and easier to clear. For the full spectrum, see Trademark Overview: The Subject Matter of Trademark Law and When to Trademark Your Brand.

Clear before you commit. The most expensive mistake in app branding is building a brand on a name that infringes someone else's, or that is unregistrable. A clearance search—across the federal register, common-law uses, app-store listings, and domains—should precede the launch, not follow the cease-and-desist. The discipline is laid out in How to Conduct a Comprehensive Trademark Clearance Search, and clearance does double duty as a defense by negating willfulness, as explained in The Shield of Good Faith.

Register federally, in the right classes. Federal registration on the Principal Register confers nationwide constructive priority, a presumption of validity, the ® symbol, and access to powerful remedies—a far stronger position than the geographically limited common-law rights that arise from use alone (on which see Trademark Rights Under Common Law). An app typically registers in Class 9 (downloadable software) and/or Class 42 (software as a service), and often Class 41 or others depending on the content; picking classes correctly affects scope, cost, and conflicts, as explained in USPTO Trademark Classes: A Guide to the Nice Classification. The application mechanics are in How to File a Trademark Application with the USPTO. And the work does not stop at registration: marks must be maintained, renewed, and policed, or they lapse or go generic—see Maintaining Trademark Registrations.

The icon can be both trademark and copyright. A distinctive app icon that identifies source is a trademark; the original artwork in that icon is also copyrightable. Both can be registered, and both should be, because each gives a different remedy against a copycat icon. This overlap—one asset, two regimes—is the recurring theme of app IP.

Enforce on the platforms. When "Larkspar" appears with a confusingly similar name and icon, Maya's fastest remedy is often not a lawsuit but a trademark complaint through Apple's or Google's IP-infringement reporting channel, backed by her registration. Online brand enforcement, including app stores, domains, and marketplaces, is covered in Brand Protection Online: A Strategic Guide for Businesses.

Layer 6: Novel Functionality and Algorithms—Patents After Alice

Suppose Larkspur's real magic is its adaptive algorithm: a genuinely novel technical method for measuring heart-rate variability from a phone's camera and adjusting session pacing in real time. Copyright will not protect the method (only the code expressing it). Trade secret might (if Maya can keep it hidden—see Layer 8). The remaining question is whether she can patent it.

She can try, but she must navigate the most treacherous terrain in software law: patent-eligible subject matter under 35 U.S.C. § 101 after Alice. In Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), the Supreme Court applied the two-step framework from Mayo Collaborative Services v. Prometheus Laboratories, Inc., 566 U.S. 66 (2012): (1) is the claim directed to a patent-ineligible concept—an abstract idea, law of nature, or natural phenomenon? and if so, (2) does it contain an inventive concept—an element or combination that transforms the claim into "significantly more" than the ineligible concept itself? A claim that merely takes an abstract idea (say, "adjusting an activity based on a measurement") and says "do it on a computer" fails. This is why the USPTO routinely rejects software and app claims as abstract, and why a great many issued software patents were later invalidated.

But Alice did not kill software patents—it disciplined them. The Federal Circuit has built a body of guideposts showing what survives:

  • Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016): claims directed to a specific improvement in the way computers operate—there, a self-referential database structure—are not abstract at step one.
  • McRO, Inc. v. Bandai Namco Games America Inc., 837 F.3d 1299 (Fed. Cir. 2016): a claim reciting specific rules that improve a technological process (automated lip-sync animation) is eligible.
  • BASCOM Global Internet Services, Inc. v. AT&T Mobility LLC, 827 F.3d 1341 (Fed. Cir. 2016): even if a claim is directed to an abstract idea, a non-conventional, inventive arrangement of known components can supply the inventive concept at step two.
  • Berkheimer v. HP Inc., 881 F.3d 1360 (Fed. Cir. 2018): whether claim elements are "well-understood, routine, and conventional" is a question of fact, which makes § 101 harder to resolve on the pleadings and gives patentees a path past early dismissal.

The drafting lesson is concrete: frame the invention as a technical improvement to a technical system, anchor it in a detailed specification that explains the problem and the engineering solution, and claim specific, non-generic steps rather than results. Larkspur's camera-based HRV method, drafted as a specific signal-processing improvement that solves a known measurement problem, has a real shot; drafted as "monitor a user and adjust an activity," it is dead on arrival. The USPTO's 2019 Patent Eligibility Guidance and its 2024 update addressing AI-assisted inventions provide the examiner-facing framework. Congress has repeatedly floated § 101 reform (the Patent Eligibility Restoration Act), but as of 2026 Alice remains the law. For the full strategy, including claim architecture and the trade-secret alternative, see Patent Eligibility After Alice: Strategies for Protecting Software and Business Method Innovations. And before relying on any patent, confirm freedom to operate against others' patents, as outlined in Conducting Freedom-to-Operate Analysis for New Products.

One more reality check: utility patents are slow (often two to four years to grant) and expensive (frequently tens of thousands of dollars across prosecution). For a fast-moving app, the patent may issue after the feature is obsolete. That is precisely why many app companies protect functionality through trade secret and speed-to-market instead—and why the choice among patent, trade secret, and "just ship it" is a business decision as much as a legal one.

Layer 7: Databases, Data, and User-Generated Content

Larkspur sits on a back-end full of data: the content Maya created, the content her users create, and the aggregated, anonymized usage data that may be the company's most valuable long-term asset. Each kind of data has a different protection profile, and the law here is genuinely tricky.

Facts are not copyrightable. Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340 (1991), is the bedrock rule: facts—names, numbers, measurements—are not original to anyone and cannot be copyrighted, no matter how much effort ("sweat of the brow") went into collecting them. So Larkspur's raw user metrics, as facts, are not protected by copyright.

But original selection and arrangement can be. Feist preserves "compilation" copyright in the original selection, coordination, and arrangement of a database. The protection is "thin"—it does not stop a competitor from independently gathering the same facts—but it does stop wholesale copying of your particular curated structure.

Contract is the real database protection. Because copyright is thin and the U.S. has no EU-style sui generis database right, the workhorse for protecting data is contract—your terms of service. A well-drafted TOS can prohibit scraping, bulk extraction, automated access, and competitive reuse, and breach of those terms is enforceable. This is the lesson of the data-access wars; the contours of what contract, copyright, and computer-fraud law can and cannot do against scrapers are mapped in Data Scraping After hiQ v. LinkedIn: Copyright, Contract, and Computer Fraud Claims.

The CFAA backstop. The Computer Fraud and Abuse Act, 18 U.S.C. § 1030, provides a federal claim against unauthorized access to a protected computer—but the Supreme Court narrowed it in Van Buren v. United States, 593 U.S. 374 (2021), holding that the statute reaches those who access areas of a system they are not entitled to access at all, not those who merely misuse access they legitimately have. After Van Buren and hiQ, suing a scraper of publicly available data under the CFAA is much harder; the stronger play is breach of contract (TOS) plus, where measures are circumvented, the DMCA. This is exactly the strategy that succeeded in the bot-scalping litigation discussed below.

User-generated content needs a license, not ownership. If users post content into Larkspur (journal entries, audio, shared playlists), they own the copyright in what they create. Maya does not need to own it—she needs a license. The TOS should grant the platform a broad, royalty-free, sublicensable license to host, display, reproduce, and adapt user content as needed to operate and promote the service, plus representations that the user has the rights they are uploading. Getting this wrong means either operating without permission (infringement exposure) or overreaching in a way that triggers user backlash and, increasingly, regulatory attention. The platform's exposure for infringing UGC is in turn managed through the DMCA safe harbor.

The DMCA § 512 safe harbor. If users can upload content, Larkspur is potentially liable for their infringements unless it qualifies for the § 512(c) hosting safe harbor: designate a registered agent with the Copyright Office, adopt and reasonably implement a repeat-infringer policy, respond to takedown notices, and avoid red-flag knowledge and financial benefit coupled with the right to control. This is non-negotiable architecture for any app with user uploads; the full mechanics are in Digital Millennium Copyright Act Safe Harbors for Online Service Providers and the notice procedure in How to File a DMCA Takedown Notice and Respond to One. (The platform-liability landscape beyond copyright—Section 230 and its IP carve-out—is treated in Section 230 Reform and Platform Liability for User-Generated IP Infringement.)

A final, crucial caveat: the personal data in Larkspur's back-end is governed not by IP law but by privacy law—CCPA/CPRA, state comprehensive statutes, GDPR for global users, COPPA if children use the app, and platform data-safety rules. Protecting data as an asset (IP/contract) and protecting data as a liability (privacy/security) are different projects that must be coordinated. The privacy side is covered in Legal Issues for Mobile Applications: Privacy and Data Minimization and Avoiding the Over-Retention of Personal Information.

Layer 8: Trade Secrets—Protecting What You Do Not Disclose

Some of Larkspur's most valuable assets are best protected by not telling anyone how they work. The adaptive algorithm, the server-side ranking logic, the model weights, the proprietary content pipeline, the customer lists—each may qualify as a trade secret under the Defend Trade Secrets Act, 18 U.S.C. § 1836, and state UTSA law, provided it (a) derives independent economic value from being secret and (b) is the subject of reasonable measures to keep it secret.

That second requirement is where most trade-secret claims live or die. "Reasonable measures" is a factual standard, and a court will ask what you actually did: Were access controls in place? Were employees and contractors under NDAs and confidentiality obligations? Was the secret marked and segregated? Was it kept server-side rather than shipped to the device? That last point is uniquely important for apps. Anything that runs in the client—on the user's phone—can be decompiled, inspected, and reverse-engineered, and reverse engineering is a lawful way to destroy a trade secret. Therefore the cardinal rule of app trade-secret protection is: keep the secret on the server. Larkspur's adaptive algorithm should run in the cloud and return only results to the device; if it runs locally, it is effectively published to any determined competitor.

Building the program—policies, agreements, technical controls, and an incident response plan—is its own discipline, walked through in Building a Trade Secret Protection Program from Scratch and, for the distributed-team reality, Trade Secrets in the Age of Remote Work and Cloud Computing. The contractual backbone—the NDAs that make confidentiality enforceable—is covered in Drafting Enforceable Non-Disclosure Agreements for Technology Transactions.

The strategic interplay with patents deserves a sentence. Patents and trade secrets are mutually exclusive on the same information: a patent publishes the invention in exchange for a time-limited monopoly; a trade secret keeps it hidden indefinitely but offers no protection against independent discovery. For a method that is hard to reverse-engineer (server-side, opaque from the outside), trade secret may be the better deal—no twenty-year clock, no Alice eligibility fight, no public disclosure handing competitors a blueprint. For a method that is easy to reverse-engineer once shipped, the patent (if eligible) is the safer bet because it protects even against independent reinvention. Choosing well is the heart of Legal Protection of Software: Copyrights, Patents, Trade Secrets, and Contracts.

Layer 9: Third-Party and Open-Source Components

Now the layer that imposes obligations on Maya rather than rights for her—and the one most likely to blow up an acquisition. Virtually no modern app is built entirely from original code. Larkspur incorporates open-source libraries, SDKs, fonts, frameworks, and APIs, each carrying a license whose terms flow through to Maya's app whether she read them or not.

Open-source licenses are enforceable copyright licenses with conditions. This is not boilerplate folklore; it is law. In Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), the Federal Circuit held that the conditions in an open-source license (there, the Artistic License) are enforceable copyright conditions, so that violating them can constitute copyright infringement, not merely breach of contract—exposing the violator to injunctions and statutory damages. Ignore an open-source license and you may be infringing.

The licenses divide into families with very different consequences:

  • Permissive licenses (MIT, BSD, Apache 2.0) ask little—usually attribution and a copy of the license, with Apache 2.0 adding an express patent grant. These are generally safe for commercial apps.
  • Strong copyleft licenses (GPL, and especially AGPL for networked software) require that derivative works—and, under AGPL, even software offered over a network—be distributed under the same license, source code and all. Embed GPL code in the wrong way and you may be obligated to open-source your proprietary app. This is the "viral" reciprocity that founders dread, and it is real.
  • Weak copyleft (LGPL, MPL) sits in between, generally requiring you to share modifications to the licensed component but not your whole application.

The danger for apps is acute because the boundary of a "derivative work" in software is genuinely uncertain, and because the distribution model (shipping a binary to app stores) can trigger obligations that a pure SaaS model might not. The compliance discipline—maintaining a software bill of materials (SBOM), tracking every component and license, honoring attribution, and segregating copyleft code—is essential and is the subject of Open Source Licensing Landmines in Enterprise Software Development, Open Source Software: Licenses, Compliance, and Risk, and the practical Open Source Compliance Checklists: The Complete Collection.

Two more component traps: SDKs and analytics libraries often carry their own data-collection behaviors that create privacy liability for Maya even though she did not write the code, and fonts and asset packs carry license restrictions that limit embedding and redistribution. The single best habit is to maintain a living inventory of every third-party component, its license, and its obligations—because in any acquisition or financing, due-diligence counsel will ask for exactly that, and "I don't know what's in it" is the answer that kills deals.

The Two Ownership Questions That Sink Companies

Everything above assumes Maya actually owns the layers she is protecting. Far too often, she does not—and the gap is invisible until a financing or acquisition surfaces it. Two doctrines drive almost every app ownership failure.

Work Made for Hire: Employees Yes, Contractors Usually No

Under 17 U.S.C. § 201(b), the author—and thus the owner—of a work made for hire is the employer, not the individual who created it. So when Larkspur's full-time employees write code on the job, the company owns the copyright automatically. Simple.

The trap is contractors and freelancers. A work created by an independent contractor is not a work made for hire unless it both (1) falls within one of the nine narrow statutory categories in § 101 (e.g., a contribution to a collective work, an audiovisual work, a compilation) and (2) is the subject of a signed written agreement saying so. The Supreme Court drew the employee/contractor line in Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), using common-law agency factors—and most independent app developers fall on the contractor side. The brutal consequence: absent a proper written assignment, the contractor who wrote your code may own the copyright in it. Your company has, at best, an implied non-exclusive license—not ownership, not the right to register in its own name, not the ability to stop the contractor from reusing the work for a competitor.

The fix is simple and must be done before the work, not after: every contractor agreement must contain a present-tense assignment of all IP ("Contractor hereby assigns…"), backstopped by work-made-for-hire language and a separate present assignment for anything that does not qualify as WMFH. A promise to assign "in the future" is weaker than a present assignment; in patent law especially, "agree to assign" can fail to transfer title automatically (the lesson of the Stanford v. Roche line). Get a clean, present, written assignment from every contributor—founders included.

Employee Inventions and the Assignment Agreement

For patentable inventions, the default is even less founder-friendly: in the United States, an invention belongs to the inventor unless assigned, even when created on the job, absent an agreement or a narrow "hired-to-invent"/shop-right doctrine. Every employee and contractor who might invent should sign a Proprietary Information and Inventions Assignment Agreement (PIIA) with a present assignment of inventions—subject to state carve-outs (California Labor Code § 2870, and similar statutes in Washington, Minnesota, Illinois, and elsewhere) that exempt inventions developed entirely on the employee's own time without company resources. Drafting these to be enforceable across jurisdictions is its own craft; see Employee Invention Assignment Agreements: Drafting for Enforceability Across Jurisdictions. The startup-document context, including the founder IP assignment and the PIIA as table-stakes documents, is in Popular Legal Documents for Startups.

The practical rule that prevents nearly all of this pain: no one touches Larkspur's code, art, or designs without first signing an agreement that presently assigns everything they create to the company. Founders are the most-skipped signatories and the most dangerous gap, because a co-founder who leaves owning a slice of the app's copyright can hold the company hostage.

The Layer Above Everything: App-Store Developer Agreements

Maya can perfect every layer below and still be constrained by the contracts she clicks through to distribute. The Apple Developer Program License Agreement and the Google Play Developer Distribution Agreement are binding contracts that govern—and limit—what she can do, and they sit above the entire stack.

Several points matter for IP specifically. First, the platforms reserve broad rights to remove apps that infringe third-party IP or violate policy, and their IP-complaint processes are often the fastest, cheapest enforcement mechanism available to a brand owner against a clone—file a substantiated trademark or copyright complaint and the offending app can disappear in days. Second, the agreements impose content and metadata rules (no misleading names or icons, no impersonation) that effectively give you a quasi-trademark remedy without litigation. Third, they constrain monetization and in-app purchase mechanics in ways that interact with your business model—an area reshaped by the antitrust litigation in Epic Games, Inc. v. Apple Inc. and ongoing regulatory pressure, with the practical fallout summarized in Legal Considerations After Developing a Mobile App. Fourth, by distributing through the stores, Maya grants the platforms certain licenses to display her marks and content for store operation—licenses she should read so she is not surprised.

The point is not that the developer agreements are unfair; it is that they are real contracts forming the outermost layer of the stack, and a developer who treats them as unreadable boilerplate is delegating IP-relevant decisions to terms she has not read.

A Worked Inventory: Larkspur, Layer by Layer

Let us put the whole map to work. Here is how Maya should inventory and protect Larkspur, in priority order—an exercise any developer can repeat for their own app.

The brand comes first because it is foundational and time-sensitive: clear "Larkspur" and the icon, then file federal trademark applications in the appropriate Nice classes (likely Class 9 and/or 42). A clone with a confusingly similar name is the most common and most damaging attack, and the registration is the key to the platforms' fast-takedown channels.

The distinctive screens come next, because design patents must be filed within a year of public disclosure and offer the only direct protection for the visual "feel." Maya files design patent applications on the breathing-circle screen and the signature home layout while she still can.

The content—code, animations, soundtrack, copy—gets copyright-registered as a coordinated set, using special-relief deposits to preserve trade secrets in the code. This unlocks the right to sue and the statutory-damages remedy against literal copyists.

The novel functionality—the camera-based HRV algorithm—gets a deliberate choice: file a utility patent application (drafted as a specific technical improvement to survive Alice) or lock it down as a server-side trade secret, depending on how reverse-engineerable it is and how long Maya needs the edge. Often the answer is "both for a while"—file the application and keep it secret until publication.

The data and UGC get protected by a rigorous terms of service (anti-scraping, broad UGC license, representations), a DMCA registered agent and repeat-infringer policy, and a privacy program that treats personal data as a liability to be minimized, not an asset to be hoarded.

The components get a documented SBOM and a compliance pass to make sure no copyleft library is quietly threatening to open-source the whole app, and no SDK is creating hidden privacy exposure.

And underneath all of it, the ownership foundation: present written assignments from every founder, employee, and contractor, signed before they touched the work, so that Maya actually owns every layer she just spent money protecting.

Run that inventory and Larkspur is no longer "an app" that may or may not be protected. It is a documented portfolio of distinct, owned, enforceable assets—exactly the posture that lets you stop a clone, license with confidence, and pass due diligence without a fire drill.

The Ticketmaster Lesson: Layered Protection Wins Cases

A real-world illustration of why the layered approach matters comes from the bot-scalping wars. Ticketmaster, which sells through a website and a mobile app, built technical and contractual defenses against automated ticket-buying: CAPTCHA challenges, purchase limits, and terms of use that flatly prohibit bots and automated access. When ticket-broker operators allegedly deployed sophisticated bots to bypass those controls and scoop up hundreds of thousands of tickets for resale, Ticketmaster did not rely on a single theory. It pleaded a stack of claims—breach of the terms of use, copyright infringement (on the theory that building the bots required downloading and copying protected content from the app), DMCA anti-circumvention (for defeating the CAPTCHA and other technical measures protecting copyrighted material), CFAA and state computer-trespass violations (because the cease-and-desist letter had revoked any authorization), and fraud (the defendants agreed to the TOU and then breached it through fake accounts).

The litigation was bumpy—the court trimmed claims at the pleading stage and required amendment—but the amended complaint survived across multiple theories, and the matter resolved with at least one defendant accepting a permanent injunction against automated purchasing. The instructive point is precisely the thesis of this guide: no single tool would have done the job. Copyright reached the copying of app content; the DMCA reached the circumvention of technical measures; the CFAA and state law reached the unauthorized access after authorization was revoked; and contract—the terms of use—reached the conduct that the other doctrines could not. A developer who had relied on copyright alone, or on the CFAA alone (especially after Van Buren narrowed it), would have had a far weaker hand. Layered protection is not belt-and-suspenders overkill; it is how you actually win.

Key Takeaways

An app is a stack of separable assets, and protecting it well means protecting each layer with the tool that fits. To consolidate:

  • Copyright covers the code (source and object), the artwork, the audio, the text, and the original selection/arrangement of data—but only the expression, never the underlying idea, system, or function. Register to sue, and use special-relief deposits to preserve trade secrets in the code.
  • The API question is governed by Google v. Oracle: reusing interface code for genuine interoperability has strong fair-use protection, but APIs were not declared free for the taking—reimplement or license when you need certainty.
  • "Look and feel" is not a single right. Copyright protects the specific creative elements but not the general feel; trade dress protects a distinctive, non-functional, source-identifying look only after secondary meaning; and design patents directly protect the ornamental appearance of GUIs and are the most underused and, post-Samsung v. Apple, potentially highest-stakes tool in the stack.
  • Trademark protects the app name and icon—often the most durable value—and the registration is the key to fast platform takedowns. Clear before you launch.
  • Patents can protect genuinely novel functionality, but only claims framed as specific technical improvements survive Alice; for easily-hidden methods, trade secret may be the better deal.
  • Data is protected mainly by contract (TOS) plus thin compilation copyright, with the CFAA narrowed after Van Buren; personal data is a privacy liability, not an IP asset.
  • Trade secrets demand reasonable secrecy measures—above all, keep the secret on the server, because anything shipped to the device can be reverse-engineered lawfully.
  • Open-source and third-party components impose obligations on you; maintain an SBOM and watch copyleft, or risk being forced to open-source your app.
  • Ownership is the foundation everything rests on: secure present written IP assignments from every founder, employee, and contractor before they create anything, because contractors usually own what they make absent a signed assignment.
  • App-store developer agreements are real contracts forming the outermost layer—read them.

Frequently Asked Questions

Do I need to register my copyright if it exists automatically? You own the copyright the moment you fix the work, but under Fourth Estate v. Wall-Street.com, 586 U.S. 296 (2019), you generally cannot file a U.S. infringement suit until the Copyright Office has acted on your application. Timely registration also unlocks statutory damages and attorney's fees, which are often the only economically viable remedy against a clone. Register the code and the visible content (art, audio, text). See How to Register a Copyright with the US Copyright Office.

Can copyright stop a competitor from building a similar app? Only if they copied your protected expression. Copyright does not protect ideas, functionality, or methods of operation (§ 102(b)). A competitor who studies what your app does and writes original code to do the same thing has not infringed your copyright. To stop functional copying you need a patent (if the functionality is novel and survives Alice), a trade secret (if you can keep the method hidden), or a strong brand and market lead.

Is my app's "look and feel" protected? Partly. The specific creative elements—icons, illustrations, original copy—are copyrightable. The overall feel and method of operation generally are not (compare Apple v. Microsoft and Lotus v. Borland). For the visual identity, pursue design patents on distinctive screens (filed within a year of disclosure) and trade dress once the look has acquired secondary meaning and is shown to be non-functional. See Design Patents vs. Trade Dress.

Who owns the app if I hired a freelance developer? Often the freelancer, unless you have a signed present assignment. Independent-contractor work is not "work made for hire" except in narrow statutory categories with a written agreement, so without an assignment you may hold only an implied non-exclusive license. Get a present written IP assignment from every contractor before work begins. See Employee Invention Assignment Agreements and Popular Legal Documents for Startups.

Can I patent my app's features? Sometimes. Software and business-method claims must survive the two-step Alice/Mayo eligibility test (Alice, 573 U.S. 208 (2014)). Claims framed as a specific technical improvement to a technical system—with detailed specification support—can be eligible (Enfish, McRO, BASCOM); claims that recite an abstract idea "on a computer" are not. Patents are slow and costly, so weigh them against trade-secret protection. See Patent Eligibility After Alice.

Is open-source code "free" to use in my commercial app? Free of charge, not free of obligations. Open-source licenses are enforceable copyright licenses with conditions (Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008)). Permissive licenses (MIT/BSD/Apache) mostly require attribution; copyleft licenses (GPL/AGPL) can require you to release your own source code. Maintain a software bill of materials and screen for copyleft. See Open Source Licensing Landmines in Enterprise Software Development.

How do I protect the data and user content in my app? Use contract first. A well-drafted terms of service can prohibit scraping and bulk extraction and grant you a license to host user content; facts themselves are not copyrightable (Feist) and the CFAA is narrowed after Van Buren. If users upload content, designate a DMCA agent and adopt a repeat-infringer policy to qualify for the § 512 safe harbor. Personal data is governed by privacy law, not IP law—see Legal Issues for Mobile Applications: Privacy.

Should I trademark my app's name, and in what classes? Yes—the brand is often your most durable asset, and federal registration confers nationwide priority and access to the platforms' fast takedown channels. Choose a distinctive (arbitrary or coined) name, clear it before launch, and register in the correct Nice classes—commonly Class 9 (downloadable software) and/or Class 42 (SaaS). See How to File a Trademark Application with the USPTO and USPTO Trademark Classes.

Related Articles

This article provides general information and is not legal advice. The law varies by jurisdiction and changes over time; for advice on your specific situation, consult qualified counsel.