From: Kacper Michajlow <kasper93-at-gmail.com@ffmpeg.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Cc: Alexander Strasser <eclipse7@gmx.net> Subject: Re: [FFmpeg-devel] [RFC] Introducing policies regarding "AI" contributions Date: Tue, 1 Jul 2025 14:44:15 +0200 Message-ID: <CABPLASS=83bYC++P8QxLvdMZtnd5Rifzt9a6Ka6jb14-gzRo5w@mail.gmail.com> (raw) In-Reply-To: <mailman.4919.1751367511.1384.ffmpeg-devel@ffmpeg.org> 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".
prev parent reply other threads:[~2025-07-01 12:44 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-07-01 10:58 Alexander Strasser via ffmpeg-devel 2025-07-01 11:20 ` Gyan Doshi 2025-07-01 12:44 ` Kacper Michajlow [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CABPLASS=83bYC++P8QxLvdMZtnd5Rifzt9a6Ka6jb14-gzRo5w@mail.gmail.com' \ --to=kasper93-at-gmail.com@ffmpeg.org \ --cc=eclipse7@gmx.net \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git