[FFmpeg-devel] [RFC] Introducing policies regarding "AI" contributions

[FFmpeg-devel] [RFC] Introducing policies regarding "AI" contributions

[Alexander Strasser via ffmpeg-devel]

[-- Attachment #1: Type: message/rfc822, Size: 7221 bytes --]

From: Alexander Strasser <eclipse7@gmx.net>
To: ffmpeg-devel@ffmpeg.org
Subject: [RFC] Introducing policies regarding "AI" contributions
Date: Tue, 1 Jul 2025 12:58:23 +0200
Message-ID: <aGO_T_HfuvhbgYoy@metallschleim.local>

Hi all,

I do not like the branding of the LLMs as AI, thus I will for now
continue to call it "AI" in quotes. I'm open for better terms.

It was just yesterday brought up on IRC in #ffmpeg-devel that there
was at least one, marked attempt to include "AI" generated code[1].

At least I would say that this particular patch series was rejected,
but there were was no explicit discussion and clear statement about
"AI" generated content; especially code.

Thus I want this thread to start a discussion, that eventually leads
to a policy about submitting and integrating "AI" generated content.

Leaving all ethical issues aside for a moment I still see 2 very big
problems with AI generated code:

* looks generally plausible but is often subtly wrong
    * leading to more work, regressions and costs
        * which often lands on a different group of people (other
          projects, reviewers, bug finders, bug fixers, etc.)
        * which are sometimes delayed for quite some time increasing
          the costs of fixing them
* license/copyright violations
    * this might be sometimes a non-issue with small changes
    * but especially for complete components the risk seems high

There is a lot more to the topic and I probably forgot to bring up
many more important aspects and details. Please feel free to bring
more things up in the discussion!

There was a preparation in the musl project to put up a policy[2],
it has not yet been finalized and realized as far as I understand.

It also brings up the point, that it is not really related to
recent "AI" tech, but more to the origin of work and its handling.
Unfortunately "AI" made problems with this a lot more common.


Best regards,
  Alexander

1. https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-April/342146.html
2. https://www.openwall.com/lists/musl/2024/10/19/3

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Introducing policies regarding "AI" contributions

[Gyan Doshi]

On 2025-07-01 04:28 pm, Alexander Strasser via ffmpeg-devel wrote:

 > Thus I want this thread to start a discussion, that eventually leads 
 > to a policy about submitting and integrating "AI" generated content.
In practice. unless a patch(set) is explicitly marked or has telltale 
signs of being AI-generated,the project can't stop such AI code getting in.
At best, we can require disclosure and for the human submitter to assume 
responsibility.

Regards,
Gyan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Introducing policies regarding "AI" contributions

[Kacper Michajlow]

On Tue, 1 Jul 2025 at 12:58, Alexander Strasser via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
>
>
>
> ---------- Forwarded message ----------
> From: Alexander Strasser <eclipse7@gmx.net>
> To: ffmpeg-devel@ffmpeg.org
> Cc:
> Bcc:
> Date: Tue, 1 Jul 2025 12:58:23 +0200
> Subject: [RFC] Introducing policies regarding "AI" contributions
> Hi all,
>
> I do not like the branding of the LLMs as AI, thus I will for now
> continue to call it "AI" in quotes. I'm open for better terms.
>
> It was just yesterday brought up on IRC in #ffmpeg-devel that there
> was at least one, marked attempt to include "AI" generated code[1].
>
> At least I would say that this particular patch series was rejected,
> but there were was no explicit discussion and clear statement about
> "AI" generated content; especially code.
>
> Thus I want this thread to start a discussion, that eventually leads
> to a policy about submitting and integrating "AI" generated content.

I don't think labeling code as "AI" matters that much. Let's ignore
licensing/legal issues for now.

What's important is the code itself and its quality. It doesn't matter
how it was created. Whether by a human, "AI" or something else. The
key is the final product. "AI" is just a tool, and like any tool, it
can be used well or poorly. How you use it may be completely different
between "operators".

I think the "AI" label exists because the code that LLMs produce is
often incomplete, low quality, and a pile of spaghetti that somehow
works for a single use case. but is far from being a sane, production
ready implementation. Anyone who has used these tools knows their
limitations and what they can or cannot do.

That said, if "AI" code means low quality code, then by all means, it
should be rejected. This applies to human, alien, or "AI" generated
code. There shouldn't be a different metric for "AI" code. If "AI"
(and its "operator") produces high quality code, there's no reason to
reject it.

After all, how can you even detect "AI" code? If the code, regardless
of who or what wrote it, follows project guidelines and is overall
high quality, that's all that matters.

P.S. I don't like those "This code was fully made by an LLM"
statements and the like. Who cares? Maybe some investor who's pushing
this. But from a technical point of view, there's no difference. After
all, you don't start your patchset by saying, "This code was written
in Vim with <list of plugins> on Arch Linux, on an ergonomic split
keyboard, with an XYZ monitor.".

- Kacper

> Leaving all ethical issues aside for a moment I still see 2 very big
> problems with AI generated code:
>
> * looks generally plausible but is often subtly wrong
>     * leading to more work, regressions and costs
>         * which often lands on a different group of people (other
>           projects, reviewers, bug finders, bug fixers, etc.)
>         * which are sometimes delayed for quite some time increasing
>           the costs of fixing them
> * license/copyright violations
>     * this might be sometimes a non-issue with small changes
>     * but especially for complete components the risk seems high
>
> There is a lot more to the topic and I probably forgot to bring up
> many more important aspects and details. Please feel free to bring
> more things up in the discussion!
>
> There was a preparation in the musl project to put up a policy[2],
> it has not yet been finalized and realized as far as I understand.
>
> It also brings up the point, that it is not really related to
> recent "AI" tech, but more to the origin of work and its handling.
> Unfortunately "AI" made problems with this a lot more common.
>
>
> Best regards,
>   Alexander
>
> 1. https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-April/342146.html
> 2. https://www.openwall.com/lists/musl/2024/10/19/3
>
>
>
> ---------- Forwarded message ----------
> From: Alexander Strasser via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
> To: ffmpeg-devel@ffmpeg.org
> Cc: Alexander Strasser <eclipse7@gmx.net>
> Bcc:
> Date: Tue, 1 Jul 2025 12:58:23 +0200
> Subject: [FFmpeg-devel] [RFC] Introducing policies regarding "AI" contributions
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".