Personally, I think it's worth looking for some answer that goes deeper than "no," since we're likely to see more and more code like this, and since we want to encourage honesty rather than see more and more developers pretend that LLM generated code is their own.
But I'm not sure what Debian can do here. Is it worth putting together a whole new list of packages in a similar state to this one and changing how it's handled as the copyright law settles over the coming... decades? Debian might not want to be caught disturbing any of it, but if there is a package list somewhere that could be referenced... I don't know. These questions are not all legal, and I have limited experience with the other aspects here. I'm not sure anybody here can speak for the best strategic approach, we can only advise on the legal risk and related Debian policies like software freedom standards. It wouldn't make sense to just include this in nonfree, for example. It's kinda Free, but the risk isn't a risk of software under a proprietary licsnse, it's a risk of infringement. Some aspects of the software are going to be non-copyrightable, and public domain code is Free, but we don't know whether to categorize the package as under public domain or your claimed license or a bit of both, which it is. So... Distribution would probably be the biggest legal risk, anybody distributing the package could potentially be liable for copyright infringement and Debian would want to steer clear of that risk as best as it can. What repositories are not distributed by or with Debian? Regards, Daniel J. Hakimi B.S. Philosophy, RPI 2012 B.S. Computer Science, RPI 2012 J.D. Cardozo Law 2015 On Thu, Oct 22, 2026, 07:56 Andrei Ionuţ Ştefan < [email protected]> wrote: > Daniel, > > Thank you for this — genuinely useful, and more rigorous than anything > else in this thread so far. > > I want to be upfront: I'm not a legal expert, and the > clone/license-scanner mitigation I mentioned earlier (ScanCode, FOSSology) > was researched with Claude's help, not independent legal knowledge. I > should have been clearer about that distinction when I first raised it. > > Your point about AFC makes something clear that I'd missed: those tools > catch verbatim or near-verbatim matches, not the kind of > structural/non-literal similarity AFC actually tests for. So my earlier > framing — "run a scanner and that addresses the regurgitation risk" — > overstated what that tooling actually covers. It's still useful for > catching the obvious cases, but it doesn't touch what you're describing. > > Given that AFC-style analysis is apparently impractical to do credibly > without expensive litigation-grade work: is there a realistic middle ground > here at all for a project like this, or is "we can't practically rule this > out" effectively disqualifying for archive inclusion as things currently > stand? I'd rather understand where the real floor is than keep suggesting > mitigations that don't actually address the risk you're describing. > > Sincerely, > Ştefan Andrei Ionuţ > > În joi, 22 oct. 2026 la 14:52, Daniel Hakimi <[email protected]> a > scris: > >> One thing I'd like to clarify here is that copyright is not limited to >> verbatim copying. Copyright covers expression, and software is treated like >> any written work. This is kind of funny, because, in a novel, you can have >> a copyright in a plot, or in a character, or in a lot of other elements >> that are hard to pin down. >> >> One test we talk about is abstraction, filtration, comparison. We >> abstract the code to the highest level of abstraction that is still >> copyrightable, filter out non-copyrightable bits (such as functional >> aspects under the merger doctrine, since copyright can only cover the >> expressive aspects that are not functional, but this is a trickier rule >> than it might sound like, software in general is considered expressive), >> and then compare what's left. >> >> This test is difficult to go through. It results in a lot of expensive >> litigation. You can compare for verbatim copying relatively easily. You >> can't practically do A-F-C on your own and promise us that there's no real >> issue. >> >> Using LLM-generated code is fundamentally risky. There's no telling what >> copyright issues might be hiding inside. I appreciate that you intend to >> trace and understand much of the code you're generating, but unless you >> understand every other browser's entire code base very deeply, from >> conventions to variable names to every other little thing... There's no way >> to guarantee that you own it, or, again, that anybody owns it. >> >> I don't mean to suggest that there isn't a way to overcome or accept >> these risks on a practical level. But there's no way to suggest that these >> risks aren't there. Not yet. >> >> Regards, >> >> Daniel J. Hakimi >> B.S. Philosophy, RPI 2012 >> B.S. Computer Science, RPI 2012 >> J.D. Cardozo Law 2015 >> >> On Thu, Oct 22, 2026, 06:59 Andreas Røsdal <[email protected]> >> wrote: >> >>> >>> On Thu, Oct 22, 2026 at 11:13 AM Gard Spreemann <[email protected]> >>> wrote: >>> >>>> Andreas Røsdal <[email protected]> writes: >>>> >>>> > Commercial Terms, §B: the customer owns its Outputs, and “Anthropic >>>> hereby assigns to Customer its right, title and interest (if any) in >>>> > and to Outputs.” >>>> > >>>> > https://www.anthropic.com/legal/commercial-terms >>>> >>>> Again, I am not a lawyer, but this merely states that Anthropic does not >>>> retain claim ownership over the output of the model, not that you can >>>> necessarily claim copyright over it. >>>> >>>> For example, we all agree that the words "hello world" are not >>>> copyrightable (by anyone). Do you really think that Anthropic's terms >>>> mean that as soon as their model outputs "hello world" to you, you can >>>> claim copyright on those words? Of course you cannot – so clearly, >>>> Anthropic's terms can't conjure out of thin air your ability to >>>> copyright something. Thus those terms are no proof of anything, and are >>>> meaningless to the discussion. Nobody here is saying that Anthropic's >>>> rights are the reason your copyright is in doubt. >>>> >>>> >>> Each and every improvement to the browser had been incremental, small >>> improvement, which improves or fixes one thing I ask it to fix, and then I >>> verify the results afterwards. It's like an artist painting a painting, one >>> stroke at a time. >>> >>> >>> Andreas >>> >>> >>
