On Mon, 06 Jul 2026 22:42:48 +0200 Ludovic Courtès <[email protected]> wrote: > Examples of non-creative changes include > mechanical conversions of package metadata from other repositories > similar to those made by `guix import`, mechanical changes similar > to those made by `guix refresh` or `guix style`, changes that > merely follow suggestions made by `guix lint`, integration of > upstream patches, changes of a package’s `#:configure-flags`, and > similar package definition adjustments that are arguably below the > [threshold of > originality](https://en.wikipedia.org/wiki/Threshold_of_originality). > > WDYT?
The examples above seems to make sense, but what's really the threshold? Where to stop? The Wikipedia article doesn't talk about code and having to know the exact threshold is a huge mess, and I don't think it's even possible. In most cases we didn't have to deal with that before. In Guix everyone added their copyrights and it was up to courts to decide on the matter. And this didn't create any issue for the collective work as a whole because there was also copyrightable code/data in there as well and most[1] of it was legal anyway. And this whole mess is why I/we really need legal guidance here. Personally I don't have the legal knowledge to tell that this is original or not across a wide variety of jurisdictions. Do we really have maintainers, committers or people in teams that do? That should exists as Linux allowed code generated by LLMs. But Linux also requires to sign the Developers's Certificate of Onwership and it is also backed by the Linux foundation who has lawyers and also employs the people like Linus Torvalds which are ultimately responsible for such rules. Also note that they tag patches made with LLMs, so maybe lawyers review them? Maybe not? Are they too big to be able to not care about other jurisdictions than the US? The problem is also who to go to. Ideally we need a community of lawyers but GNU will probably tell us to wait, so what options do we really have here? And we do need good documentation for reviewers. Else we'd have the choice between not being able to review a huge amount of patches made with LLMs (which is worse than forbidding LLMs) or doing a bad review which come with legal risks (we don't even have a DCO here, so who is responsible?). And here I keep asking myself why we need to rush when GNU already made a rule that we have to follow that tells us to wait before integrating code/data made with LLMs. As far as I understand there was no GCD to leave GNU yet so that rule is binding. And to me the legal issues we bump into here are because the community is basically not ready, and the problem of "we can fix later" is also that, as you said: > I am somewhat reluctant to automated expiration because that could > leave us in limbo if the measures chosen in the GCD expire and nobody > picks up the work of consulting the community to determine what to do > next. And we also can't go back in the past to stop the flood of LLM contributions. What I would like to avoid is a situation like ReactOS where we end up having to do an audit of a huge amount of code. That slowed down their project for many years (people only did auditing for years). And the question is also how well did they audit the code? Were they just fed up and ended up spending years on auditing for nothing? Can Microsoft still shut them down on a whim? We live in a world where several big corporations would be happy to be able to shut down free software projects (and Google tried to shut down F-Droid). And here we are arguing on things that seem legally logical but is it really? How to know? That whole situation looks really absurd to me. Guix is important, it took countless effort by many people (which also includes advocacy etc, which is not in commits). Several projects depend on Guix already (GNU Boot, Zerocat Chipflasher, probably much more). And I really don't understand why we can't sit down and think about all that. I know at least 2 situations where people messed up their lives or their projects for legal reasons and there is basically no turning back. And note that while I'm against the inclusion of code/data made by LLMs I'm also more than willing to compromise on the matter for the sake of consistency, but at least can we do it right? Making the GPLv3 took years, people didn't rush like that. Most projects also don't invent their own license just because they can (though it could also be seen as more democratic as you can decide what's in it). While this GCD isn't as big/defining as the GPLv3, for Guix it is a huge decision, especially given the huge debate (the main/master branch wasn't that messy) and also because of the legal implications and the probable inability to go back in time remove all the commits made with LLMs (assuming that there are many). So if GCD really means Guix Consensus Document, can we at least have the time to do it right? Else what is really "Consensus" for if we take extremely important decisions without knowing enough about them and in a rush? It would look more like a forced decision, and if I recall well Debian which is also extremely important (it's more critical than Guix for many use cases) decided to not decide[2] and that's only 4 month ago. So can we do something like that and wait (and not accept code/data made with LLMs) until GNU releases its rules? This way we do have a deadline and the issue is not forgotten at all. And we'd have more information then. The exact same GCD could also be a starting point so the overhead would be extremely low to continue where we stopped. References: ----------- [1]The most common issue is probably if some code was copied verbatim from Stack Overflow, and that it was not in canonical form, but even then, the amount of code was small, and there were also ways around it (simply by rewriting the code). And it was also possible to combine the GPL and the the CC-BY-SA 4.0, though it is complicated to do, so almost nobody did what was required, but here I'm now a lawyer so I don't know how that interacts with the inbound/outbound convention. [2]https://lwn.net/Articles/1061544/ Denis.
pgpdTkapqDy9F.pgp
Description: OpenPGP digital signature
