Le sunnuntaina 28. tammikuuta 2024, 5.25.49 EET Michael Niedermayer a écrit : > Please read the following to get a better understanding what STF is about: > (In short it is about maintenance and sustainability, not features) > https://www.sovereigntechfund.de/programs/applications > > As some probably already know, Thilo has worked with STF to work out > many details of this. SPI will handle the financials for FFmpeg.
As anybody who's been following FFmpeg-devel knows, people have pointed out SPI seems like a poor choice of vehicle for that sort of commission. I won't repeat the arguments that were already made in the second half of last year. But I will add a few comments... > Everyone willing to benefit from this sponsorship must not be a US sanctioned > entity or in a US sanctioned country. In other words, the choice of a US vehicle is excluding people who are, or fear that they may be affected by US sanctions. Some active developers are associated with, for example, the Chinese Academy of Science, Huawei Technologies or other Chinese IT R&D entites. This is discriminatory, and thus something that an open-source project should actively seek to *avoid*. German government funding should go to German or at least EU-based entities if only for that reason. In other words, by going through SPI, Thilo is *unnecessarily* bringing ugly politics into an open-source project. (And please don't shoot the messenger here.) > At this point, what we need is a list of Projects so we can submit an > application to STF at or before 12th Feb. (at the 14th they have a meeting > and will review our submission) What STF told us, they need ATM is: The "selection criteria" seem rather restrictive. It seems that critical tasks such as long-term maintainance (Anton) and security fixes (you) are in scope. Though I can only agree with Kieran that SoW is ill-suited for tasks of the sort. If SPI insists on SoW, which is somewhat understandable from their legal and moral standpoint, then that is another reason why SPI should not, or maybe, cannot, be the vehicle. By stretching the criteria a little, maybe reasonably expected external or normative updates are also in scope, like say implementing optimisations for new ISA extensions or new codec profiles. But implementing entirely new features seems unambiguously excluded, especially if competing with existing open-source projects. Prototypes are also *explicitly* excluded. So for the sake of the argument, reimplementing X264, dav1d or GNU/radio functionality in FFmpeg seems like it would not qualify. I am not a lawyer, but there may be nontrivial legal implications for SPI and the contractees here. Note that I do not mean to argue against the restrictions here. They make perfect sense considering that this funding would ultimately come from the German tax payers. (...) > My suggestion is that we create a Trac WIKI page similar to the ideas > page for GSoC. > On that page everyone can add a project idea. > The requirement is that > 1. it must fit in the goals and mission and all of STF > 2. it must be about FFmpeg (IIUC non coding tasks are ok) IIUC, they are *not* OK, unless they are a dependency of a coding task: | Development is our primary focus, although security audits, conference | attendance, and other community-based events can be included in the | application should they be necessary. -- レミ・デニ-クールモン http://www.remlab.net/ _______________________________________________ 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".
