> Oracle also *lost* that case.
It lost in on the fair use grounds. Which is pretty much an admission that organization and shape of APIs is something copyrightable (and thus requires a permission from the copyright holder) except when restrictions on it would do more harm than good. Straight from the discussed case:
Given programmers’ investment in learning the Sun Java API, to allow enforcement of Oracle’s copyright here would risk harm to the public. Given the costs and difficulties of producing alternative APIs with similar appeal to programmers, allowing enforcement here would make of the Sun Java API’s declaring code a lock limiting the future creativity of new programs. Oracle alone would hold the key. The result could well prove highly profitable to Oracle (or other firms holding a copyright in computer interfaces). But those profits could well flow from creative improvements, new applications, and new uses developed by users who have learned to work with that interface. To that extent, the lock would interfere with, not further, copyright’s basic creativity objectives.
Do you see an admission that API is uncopyrightable, here? On the contrary, it's an admission that API is copyrightable, but when someone else depends on your API you couldn't use it as a lock, because the lock would interfere with, not further, copyright’s basic creativity objectives.
This works for public APIs, but when LLM copies internal APIs that were never exposed to public it flies right out of the window: it's not public, it couldn't be used a lock, it's use is not “fair use” in any shape or form.
> It reads as if it slipped through a wormhole from a parallel universe where the law is entirely different.No, from parallel universe where people actually read documents and not just titles.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。