Re: [FFmpeg-devel] Sovereign Tech Fund

["Rémi Denis-Courmont" <remi@remlab.net>]

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-request@ffmpeg.org with subject "unsubscribe".