On Wed, Jul 16, 2025 at 04:09:41PM -0400, Stephen Gallagher wrote: > I'm thinking we should treat AI-generated code the same way that we > would treat sub-contracted code. I've worked at companies that > outsourced some software-development to subcontracting companies. The > way this would generally work is that there would be an on-site > coordinator that submitted all of the code on behalf of the (most > likely underpaid) coders working elsewhere. The way this was > interpreted is that the coordinator, as a representative of the > subcontracting company, was taking on the responsibility (and > accountability) for verifying that the content being submitted is > functional, non-malicious and not *known to be* violating anyone's > copyright. If later it turned out that someone on their team was > stealing code, the person whose name was on the commit would be held > responsible for that violation. > > I think we can realistically only hold generative AI submissions to > roughly this same standard: we already trust our contributors to do > their due-diligence. They remain responsible for what the code they > submit does (and will be held accountable for it if it's malicious or > violates copyrights and patents).
In practical terms, how can a contributor do due-diligence on the output of an AI generator ? The vast size of training material makes it hard, if not impossible validate the license & copyright compliance of non-trivial code. Some tools claim to validate their output for compliance in some manner, but what that actually means is hard to find out & the reliablity of such claims is unclear. In the case of a human sub-contractor (or any 3rd party you acquired a patch via) you can expect to have a number practical ways to do useful "due diligence" to gain confidence in the code you receive. Particularly if you work with someone over time you can increasingly build a strong trust relationship. This is materially different to a relationship with an AI which (at least with common tools today) can be more than a little bit inconsistent and unpredictable on an ongoing basis, making it hard to build up trust over time to the extent you would with a person. NB for trivial code the situation is somewhat different & simpler, as you can likely make a claim that trivial changes won't meet the threshold for copyright protection, whether from a human or AI. > And, frankly, there is very little > way we can detect if the code was AI-generated or written by a human > being. If we tried to make rules against GenAI, the practical effect > will be that people will just stop including notes telling us about > it. Discouraging transparency won't improve the situation at all. Given the direction of the tech industry in general wrt AI, IMHO, the absence of a written policy on AI generated contribution, will effectively soon imply a policy that the project accepts any & all use of AI. IOW, not making a decision on AI is effectively making a decision on AI. Maybe that is none the less right for Fedora, I can't say ? I think it important that we spend time to debate & investigate the different aspects, so we can judge whether we benefit from an explicit policy (whether it says to allow or deny or delegate it to contributors' judgement, or something else) or not. We may not be able to detect all AI based contributions, but I don't think that having such an ability needs to be a pre-requisite for defining an explicit policy, whatever it may state. The operation of Fedora, and OSS communities in general, is heavily reliant on trust built up organically between participants over time, and IMHO Fedora does fairly well in this respect. If we come up with a well reasoned policy on AI, we should broadly be able to expect our contributors to abide by it. If a small minority don't, they'll have to accept the consequences if someone notices, but if a large set don't then it could be a sign the policy was misguided & needs revisiting, which would at least have been a learning experiance for us all. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue