Hi,
Thanks for the feedback!
On 20/02/26 at 10:21 +0100, Stefano Zacchiroli wrote:
> > 1. **Legal Compatibility:** Contributors should ensure that the terms and
> > conditions of the generative AI tool do not impose contractual
> > restrictions that conflict with the distribution, modification, or use of
> > the output in the context of Debian.
>
> (nitpick) I agree with this one, but the title isn't great as it makes
> people (or me at least) think of license/copyright compatibility issues
> on the output, whereas it is more specific---as clearly described in the
> expanded version. How about "legal use" or "permitted use"? They are not
> great either. Maybe someone else will come up with a better suggestion.
I agree it's not optimal. Maybe "Tooling Legal Compatibility" would be
better?
> > 2. **Licensing and Attribution:** If any pre-existing copyrighted materials
> > (including pre-existing code licensed as free software) authored or owned
> > by third parties are included in the AI tool’s output, prior to
> > contributing such output to the project, the contributor should verify
> > that such materials are available under a compatible license.
> > Additionally, the contributor should provide notice and attribution of
> > such third party rights, along with information about the applicable
> > license terms, with their contribution.
>
> I agree with this one too, but I find the wording to be too strong,
> because it implies an active action on contributors' part *for each use
> of a given tool*. We know that that is not going to happen. What is more
> realistic is that contributors will vet *tools* for this (for example,
> some coding assistants have integrated code clone detection / plagiarism
> detection / provenance detection capabilities that would help there and
> that can be enabled once and for all). Any remaining license violation
> (if at all) can be caught and fixed downstream, as it already happens
> today for license violations introduced in the archive for any other
> reason.
>
> For comparison, the Linux kernel guidelines on this topic say "All code
> must be compatible with GPL-2.0-only". Note how the wording is on the
> result, without saying what contributors should do at each use.
To me, the precondition ("if any pre-existing copyrighted materials
authored or owned by third parties are included in the output") means
that the contributor is expected to first question whether it is likely
that the output is including copyrighted material. For many prompts, the
output won't be copyrighted, because it's either trivial or too strongly
linked to pre-existing code in the codebase being modified.
But if I prompt "write a python method that decompresses a
gzip-compressed file without using any built-in compression library",
then it's likely that the output will contain unmodified pre-existing
code.
In my experience, it's easy to understand if one should worry by looking
at the changes being proposed.
I'm not sure it's a good idea to explicitely recommend code clone
detection tools since most AI assistants dont have such features.
I'm not sure how to improve the proposal though.
> > 3. **Accountability:** Contributors assume full responsibility for their
> > contributions, including vouching for the technical merit, security,
> > license compliance, and utility of their submissions. The contributor
> > remains solely accountable for the entirety of these contributions.
> > Contributors should fully understand the proposed changes and be prepared
> > to justify them.
> >
> > 4. **Explicit Disclosure:** When a significant portion of the contribution
> > is taken from a tool without manual modification, contributors should
> > disclose the tool's use. This may be recorded using Git trailers, such as
> > `Generated-By:` or `Assisted-By:`.
>
> Again, for comparison purposes, here's what the Kernel community comes
> up with about these two:
generated-content.rst also has:
> Ensure that you understand your entire submission and are prepared to respond
> to review comments.
which aligns with
> Contributors should fully understand the proposed changes and be prepared
> to justify them.
Lucas
