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

Reply via email to