[FFmpeg-devel] Sovereign Tech Fund
Rémi Denis-Courmont
remi at remlab.net
Sun Jan 28 21:17:03 EET 2024
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/
More information about the ffmpeg-devel
mailing list