* On 2026-06-06 at 19:12 BST, Greg Troxel wrote:
Benny Siegert <bsiegert%netbsd.org@localhost> writes:On Sat, 6 Jun 2026, Jonathan Perkin wrote:This obviously needs to be clarified with respect to pkgsrc. For example if we have a package that has an important fix in their upstream repository but hasn't made it to a release yet we usually apply that patch to pkgsrc. Are you saying that if upstream used an LLM we can no longer apply that patch even if we didn't write it? How is that effectively different from just using an upstream tarball that includes the LLM patch?AIUI, this rule does not apply to patches. Patches are considered part of the code base that is being patched and thus under the same licence.We have considered patches the be licensed under the upstream license, and I think it makes sense not to object to cherry-picked upstream patches because they are vibecoded. I would not really want to cross into novel LLM output in pkgsrc. Patches are kind of funny because they are sort of pkgsrc authored but also at least partly by upstream, and sometimes totally by upstream. I would say Despite the general prohibition on LLM output being committed to TNF repositories (including pkgsrc and pkgsrc-wip), adding a patch from upstream (merged, pending PR, proposed in their communications channels) is acceptable. (As always, cherry-picked patches should be attributed, but that's not special about LLMs.)
But a patch that is not yet accepted by upstream is *not* ok, even if upstream are LLM-friendly and would likely accept it?
If so then I appreciate the guidance, but it does not make any rational sense to me, as I do not see the difference, nor what it is trying to prevent exactly, as either way you'd end up with LLM-generated code committed to pkgsrc, but you're saying one is ok while others are forbidden.
I completely understand and respect NetBSD src not wanting any LLM code under any circumstance, for example, but this guidance is not consistent as I understand it.
Thus I'd again like a very clear list of "is" or "is not" accepted, as I fear that such inconsistencies will make it difficult to know exactly where one stands, and I (personally as a heavy LLM user elsewhere) don't want to make any mistakes here.
What is not allowed (again, in my understanding of the rule) is using a coding agent for the pkgsrc files themselves (e.g. Makefiles). Since Chavdar is doing that, these packages are not allowed in pkgsrc itself.That is my interpretation too.
Again this doesn't make much sense to me, but perhaps that is because in my mind there's no way that you could consider most Makefiles copyrightable given they are little more than generic metadata, but again this is where hard and fast rules that are written down somewhere official would be appreciated so that there is no confusion.
Thanks, -- Jonathan Perkin pkgsrc.smartos.org Open Source Complete Cloud www.tritondatacenter.com