On Sun, 28 Apr 2019 22:02:11 +0200 (CEST) Marton Balint <c...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". --phil _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
