[FFmpeg-devel] Sovereign Tech Fund

[Kieran Kunhya]

> This is also why there's no need to review the invoices, and no risk of a
> legitimate invoice being rejected: Because the deliverable will likely be
> the commit (unless the GA objects beforehand and asks SPI to use something
> else), so until it (the MR/PR) is accepted, there's no invoice to start
> with. And as STF is footing the bill, there's no reason to FFmpeg concern
> itself if it turned out expensive or not when reviewing, and can focus in
> actually improving the program (SPI and STF will place some budget limits,
> so contributors/contractors know what to expect and the money won't run
> out).
>

Of course we need to be concerned about this, FFmpeg isn't a think tank for
people's fun developments with public money from STF. The same applies to
donated funds, we have a responsibility as a community to spend the money
for community purposes.
You're not doing SPI any favours here with these comments.

Kieran

On Mon, Jan 29, 2024, 12:02 Kieran Kunhya <kierank at obe.tv> wrote:
>
>>
>>> >> [...] the GA definitly cannot object to an invoice for a project that
>>> the GA approved previously.
>>> > "The General Assembly is sovereign and legitimate for all its
>>> decisions regarding the FFmpeg project."
>>>
>>> When working with a contract (and a SOW), the General Assembly won't be
>>> able to block an invoice.
>>> Because the General Assembly will already have exercised its sovereignty
>>> before the work started.
>>> And unless the GA becomes a nation, any court of law would uphold the
>>> contract.
>>>
>>
>> In this project, acceptance of a patch is based on the technical contents
>> of a patch, not a few vague paragraphs in a SoW. These decisions are made
>> by the Technical Committee and the General Assembly.
>>
>> Tying the project contractually is unacceptable.
>>
>> There are plenty of "corporate" open source projects where this is fine,
>> but there is a reason we are not one of those full of corporate friendly
>> code like binary blobs, intrinsics, SDKs etc.
>>
>> Kieran
>>
>>>