mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "H. Peter Anvin" <hpa@zytor.com>,
	Jonathan Corbet <corbet@lwn.net>,
	 Steven Rostedt <rostedt@goodmis.org>
Cc: Christian Brauner <brauner@kernel.org>,
	 tech-board-discuss@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	 ksummit-discuss@lists.linuxfoundation.org,
	christianvanbrauner@gmail.com
Subject: Re: LLM based rewrites
Date: Mon, 09 Mar 2026 11:19:42 -0700	[thread overview]
Message-ID: <1caf74551e06ef43e4cc6829c961c1de2bbf8758.camel@HansenPartnership.com> (raw)
In-Reply-To: <04B897EF-DEEC-42D0-8E00-888CEEA5318E@zytor.com>

On Mon, 2026-03-09 at 09:55 -0700, H. Peter Anvin wrote:
> On March 9, 2026 9:33:12 AM PDT, Jonathan Corbet <corbet@lwn.net>
> wrote:
> > Steven Rostedt <rostedt@goodmis.org> writes:
> > 
> > > On Mon, 09 Mar 2026 08:31:03 -0700
> > > "H. Peter Anvin" <hpa@zytor.com> wrote:
> > > 
> > > > It is somewhat hard to see how that would constitute a "clean-
> > > > room"
> > > > rewrite. A clean-room rewrite entails two teams, one (the
> > > > "clean" room)
> > > > which must be certified to have never seen the code in
> > > > question, and all
> > > > communications between the two teams must be auditable.
> > > 
> > > I was thinking the same.
> > 
> > The argumentation that is being made (which I am trying to
> > reproduce but
> > am *not* advocating) is that "a clean-room rewrite is just one
> > means to
> > an end" and that, in this specific case, the code being rewritten
> > was
> > explicitly excluded from the context given to the bot (though that
> > turns
> > out not to entirely be the case).  In theory, it only had the
> > desired
> > API and a set of tests available to it.
> > 
> > The fact that every version of chardet was surely in its training
> > data
> > is not deemed to be relevant.
> > 
> > jon
> > 
> 
> That's a question for the lawyers and the courts, really. But it is
> most definitely *not* clean room. That being said, clean room is
> certainly not the only way to rewrite software that can pass legal
> muster, but it is the gold standard

Agreed.  The specific problem is that The US Copyright definition of
derivation presumes that if you've had exposure to the original work
then anything you produce that's similar is a derivative.  That doesn't
mean that you can't produce a non derivative similar work it's just the
burden of proof shifts to you to prove that in creating the similar
work you didn't include any elements of the original.  This is a
phenomenally difficult thing to prove in court (at least for humans)
which is why clean room reverse engineering was developed ... because
you can demonstrate the required non-exposure to the original by the
separation of the two teams.

I don't think LLMs will be able to come up with the necessary proof of
separation without essentially recreating the clean room process, which
grows cost prohibitive as the complexity of the work increases.

Regards,

James





  parent reply	other threads:[~2026-03-09 18:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-07 20:49 Christian Brauner
2026-03-09 13:57 ` Steven Rostedt
2026-03-09 15:31   ` H. Peter Anvin
2026-03-09 16:16     ` Steven Rostedt
2026-03-09 16:33       ` Jonathan Corbet
2026-03-09 16:55         ` H. Peter Anvin
2026-03-09 17:09           ` H. Peter Anvin
2026-03-09 18:19           ` James Bottomley [this message]
2026-03-09 18:34             ` Steven Rostedt
2026-03-09 18:38               ` Dr. David Alan Gilbert
2026-03-09 18:54               ` James Bottomley
2026-03-10  4:52           ` Theodore Tso
     [not found]             ` <CAMTJT3_cVaA7aJmDa6j288-qwP3jzvM_R2pdk+XmE+1U=Sovbg@mail.gmail.com>
2026-03-10 12:47               ` Theodore Tso
2026-03-10 14:10                 ` Dr. Greg
2026-03-09 16:05 ` Dave Hansen
2026-03-09 16:16 ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1caf74551e06ef43e4cc6829c961c1de2bbf8758.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=brauner@kernel.org \
    --cc=christianvanbrauner@gmail.com \
    --cc=corbet@lwn.net \
    --cc=hpa@zytor.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tech-board-discuss@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®