[FFmpeg-devel] patch for a new H.264 codec

[Ronald S. Bultje]

Hi,

On Mon, Mar 11, 2019 at 12:21 PM Soft Works <softworkz at hotmail.com> wrote:

> > From: Nicolas George
> >
> > Yufei He (12019-03-11):
> > > Matrox M264 is similar to other hardware codecs.
> > >
> > > I saw amf_load_library and nvenc_load_library in ffmpeg.
> >
> > Past practices do not constitute precedents.
> >
> > > We got a lot customers using ffmpeg and they want to use Matrox M264
> to do transcoding.
> >
> > If you make the driver GPL-compatible, there will be no problem at all.
> >
> > Regards,
> >
> > --
> >   Nicolas George
>
> While I don’t care much about Matrox, I’m a bit surprised about the
> recent sounds here. Should  we expect ffmpeg to drop most hw
> accelerations, then?
>
> IANAL, but aren’t drivers clearly considered to be system components?
> In this case they would  be exempted from the GPL afaic?
>

Getting very legal here for someone who's not a lawyer :), but my reading
of the GPL is not that it says "something that acts at system level" (e.g.
hardware), but something that is provided by the base system (i.e. you can
assume it to be installed in some way shape or form regardless of the exact
license that it is accompanied by). For example, you can assume your system
has a libc, even though it might not be a GPL libc.

However, my objection is not legal, it is philosophical. I would prefer
that we (FFmpeg) as a project do not encourage the use of closed-source
software or endorse particular closed-source software (by including support
for it in FFmpeg). We are an open source project, and thus (again: in my
personal opinion) we should only endorse other open source software. That
does not mean closed source software is bad or should not be used. It
merely means we do not endorse it by including support for it.

Ronald