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

Philip Langdale philipl at overt.org
Sun May 5 19:06:05 EEST 2019


On Sun, 28 Apr 2019 22:02:11 +0200 (CEST)
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?

I'm conflicted. I agree they violated the licence and they have to
answer for that, but the decision to remove it has negatively affected
end users who didn't do anything wrong, and respected the licence as
understood. Additionally, I'm uncomfortable with the idea that it's
being removed because we say it should never have been there in the
first place, rather than as a direct response to the licence violation.
You might consider that simply playing with semantics but I don't like
the idea of moving the goal posts. At least if you say support was
removed due to licence violations you make it clear why it's happening.

So, I guess I'm voting NO in terms of how and why it was done, and I'd
want a proper discussion of how to do it that and what the basis was.

> 2) Should patches using closed source libraries which are not
> considered "System Libraries" according to the GPL be rejected?

I know the question was withdrawn, but this speaks to the issue of
making sure we understand why we're accepting or rejecting something.
We could say "we'll reject any patches that are LGPL incompatible" which
would obviously cover rejection on this basis, but it would also lead
to rejecting other open-source components which we think we are
comfortable with. We're then left trying to define what we will and
won't accept on less precise terms, which leads to the difficulty we
have today. You could say "any submissions must be covered by one of
the following open source licences", but that will actually allow
things that we seem not to want - like a BSD licenced dynamic loader
for a closed source library - that's clearly a BSD licenced submission
that is LGPL incompatible. Seems messy. It would be easier to construct
a policy if we didn't have LGPL-incompatible open-source components.

> Deadline for voting is 7 days from now.
> 
> Thanks,
> Marton
> 
> [1]
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html
> _______________________________________________ ffmpeg-devel mailing
> list ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".



--phil


More information about the ffmpeg-devel mailing list