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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
