Such imperfect measures offer a compromise between "big tech can steal everything" and "LLMs trained on unpurchased books are illegal".
It's not just books but any tragedy-of-the-commons situation where a "feeder industry" for training can be fatally undermined by the very LLM that desires future training data from that industry.
Indeed the company should purchase the books. If they obtain copies in a process that violates copyright, then that's indeed a violation of copyright.
The current decision does not rule on the legality of obtaining the books without purchasing.
However, that option was ultimately not pursued as instead...
>> Anthropic spent many millions of dollars to purchase millions of print books, often in used condition. Then, its service providers stripped the books from their bindings, cut their pages to size, and scanned the books into digital form — discarding the paper originals. Each print book resulted in a PDF copy containing images of the scanned pages with machine-readable text (including front and back cover scans for softcover books). Anthropic created its own catalog of bibliographic metadata for the books it was acquiring. It acquired copies of millions of books, including of all works at issue for all Authors.
(from the ruling)
If the actual model was trained from the unauthorized copies, and then they post-hoc bought the books, that doesn't retroactively cancel the initial copyright violation. As I understand they did not retrain the model using the OCR'd scans
IMHO, a better example would be the AI generated summaries provided by Google. Often these summaries have sufficient information and detail that people do not read the source article. The authors aren't getting paid (perhaps through on-page ads, which are not viewed) and then go out of business.
This strikes me as a good fit for the tax-on-cassette metaphor.
Just as duplicating a fragment can be legal, duplicating any fragment on demand is not. Rephrasing a passage might be legal, but rephrasing any passage on demand might not.
https://1minutebook.com/are-book-summaries-legal/
Fair use is a defense often cited in those cases but it's just that: a defense. Cliff Notes are often cited here but they actually license the content in many cases.
> If you want to write a summary of any novel, without quoting from it, you are free to do it
> Copyright does not protect ideas, only a particular expression of those ideas
> You would likely get in trouble only if your summary contained long excerpts directly from the book
> As long as you do not quote directly from the book, or copy any of the content, then writing a unique summary is not illegal. You can mention the title, you can even quote sentences from the book as long as they are cited, you just can’t reproduce chunks of the content
etc
(I'm also not sure whether this article is just blogspam or itself AI generated)
But for non-fiction and technical books, they sure as hell will. For example, if I ask Gemini "What does Bob Nystrom say about the Singleton pattern in Game Programming Patterns?", it says:
---
In "Game Programming Patterns," Bob Nystrom dedicates an entire chapter to the Singleton pattern, which is unusual because, as he states, "Every other chapter in this book shows you how to use a design pattern. This chapter shows you how not to use one."
Here's a summary of his key points regarding the Singleton pattern:
* More Harm Than Good: Nystrom argues that despite its noble intentions, the Singleton pattern often does more harm than good, especially in game development. He notes that the Gang of Four (GoF) stressed its sparing use, a message that was often lost in translation to the game industry.
* Global State in Disguise: He highlights that the Singleton is essentially a global variable in disguise. While it ensures a single instance, it often leads to problems associated with global state, such as tightly coupled code, difficulty in testing, and reduced flexibility.
* Encourages Tight Coupling: By providing a global access point, Singletons encourage various parts of the codebase to directly depend on them. This makes the code harder to change and refactor because modifications to the Singleton can have widespread, unpredictable effects.
* Hinders Testability: Testing code that relies on Singletons can be challenging. Because Singletons are globally accessible and often difficult to mock or replace, it can be hard to isolate units of code for testing, leading to brittle tests or a lack of testing altogether.
* Limits Flexibility: Nystrom points out that while a class might currently only need one instance (e.g., a FileSystem or AudioSystem), hardcoding this limitation with a Singleton makes it difficult to change in the future. If a game later needs multiple file systems (e.g., for different save slots) or different audio contexts, a Singleton makes this a non-trivial refactoring.
* Alternatives Often Better: He suggests that often, what developers think they need a Singleton for can be better achieved with other patterns or simpler solutions. For instance, if the only goal is to have a single instance, a simple static class might suffice if global access is truly desired and initialization order isn't a complex concern. For managing services, he often advocates for the Service Locator pattern as a less problematic alternative that still provides global access without enforcing a single instance.
* Misconceptions about "Singular Resources": While the GoF suggested Singletons for "physical devices," Nystrom argues that few physical devices are truly singular in a way that necessitates a Singleton. For example, while you might only have one keyboard, a game could theoretically support multiple input devices. Using a Singleton prematurely prevents this flexibility.
* Lazy Initialization: He acknowledges that a well-implemented Singleton using lazy initialization (creating the instance only when it's first accessed) can save memory and CPU cycles and resolve some issues with static initialization order. However, he emphasizes that these benefits don't outweigh the pattern's fundamental architectural drawbacks.
* In essence, Nystrom's strong stance is that while the Singleton pattern can ensure a single instance and provide global access, its downsides (coupling, testability, flexibility) often make it an anti-pattern in game development, and developers should carefully consider alternatives before reaching for it.
---
Is that summary as good as actually reading the book? Probably not. Will people rely on that and skip buying my book. Almost certainly so.
I believe copyright is always case-by-case. No one sues over plot summaries because they likely help sales. Summarize books or news articles with an LLM and you end up with the lawsuits we see today.