Detecting AI obfuscated porting [LWN.net]

Detecting AI obfuscated porting

Posted Jun 2, 2026 10:55 UTC (Tue) by pbonzini (subscriber, #60935)
In reply to: Detecting AI obfuscated porting by khim
Parent article: Ombredanne: An AI agent ported our codebase from Python to Rust

Clean room reverse engineering has been a valid technique since the 80s. Oracle v. Google was about copying the API declarations, analyzing the code and not publishing the result anywhere (only feeding it to another group of humans or agents) would be a completely different thing.

NEC v. Intel was not even completely clean room and yet was accepted as valid just because the result was different enough.

Detecting AI obfuscated porting

Posted Jun 2, 2026 19:02 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (2 responses)

Oracle also *lost* that case.

Frankly, the whole comment by khim is completely incomprehensible to me. It reads as if it slipped through a wormhole from a parallel universe where the law is entirely different.

Detecting AI obfuscated porting

Posted Jun 3, 2026 4:29 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

Well, it also has to be conceded that Oracle lost it on fair use grounds if I don't misremember. Fair use is complicated to evaluate and it took the supreme court to sort it out.

But still the case was not about the clean room reimplementation, which was fine, but about the copying of APIs beyond java.lang.

Detecting AI obfuscated porting

Posted Jun 3, 2026 13:38 UTC (Wed) by khim (subscriber, #9252) [Link]

> 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.