[FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

[Marton Balint]

On Fri, 15 Mar 2019, Ronald S. Bultje wrote:

> Hi guys,
>
> On Thu, Mar 14, 2019 at 1:55 PM Yufei He <yhe at matrox.com> wrote:
>
>> Hi
>>
>> Here is the patch for a new H.264 codec with Matrox m264 card.
>>
>
> I want to bring up again that this library is closed-source. I don't think
> FFmpeg should link to closed-source software in its public mainline
> version. Matrox is obviously free :-) to maintain their own modified
> version as long as they comply with all licensing conditions.
>
> On IRC, we just discussed the following:
> - --enable-nonfree was initially intended for dealing sort of roughly with
> incompatible opensource licenses, for example AAC encoders or GPL +
> LGPL-compatible-but-LGPL-incomptible libraries;
> - nowadays, --enable-nonfree is also used for NDI (which Kieran sent a
> patch to remove already) and now this.
>
> I would like to request a vote amongst frequent developers (and if you
> don't count me amongst that, that's fine) to decide whether closed-source
> software integration in general, as well as this one in particular, is OK.
> I don't think the system library provision applies here, since you'll be
> hard-pressed to find a system with Matrox hardware (it's high-$$$
> enterprise stuff).

I think it is a mistake to tackle this from a licensing point of view 
because it is debatable what counts as a system library or what counts as 
a closed plugin of an LGPL library. Instead of debates about components we
will get debates about licensing. Totally pointless.

Therefore I don't think a generic vote about closed source is a good idea. 
To allow or not a certain closed source component is mostly subjective so 
doing a vote on a case by case basis seems the most fair to me. We don't 
have _that_ many closed source submissions.

When voting, the following can be considered by each voter:
- submitter reputation (past contributions/license awareness/maintenance capability)
- capability to build the component (headers/SDK price/licensing/NDA)
- capability to use the component (library/driver/HW price)
- component target (consumer/professional/enterprise)
- potentional user base

Regards,
Marton