Charles, Fair pushback, and noted. To be clear: I'm not claiming the authority to decide whether Debian accepts Andreas's contribution — that's not mine to decide, and I didn't mean to imply otherwise.
I raised this specifically about Andreas's package because that's the package on the table in this thread, not because I think it's uniquely guilty — I'm aware there are other packages in a similar position. If there's an existing precedent or policy covering those, pointing me to it would actually resolve a lot of my questions faster than re-litigating this one case. My asks to Andreas were about getting clarity I need, not about rendering a verdict. If that came across otherwise, that's on my phrasing, not my intent. Ştefan Andrei Ionuţ În joi, 22 oct. 2026 la 15:14, Daniel Hakimi <[email protected]> a scris: > 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 >>>> >>>> >>>
