Re: [FFmpeg-devel] Plugins architecture

[Michael Niedermayer <michael@niedermayer.cc>]

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

Hi Lynne

On Mon, Aug 11, 2025 at 09:22:26PM +0900, Lynne wrote:
[...]
> To me, at least, I can imagine five options:
> 
> Option 1 - we have an official binary plugin interface, free for
>            everyone to use with no limitation.

That requires someone to create that "binary plugin interface",
that person seems not existing, so i dont think its an "option"


> Option 2 - we have an official source plugin interface, free for
>            everyone to use with no limitations. This means that all
>            plugins are source-code based. External plugins would result
>            in a build with a different license - if one of the plugins
>            used was non-free, then the resulting build would be non
>            free.
>            Basically, the status quo now, only we would avoid breaking
>            interfaces like AVCodec.
>            The list of source plugins would not be maintained by us, but
>            could be a text file that users could share between.


> Option 3 - we have an official source plugin interface, free for
>            everyone to use, with license limitations. All source plugins
>            The list of source plugins would be maintained by us, and
>            policing of the list for violations (including using
>            dlopen() to workaround licensing) would be left to us.
>            The list of such plugins would be maintained by us.

Id like to point out that testing for dlopen() is a matter of
"git grep dlopen" after the "git merge" of teh plugins
Similarly we can require any specific license or contract text in a
plugin and can verify that automatically. (similar to fate-source)
Thus turning a non compliant plugin into a contract violation

Iam not sure we want or need any of that, just saying that if we want
then its a automated thing


> Option 4 - we have an official source plugins interface for repositories
>            maintained by FFmpeg developers. This means that for
>            developers interested in developing features outside of the
>            scope of the project, there would exist an interface which
>            would allow developers to conveniently maintain and
>            distribute their work as an optional extension for the
>            project.

These options do not seem exclusive
we can make a list of GPL/LGPL plugins maintained by ffmpeg developers

and a seperate list of GPL/LGPL plugins maintained by other developers


> 
> As a maintainer, I would like to avoid option 3 to the extent that I am more
> comfortable with fully liberalizing all plugins via option 1.
> 
> I would like to hear other options or suggestions that developers may have,
> and ultimately, if there's a consensus on the amount of options that that
> the project would benefit from having a plugins interface, a vote on the
> type of interface(s) we would maintain.

IIUC your intend is to avoid closed source / non free plugins.
I do think, what you push for here, will open the door primarly for
closed source / non free plugins.
So it seems to do the exact opposite of what you try to achieve.

Because if we dont have a reasonable complete list of plugins in
our repository, it will be outside and will contain all the non free,
corporate and closed source ones

thx

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

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