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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3331 bytes --]

On Mon, Jul 07, 2025 at 02:35:38AM +0200, Marvin Scholz wrote:
> 
> 
> On 7 Jul 2025, at 2:10, Michael Niedermayer wrote:
> 
> > Hi
> >
> > On Mon, Jul 07, 2025 at 12:29:44AM +0200, Alexander Strasser via ffmpeg-devel wrote:
> >> Date: Mon, 7 Jul 2025 00:29:44 +0200
> >> From: Alexander Strasser <eclipse7@gmx.net>
> >> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [RFC] Introducing policies regarding "AI" contributions
> >>
> >> Hi Michael!
> >>
> >> On 2025-07-04 12:15 +0200, Michael Niedermayer wrote:
> >>> The use of tools to assist developers is growing and will
> >>> continue to grow. Its not going away.
> >>> And what one can and cannot do with these tools will evolve
> >>>
> >>> I dont think i understand the thought process behind this policy.
> >>
> >> I did not propose any policy in particular yet. So I'm not
> >> sure what you are referring to.
> >
> > a policy is premature.
> >
> >
> > [...]
> >
> >> More importantly I see no way for the license part to work out
> >> automagically. In how far is the result a derivative other works?
> >> How would we apply attribution where original works demand it?
> >> How do we now the generated code is not just a mostly exact copy
> >> of the original training material?
> >
> > How do you know that a student that was a tought C by teaching
> > materials licensed under AGPL will not produce work that falls under AGPL ?
> >
> > We should work on FFmpeg, review patches, fix bugs get the release done.
> > And let people use the tools that work best for them.
> >
> > I do not want to have to spend time to think about if the use of
> > tools (code completion?, some few line function prototype,
> > LLM that fixed spelling errors, ...)
> > requires a pariah mark on the patch or is "allowed"
> >
> > Such rules are IMHO not compatible with free software.
> >
> > It also would be another huge "go away" sign for the next generation
> > of developers.
> 

> IMHO if something is a huge "go away" it is the lack of a modern development
> workflow, like what a modern Git forge offers…

It seems we all dump our wishlists and ideas here so let me continue:

heres my wish list
1. an assistent that takes some work of my sholders so i have more time for ffmpeg
2. a static copy of trac
    chatgpt says this: "*Status is taken from the Trac notification e-mails mirrored on mail-archive.com, which still expose the ticket state even though the Trac web UI now sits behind an anti-bot challenge."
    when i give chatgpt a simple short question about ffmpeg bugs
    its bad as many people use chatgpt now as their primary source and not google (iam not sure actually if google still indexes it)
3. people merging or cherry picking forks
4. someone to convince carl to return and maintain trac
5. People realizing that maintaining the MAINTAINER file may help having maintainers ...
6. myself going to bed earlier and not writing this, that one was my fault ;)

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- 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".