Sam James <[email protected]> writes: > Michał Górny <[email protected]> writes: > >> Hello, >> >> Recently we've seen quite a grow in LLM usage in upstream packages, to >> various degrees. The exact degree differs, apparently ranging from >> using LLMs as glorified autocomplete to asking them to rewrite the whole >> project or being convinced that a chatbot is sentient. The results are >> raising some concerns. I've originally written to the distributions ml >> [1] to facilitate some feedback on how other distributions are handling >> it, but the major players didn't reply. >> >> 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. >> >> Two recent cases that impacted the Python team were autobahn and >> chardet. > > I think there are cases where we can uncontroversially (*) want to mark > somehow, those are: > 1) LLM-assisted rewrites for copyright reasons: clearly dubious > ethically and legally; > 2) where the quality has gone substantially downhill, so legal issues > aside, it's not fair to our developers or our users (or upstreams of > *other* packages) to expose them to bugs from the rewrite. > > Supposing we can agree that at least some packages require marking, > there's some things we want out of that: > 1) users being able to avoid such packages if they wish; > 2) preventing software from relying on it (at least in some, perhaps the > default, configuration(s)); > 3) avoiding people packaging tainted/broken versions.
I think in the end we may want at least two solutions: 1) catastrophic cases like chardet want something like p.mask as Eli suggested, and 2) some LICENSE-based solution (or similar) for users to exercise their choices, and I think I'd be one of them doing that. > > For technical ways of achieving this marking: > [...] BTW, we did discuss package.deprecated on IRC the other day, but we concluded it was unsuitable. It is developer-facing (Portage doesn't warn on it); would be unreasonable for it to do so as a lot of it would scare users and not be actionable for them), so we'd need to introduce another file for it, and even then, it'd lack a convenient way to avoid said package, unlike with licence-based masking. But it could work and users could, with a new file, put entries into their own /etc/portage masks. > > (*) I consider these to hopefully have rough consensus even if > the app-admin/keepassxc case doesn't. > > So, to me, it seems LICENSE is the best option even if not ideal, as it > gives us most of what we want, and it's the closest to working. > >> [...] > > thanks, > sam
signature.asc
Description: PGP signature
