[FFmpeg-devel] [DECISION] Project policy on closed source components

[Jan Ekström]

On Sun, Apr 28, 2019 at 11:02 PM Marton Balint <cus at passwd.hu> wrote:
>
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened without general consensus, so a vote
> is necessary to justify the removal.
>
> So here is a call to the voting committee [1] to decide on the following
> two questions:
>
> 1) Should libNDI support be removed from the ffmpeg codebase?
>

Yes.

To give a reasoning for this, I have taken a quick look at the history
of enable-nonfree (first appearing in
3fe142e2555ec8b527f2ff4cc517c015a114e91a in January of 2008), and it
seems like its reasoning was to enable linking of (open source)
components that were already in the code base that were then found out
to not have technical limitations in their build which would follow
their incompatibility with LGPL, GPL or both (starting with the 3GPP
AMR-NB decoder wrapper added in
891f64b33972bb35f64d0b7ae0928004ff278f5b in May of 2003).

Later on, it would be utilized when similar incompatibilities were
found, of which at this point in time the Google published Fraunhofer
AAC decoder/encoder suite is probably the best known example of.
Before that there was the case where people happened to look into what
libfaac actually contained, and it was noticed that the library
actually contained the code from the reference implementation, making
it incompatible with its own license.

Following that quick check of things, I looked at the licenses of what
FFmpeg can be redistributably built under: LGPL versions 2.1 and 3, as
well as GPLv2 and 3. Thus, effectively the most limiting license of
these would be one of the versions of the GPL. Thus, in my opinion as
much of the code in FFmpeg should be compatible with LGPLv2.1+ and
GPLv2+. And thus we gain an understanding of what sort of closed
source software we can utilize within FFmpeg without limiting the
option in binary licenses for the user (basically, the poorly worded
things regarding things that come with the system - which is why
generally having schannel/dxva2|d3d11va/videotoolbox support is seen
as "alright"). Then, depending on the amount of working alternatives
that are under licenses which do not require additional limitations to
available configurations, and acceptance of the dependencies utilized,
we have components which require specific sets of configuration.
Examples of such would be:
- libaribb24 requires LGPLv3+ in its current git form, and GPLv3+ in
its current latest release form. There is an alternative, but it
requires porting of a custom glibc iconv module into the code base
first, so usage of the alternative is not realistic right away. Thus
one could argue that it might still be worth the while to have support
for this library in the code base.
- libfdk-aac is open source, and to my (admittedly hazy) understanding
the patent-related clause only affects GPL and not LGPL configurations
(due to the "no additional limitations" clause in the former?). There
are no open source alternatives providing similar level of quality for
HE-AAC, thus making it arguable that fdk-aac a worthwhile thing to
keep around.

Now, back to libNDI. Let's start with the side that in my opinion
looks more positive to it, and then move to the things where I see it
in a less positive way:

- libNDI does not have open source alternatives, which would be under
a license that could be used for a re-distributable binary.
- libNDI does have a use case and it could be argued that there is a
need for it in the community.

Just looking at these first two lines, I could still argue that it
might be worth it to have in the code base. But only if the basic
requirement regarding the dependency's licensing passes. libNDI's
state in my opinion is as follows:

- libNDI is closed source, and even according to the more generous
readings of the most strict license you can configure your FFmpeg
binary under (GPL) cannot be considered acceptable as it is not a
hardware driver interface, but rather just a network protocol
implementation.

Thus the general "is this OK" check for me does not get passed.
Decklink for example seems to pass since I see people being OK with
the hardware interface driver interpretation, and if I understand it
correctly the reason why it is under nonfree currently is due to the
SDK's poor licensing (?).

I would have loved to have had this discussion happen in 2017, before
libNDI support getting merged. That way this would not look like a
knee-jerk reaction to certain events during the last year or so. Alas,
that was not what happened. I am one of those guilty as charged for
one reason or another to have not replied into that thread. Maybe we
could have persuaded people to work on an open source alternative
implementation earlier, instead of now. Also this would have less
inconvenienced users who did have this wrapper in their FFmpeg code
base since 2017 for local usage.

In any case, I hope I have put my reasoning for my vote on the table
in a somewhat coherent way. Possible factual errors in it are not on
purpose, I can just have an incorrect understanding of some things -
just like any other human :) .

Best regards,
Jan