On 3/10/26 10:25 PM, Kai Krakow wrote:

> What about code running Gentoo infrastructure? Or Gentoo tooling?
> What's the scope of the AI policy regarding "contribution to Gentoo"?
> Today, many packages have deep dependencies. It will be hard to avoid
> code which has AI assisted code involved. The text from the wiki
> doesn't really explain that to me:
> 
>> This policy affects Gentoo contributions and the official Gentoo projects. 
>> It does not prohibit adding packages for AI-related software or software 
>> that is being developed with the help of such tools upstream.
> 
> Yes, it says I can add packages to Gentoo which are about AI, or which
> are developed using AI. Fine. That's easy. But a contribution to
> Gentoo infrastructure goes deeper as such code becomes part of Gentoo
> tooling and/or infrastructure and is no longer just a random package.


Repositories hosted on:

https://gitweb.gentoo.org

and often mirrored to

https://codeberg.org/gentoo
https://github.com/gentoo

are official gentoo projects. That includes the gitweb projects under
infra/ and proj/, so, contribution to official Gentoo infra / tooling
run by infra.

Such repos cannot include content "created with the assistance of" an
LLM. Patches to code or artwork are "content", commit messages are
"content".


> Again, I don't want to say the rule is useless. I want to understand
> it to act properly and *not* violate it.
> 
> With that in mind, at least chardet is part of the infrastructure and
> tooling, isn't it?


Dependencies aren't official Gentoo projects (unless said dependencies
are also hosted by Gentoo ;)) so depending on chardet wouldn't violate
Council policy. Unless someone proposes to contribute "the chardet
project" itself to the Gentoo Foundation.

Developers of specific Gentoo projects might say chardet's mother was a
hamster, and its father smelt of elderberries. But that's not enforced
by Council policy, and would need negotiation with said devs.


> But I'm not sure if that should be discussed further here, and I'm
> fine with leaving it as an open question to discuss somewhere else.
> And I'm fine with being extra careful with getting involved in any
> core tooling just to avoid violating any policy, and only contribute
> when the policy applies a clearly defined scope, e.g. just
> contributing ebuilds.


... or only contribute LLM-free proposals, since LLM-free contributions
are compliant with the policy if it *does* apply, and cause no issues if
it *doesn't* apply. ;)


-- 
Eli Schwartz

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to