On Sun, Apr 28, 2019 at 11:02 PM 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? >
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 _______________________________________________ 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".
