Kai Krakow <[email protected]> writes:

> Am Mi., 11. März 2026 um 02:02 Uhr schrieb Eli Schwartz 
> <[email protected]>:
>>
>> On 3/10/26 8:23 PM, Kai Krakow wrote:
>> > Am Di., 10. März 2026 um 16:55 Uhr schrieb Michał Górny 
>> > <[email protected]>:
>>
>> >> Our "AI policy" [2] covers only direct contributions to Gentoo.  At the
>> >> time, we did not consider it appropriate to start restricting what
>> >> packages are added to Gentoo.  Still, general rules apply and some of
>> >> the recent packages are starting to raise concerns there.  Hence I'm
>> >> looking for your feedback.
>> >
>> > I think we cannot avoid that AI is somehow involved in any commits
>> > ending up in Gentoo, be it ebuilds, or be it packages. I'd argue that
>> > it is almost unavoidable for the common developer to have at least AI
>> > completion running in the code editor. I say "almost" and "common",
>> > because if someone really cares, they certainly *can* avoid that.
>>
>>
>> It is banned by Council voted policy. If we cannot avoid it, that means
>> users do it and then unethically lie and testify to Gentoo,
>>
>> """
>> This contribution has not been created with the assistance of Natural
>> Language Processing artificial intelligence tools, in accordance with
>> the AI policy.
>> """
>
> And I adhere to that for contributions to Gentoo. Such policies are in
> place to be followed. And it's easy to do that by just not using an
> editor which has any AI features.
>
> I just questioned how sure we can be to avoid it. And I agree: Yes
> people can ignore that, and it should be justified as a lie.
>
>
>> While it is pedantically true for you to say, it is physically possible
>> people lie to us and not get caught -- that is not an excuse for saying
>> "there is no point having a rule when people could lie and break the
>> rule". And it doesn't mean lack of 100% enforcement means the policy is
>> wrong and should be abolished.
>
> I didn't say "there is no point in having a rule". And the context
> hasn't even been ebuilds alone. chardet or autobahn don't provide
> ebuilds. So the context is source code. We cannot avoid that package
> source code with AI involvement becomes part of the packages that
> Gentoo ebuilds install.
>
> What's the scope of the Gentoo AI policy anyways?
>
> Yes, ebuilds. I clearly get that. That's not the question.
>
> 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.
>
> 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?
>

(I don't think this is a common understanding of the rule.)

> 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.

I'm a bit surprised to hear this argument. I think it's obvious that if
you wrote some script and it happened to use chardet (*) which is
developed using AI but suppose it is otherwise unproblematic, that
wouldn't count. You're also free to ask if you're unsure.

(*) Of course, with the licencing situation now too being well-known,
that would be ill-advised, so I'd be surprised if someone did that.

>
>
> Thanks,
> Kai

Attachment: signature.asc
Description: PGP signature

Reply via email to