LLMs and the Law

No, a language model is not a derivative work of its training set merely because it was trained on it.

A derivative work must “recast, transform, or adapt” one or more preexisting works. Courts generally also require incorporation of protected expression—not merely learning facts, ideas, statistical relationships, vocabulary, or style. See 17 U.S.C. § 101, 17 U.S.C. § 102(b), and 17 U.S.C. § 106(2).

In theory, a particular model could potentially infringe if its weights encode recoverable protected expression. As of October 2026, no reported U.S. merits decision has held that an LLM’s weights are themselves infringingly copies or derivative works of identified training works.

The emerging distinction is:

Yes, but only in a limited sense. The clearest merits-stage example involved adversarial prompts specifically designed to extract training data.

In Kadrey v. Meta, at summary judgment, the court treated the evidentiary record as showing that Llama could be induced through adversarial prompts to regurgitate short passages—no more than about 50 words—from the plaintiffs’ books. The court called these “minuscule portions” and found that they did not meaningfully substitute for the books or establish the plaintiffs’ claimed market harm.

The court considered that evidence when deciding whether Meta’s training copies were fair use. It did not separately hold that every output containing such a passage was a fair use. See Kadrey v. Meta Platforms, Inc., summary-judgment order (N.D. Cal. 2025).

Not ordinarily, and not merely because its source model was trained on the set.

This is because “the training set” is in practice never a single copyrighted work. It may contain millions of separately owned works, public-domain material, uncopyrightable facts, and perhaps a copyrightable selection or arrangement. See 17 U.S.C. § 101 and 17 U.S.C. § 103. Derivative status therefore normally must be analyzed against individual identified works, not against the dataset in the abstract.

As of the date of this FAQ, I am not aware of a reported U.S. merits decision holding that text generated by an LLM was an infringing derivative work of an identified training text. Courts have allowed some output-infringement theories to proceed at the pleading stage, but those decisions establish only that the allegations were plausible, not that infringement occurred.

An output can be an infringing reproduction or derivative work if it is substantially similar in protected expression to a training work (some specific work in the training set). Similarity in unprotected ideas, facts, or style alone generally is insufficient. See 17 U.S.C. § 102(b) and Kadrey v. Meta Platforms, Inc. (N.D. Cal. Nov. 20, 2023).

The involvement of an LLM does not eliminate the ordinary requirements for copyright infringement. Whether a particular output is protected by fair use is a separate, fact-specific question under 17 U.S.C. § 107.

Yes. Assembling and using a training corpus normally entails making copies and can therefore implicate the copyright owner’s reproduction right under 17 U.S.C. § 106(1). A developer’s lawful access to a source does not necessarily authorize making a new training copy. Conversely, an unlicensed copy is not necessarily infringing if fair use under 17 U.S.C. § 107 or another statutory limitation applies.

The clearest decided LLM case concerning acquisition of training material is Bartz v. Anthropic, although it did not culminate in a final finding of liability.

Anthropic downloaded millions of books from pirate libraries, including LibGen and PiLiMi, kept them in a central research library, and made further copies of some books for LLM training. In June 2025, the district court ruled:

See Bartz v. Anthropic PBC, order on fair use (N.D. Cal. June 23, 2025).

The important procedural qualification is that only Anthropic had moved for summary judgment. The court rejected Anthropic’s fair-use defense for the pirated-library copies, but it did not enter a final merits judgment declaring Anthropic liable. The parties subsequently settled for $1.5 billion, without a trial or admission of liability. The final settlement required destruction of covered pirated copies, subject to legal-preservation obligations. See Bartz v. Anthropic PBC, final settlement approval (N.D. Cal. July 20, 2026).

Thus, the legality of acquiring or retaining source copies, the legality of making training copies, the legal character of model weights, and the legality of particular outputs are distinct questions.

(Included because has been a common use case of LLMs.)

Yes. Reverse engineering software binaries is generally legal in the United States, but it is not categorically legal in every circumstance. The answer depends on copyright, the DMCA, trade-secret law, and sometimes contract law.

The leading copyright case is Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992). Accolade disassembled Sega’s object code to determine how to make independently written games compatible with the Genesis. The Ninth Circuit held: “disassembly of copyrighted object code is, as a matter of law, a fair use” when disassembly is necessary to get at unprotected elements of the program and the reverse engineer has a legitimate (e.g non-criminal) reason for doing so.

That principle was reinforced in Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000). Connectix reverse-engineered Sony’s PlayStation BIOS while developing its independently written PlayStation emulator. The Ninth Circuit held that the intermediate copies made during reverse engineering were fair use, even though the entire BIOS was copied during the analysis. The resulting emulator did not contain Sony’s copyrighted code.

So, for example, this is generally on quite strong ground under those precedents:

binary → disassembler/decompiler → learn undocumented interface → write your own implementation

provided that the resulting implementation doesn’t copy protected expression from the original.

The DMCA added a separate prohibition against circumventing technological access controls. But Congress included an explicit reverse-engineering exception for interoperability, 17 U.S.C. § 1201(f).

It permits someone who has lawfully obtained the right to use a program to circumvent an access-control measure for the purpose of identifying and analyzing program elements necessary to achieve interoperability of an independently created program, subject to several conditions. It also permits development of circumvention tools necessary for that interoperability.

Thus there is an important distinction between disassembling an unobfuscated executable you lawfully possess and defeating encryption, DRM, authentication, or another technological protection in order to obtain the code.

The first may straightforwardly fall under Sega/Connectix fair use. The second raises §1201 independently, although §1201(f) may protect interoperability work.

There can also be contract complications. An EULA may purport to prohibit reverse engineering. Whether such a provision is enforceable can depend on jurisdiction and circumstances, so Sega shouldn’t be read as saying that copyright law automatically invalidates every contractual restriction.

And if the software wasn’t legitimately obtained, additional bodies of law can come into play. Trade-secret law, unauthorized computer access, contractual confidentiality obligations, and acquisition of leaked proprietary source code are quite different cases from examining a binary that you lawfully possess.

(Included because of the controversy about Photocraft and similar projects.)

Clean-room development is a process for producing a compatible program without giving its implementers access to the original program’s protected code or other expressive material. Typically, one team studies the original system and writes a specification limited to functional requirements, interfaces, protocols, and other unprotected information. A separate team, which has not seen the original code, implements a new program solely from that specification. The separation, provenance of the specification, and development history should be documented.

A clean-room process is evidence of independent creation; it is not a statutory safe harbor. It does not excuse copying that occurs during analysis, make protected expression unprotected, or eliminate possible liability under contract, trade-secret, patent, or anti-circumvention law. Its value depends on whether the separation was real and whether the resulting program copies protected expression rather than only unprotected functionality.

There is no single Supreme Court decision establishing a nationwide clean-room rule. The principal authorities are jurisdiction-specific:

Thus, a well-run clean room reduces the risk of copying protected expression and creates evidence of independent development, but the resulting program must still be evaluated under the copyright rules applicable in the relevant jurisdiction.

In part. A software UI may contain copyrightable visual or textual expression, but copyright does not protect the UI’s ideas, functions, systems, procedures, or methods of operation. It also does not protect elements dictated by technical constraints or conventions, nor short and commonplace labels such as “Save” or “Print.” See 17 U.S.C. § 102(b).

Potentially protectable material can include original artwork, icons, animations, text, and sufficiently creative choices in the selection and arrangement of visual elements. Protection extends only to that expression, not to the underlying task, workflow, or general design concept. A copyright in a particular drawing of a trash-can icon, for example, does not confer a monopoly over using a trash can to represent deletion.

The leading “look and feel” case is Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The Ninth Circuit recognized that a GUI can be a copyrightable audiovisual work, but required the court to identify and filter out licensed and unprotectable matter before comparing the works. It held that basic GUI ideas such as windows, icons, menus, and the desktop metaphor were not themselves protectable. Features that were standard, functionally constrained, or among only a few ways to express an idea were also unprotectable or received only “thin” protection against virtually identical copying. An original combination of individually unprotectable elements may be protected, but only the author’s particular selection and arrangement—not the elements or system themselves.

Interaction design can receive still less protection. In Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807 (1st Cir. 1995), the First Circuit held that the Lotus 1-2-3 menu-command hierarchy was an uncopyrightable “method of operation”: users employed the command names and hierarchy to operate the program. The Supreme Court affirmed by an equally divided Court, which left the First Circuit’s judgment standing without creating a nationwide Supreme Court precedent. See Lotus Development Corp. v. Borland International, Inc., 516 U.S. 233 (1996). Lotus distinguished the operative command hierarchy from expressive screen displays and explanatory prompts that users did not have to employ to control the program.

Thus, copying a UI’s general workflow, familiar controls, functional behavior, or conventions is not automatically copyright infringement. Copying its distinctive graphics, prose, animation, or a sufficiently original visual composition may be. The practical analysis is element-by-element: identify what was copied; remove ideas, methods of operation, stock elements, public-domain material, and features dictated by function or compatibility; then compare the remaining protected expression under the infringement standard of the relevant jurisdiction.

Copyright is not the only possible protection. A UI may also implicate design patents, utility patents, trademarks or trade dress, contracts, and trade-secret law. Those regimes have different requirements and may protect interests that copyright does not.