Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Hello everyone! (no meaning attached to which mail I respond to) While it reads less bad today than it did yesterday night, please try to keep the things written in the code of conduct in mind, assume best intentions etc., this thread didn't quite live up to it IMO. It's possible to state even strong disagreement in more respectful ways. If you permit, I'd also suggest that people in favour of removal take the win and don't push it - having a majority should be no excuse for making it a "tyranny of the majority". If one wants an actual working community, minorities (of any form) sometimes need to be respected and get concessions beyond what they can get by votes (ignoring the technical question here). And for anyone in favour of votes I hope it shows why votes are a bad idea: they don't resolve the conflict and there's at least one loser. Don't call them if you have other options. Compromise and consesus is always better. Though I admit a way to ask the mood more like a poll sounds interesting to me, maybe even anonymous? Best regards, Reimar Döffinger ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Mon, May 13, 2019 at 10:53 PM Carl Eugen Hoyos wrote: > > > Release branches provide a guarantee of API, ABI and feature > > stability. > > And we sadly did not always hold that guarantee=-( Mistakes have been made. We shall strive to be better in the future, and not use them as an excuse to push an agenda. > > > We shall not violate that for some petty feud. > > I wonder if this isn't exactly a case where it should be violated. > Contrary to the cases where we - unfortunately - have > violated it in the past. > No, we shall not. ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Am Mo., 13. Mai 2019 um 22:46 Uhr schrieb Hendrik Leppkes : > > On Mon, May 13, 2019 at 10:37 PM Carl Eugen Hoyos wrote: > > > > Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer : > > > > > > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: > > > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer > > > > : > > > >> > > > >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > > > >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint > > > >>> : > > > > > > 1) Should libNDI support be removed from the ffmpeg codebase? > > > > > > Thanks for the votes, I counted 9 yes, 5 no, so majority is for > > > removal of > > > libNDI, which is already done. > > > >>> > > > >>> The vote was not about the removal from libndi from release branches? > > > >> > > > >> No, features on releases are frozen, as changing them can result in > > > >> breakages for distros and package managers. > > > > > > > > We have broken distros and packages before, we would not break it > > > > in this case;-) > > > > > > We would. Distros and scripts would be broken, and it would not be pretty. > > > > Would you please be so kind as to explain (if possible in detail) how > > this would be possible in this specific case? > > I do not understand how removing a non-free dependency can break a > > binary distribution. > > > > There are other people that use and build ffmpeg, and track release > branches. But not distributions as claimed above. > And they may as well be building only for themselves a > non-free binary. Absolutely. And they can still do that after reverting a possible removal but they would realize that we are not endorsing the library anymore. > Release branches provide a guarantee of API, ABI and feature > stability. And we sadly did not always hold that guarantee=-( > We shall not violate that for some petty feud. I wonder if this isn't exactly a case where it should be violated. Contrary to the cases where we - unfortunately - have violated it in the past. Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 5/13/2019 5:36 PM, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer : >> >> On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: >>> Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : > >>> 1) Should libNDI support be removed from the ffmpeg codebase? >> >> Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal >> of >> libNDI, which is already done. > > The vote was not about the removal from libndi from release branches? No, features on releases are frozen, as changing them can result in breakages for distros and package managers. >>> >>> We have broken distros and packages before, we would not break it >>> in this case;-) >> >> We would. Distros and scripts would be broken, and it would not be pretty. > > Would you please be so kind as to explain (if possible in detail) how > this would be possible in this specific case? > I do not understand how removing a non-free dependency can break a > binary distribution. > We have removed tons of libraries before and it's always limited to git master. >>> >>> None of them had to be removed because the authors chose to >>> violate our copyright (and refused to fix the copyright violation) >>> so we decided to stop endorsing them. >> >> If you feel strong about it > > I don't, I just wonder how your interpretation of the question > is more obvious than mine. > >> and if you think it justifies breaking >> releases and pissing off distros and package managers handling half a >> decade old well tested LTS releases, you can start a vote to remove it >> from releases. > > Again: Please elaborate! No, i wont. I'm tired of you having something in mind but never saying it. You have a reason to think distros will not be affected? State it. If it's right, then you stopped an argument before it started. Don't try to lead the other party to reach to the same conclusion you came to when a single paragraph can prevent it. It wastes time and patience, and the latter is something people on this list have run out of long ago. The vote was to make the removal that already took place official. If you want it gone from release branches, start a vote for it explaining why something that exceptional should be done and why it would not be an issue. As i said, i don't think you'll have a hard time harvesting positive votes for it knowing the above precedent. ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Mon, May 13, 2019 at 10:37 PM Carl Eugen Hoyos wrote: > > Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer : > > > > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: > > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : > > >> > > >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > > >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint > > >>> : > > > > 1) Should libNDI support be removed from the ffmpeg codebase? > > > > Thanks for the votes, I counted 9 yes, 5 no, so majority is for > > removal of > > libNDI, which is already done. > > >>> > > >>> The vote was not about the removal from libndi from release branches? > > >> > > >> No, features on releases are frozen, as changing them can result in > > >> breakages for distros and package managers. > > > > > > We have broken distros and packages before, we would not break it > > > in this case;-) > > > > We would. Distros and scripts would be broken, and it would not be pretty. > > Would you please be so kind as to explain (if possible in detail) how > this would be possible in this specific case? > I do not understand how removing a non-free dependency can break a > binary distribution. > There are other people that use and build ffmpeg, and track release branches. And they may as well be building only for themselves a non-free binary. Release branches provide a guarantee of API, ABI and feature stability. We shall not violate that for some petty feud. - Hendrik ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer : > > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : > >> > >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : > > 1) Should libNDI support be removed from the ffmpeg codebase? > > Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal > of > libNDI, which is already done. > >>> > >>> The vote was not about the removal from libndi from release branches? > >> > >> No, features on releases are frozen, as changing them can result in > >> breakages for distros and package managers. > > > > We have broken distros and packages before, we would not break it > > in this case;-) > > We would. Distros and scripts would be broken, and it would not be pretty. Would you please be so kind as to explain (if possible in detail) how this would be possible in this specific case? I do not understand how removing a non-free dependency can break a binary distribution. > >> We have removed tons of > >> libraries before and it's always limited to git master. > > > > None of them had to be removed because the authors chose to > > violate our copyright (and refused to fix the copyright violation) > > so we decided to stop endorsing them. > > If you feel strong about it I don't, I just wonder how your interpretation of the question is more obvious than mine. > and if you think it justifies breaking > releases and pissing off distros and package managers handling half a > decade old well tested LTS releases, you can start a vote to remove it > from releases. Again: Please elaborate! Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : >> >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : On Sun, 28 Apr 2019, Marton Balint 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? > Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of libNDI, which is already done. >>> >>> The vote was not about the removal from libndi from release branches? >> >> No, features on releases are frozen, as changing them can result in >> breakages for distros and package managers. > > We have broken distros and packages before, we would not break it > in this case;-) We would. Distros and scripts would be broken, and it would not be pretty. > >> We have removed tons of >> libraries before and it's always limited to git master. > > None of them had to be removed because the authors chose to > violate our copyright (and refused to fix the copyright violation) > so we decided to stop endorsing them. If you feel strong about it, and if you think it justifies breaking releases and pissing off distros and package managers handling half a decade old well tested LTS releases, you can start a vote to remove it from releases. Seeing the outcome of the above vote, i wouldn't be surprised if such a vote gets a positive result as well. > >> The vote was to make the removal official > > Sorry, but I find this interpretation extremely difficult from the quote > above, I think "Also the removal of libNDI happened without general consensus, so a vote is necessary to justify the removal." is pretty clear with its usage of words like "happened". ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer : > > On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > > Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : > >> > >> On Sun, 28 Apr 2019, Marton Balint 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? > >>> > >> > >> Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of > >> libNDI, which is already done. > > > > The vote was not about the removal from libndi from release branches? > > No, features on releases are frozen, as changing them can result in > breakages for distros and package managers. We have broken distros and packages before, we would not break it in this case;-) > We have removed tons of > libraries before and it's always limited to git master. None of them had to be removed because the authors chose to violate our copyright (and refused to fix the copyright violation) so we decided to stop endorsing them. > The vote was to make the removal official Sorry, but I find this interpretation extremely difficult from the quote above, Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote: > Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : >> >> On Sun, 28 Apr 2019, Marton Balint 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? >>> >> >> Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of >> libNDI, which is already done. > > The vote was not about the removal from libndi from release branches? No, features on releases are frozen, as changing them can result in breakages for distros and package managers. We have removed tons of libraries before and it's always limited to git master. The vote was to make the removal official, as stated in the first email quoted above, since some people were not happy it was done without a formal vote. ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint : > > On Sun, 28 Apr 2019, Marton Balint 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? > > > > Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of > libNDI, which is already done. The vote was not about the removal from libndi from release branches? Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Marton Balint 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? Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of libNDI, which is already done. Regards, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Marton Balint 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? No. Regards, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, Apr 28, 2019 at 11:02 PM Marton Balint 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
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 28/04/2019 21:02, Marton Balint wrote: > 1) Should libNDI support be removed from the ffmpeg codebase? Yes. - Mark ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019 22:02:11 +0200 (CEST) Marton Balint 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Marton Balint > Sent: Monday, April 29, 2019 4:02 AM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [DECISION] Project policy on closed source > components > > 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 > 2) Should patches using closed source libraries which are not considered > "System Libraries" according to the GPL be rejected? > > Deadline for voting is 7 days from now. Yes. (Looks it is a good chance to have a good summary (or guide) about the whole vote process, including which case can trigger a vote, how to define a vote period， how to remove vote committee who are not active and add new committee, and so on ) ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 03.05.2019, at 20:16, Michael Niedermayer wrote: > On Fri, May 03, 2019 at 11:08:35AM +0200, Carl Eugen Hoyos wrote: >> Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick >> : > >> And finally: What do you suggest to "punish the violator"? > > while this question wasnt directed at me ... > > Compete with it, provide a better product for a lower price, as in like a > free open replacement. If you succeed the majority of people will be happy. > > Its better to replace a feature by a supperior or equivalent one than to > just remove it. I agree with the idea, but it becomes a VERY unfair competition when one side enforces their "IP" rights beyond their legal rights (while ignoring any one else's) and the other side does nothing. "What's mine is mine and what's yours is also mine" is not really competition. From a quick read that seems to be the majority objection here... ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Mon, Apr 29, 2019 at 4:02 AM Marton Balint 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 > > 2) Should patches using closed source libraries which are not considered > "System Libraries" according to the GPL be rejected? > Yes Thanks. ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
> 在 2019年5月4日，上午9:32，Peter Ross 写道： > >> On Fri, May 03, 2019 at 10:43:36AM -0700, Baptiste Coudurier wrote: >> >>> On May 3, 2019, at 1:15 AM, Paul B Mahol wrote: >>> >>> On 4/28/19, Marton Balint 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, yes. >> >> Yes > > Yes Yes > 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? >>> >>> Yes, yes, yes. >> >> Yes > > Yes. Yes > > -- Peter > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Fri, May 03, 2019 at 10:43:36AM -0700, Baptiste Coudurier wrote: > > > On May 3, 2019, at 1:15 AM, Paul B Mahol wrote: > > > > On 4/28/19, Marton Balint 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, yes. > > Yes Yes. > >> 2) Should patches using closed source libraries which are not considered > >> "System Libraries" according to the GPL be rejected? > > > > Yes, yes, yes. > > Yes Yes. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Fri, May 03, 2019 at 11:08:35AM +0200, Carl Eugen Hoyos wrote: > Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick > : > > > In this case NDI took prompt action and removed the said binaries from > > their website immediately. > > This is not true, please stop spreading this wrong claim. > > > A similar violation was done by Amazon some time back > > (https://trac.ffmpeg.org/ticket/7214) and > > we closed that issue as Amazon took down binaries from their website and > > provided the source > > code of their plugin > > Yes. > Note that as somebody who is rather outspoken but not a native speaker > your email sounds to > me as if you are trying to bad-mouth Amazon: Do you believe that they > did not handle above > ticket correctly? Or do I simply misunderstand? > > > (In this case, NDI plugin is already open source). > > No. > If this were true, there would be no license violation. > > Do I understand correctly that you write twice in your long text that > the license violation is > ongoing, but not done by NDI? This would make no sense to me, could > you elaborate? > > And finally: What do you suggest to "punish the violator"? while this question wasnt directed at me ... Compete with it, provide a better product for a lower price, as in like a free open replacement. If you succeed the majority of people will be happy. Its better to replace a feature by a supperior or equivalent one than to just remove it. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
> On May 3, 2019, at 1:15 AM, Paul B Mahol wrote: > > On 4/28/19, Marton Balint 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, yes. Yes > >> >> 2) Should patches using closed source libraries which are not considered >> "System Libraries" according to the GPL be rejected? > > Yes, yes, yes. Yes — Baptiste ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Fri, 3 May 2019, at 07:27, Jeyapal, Karthick wrote: > Open source violation by NDI is a serious issue that needs to be > addressed. But removing the libndi plugin from the ffmpeg repository > will not address the issue of violation. A willful violator can still You are confusing 2 things: - the violation of FFmpeg and x264 license from NDI, and the usual hostility of Newtek towards our community, - the violation of this project ideas by allowing linking a completely-closed source library. Problem [1] made a lot of people look at problem [2], because not many people had looked at it closely. Because of [1], people looked at [2] and realized that this was not OK, and different from the rest of the FFmpeg project, especially since we refused librmhd and other closed-source libraries. So please don't make it a vote about [1], when it is a vote about [2]. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Fri, 3 May 2019 at 15:24, Kieran Kunhya wrote: > > > > > > Kieran, > > > > Can you point to evidence on the same? An active legal threat to "a > > developer writing an open source implementation of NDI"? > > > > With that in place, it wouldn't be ignored as a material fact, would it? > > > > https://trac.ffmpeg.org/ticket/7589 > > Discussed in there. A few people in the community can corroborate this. > But it's not the job of the person who was threatened to publicise this in > detail. > > Kieran > Thanks for the clarification, Kieran. The evidence provided (including the corroboration) is absolutely satisfactory. ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
> > > Kieran, > > Can you point to evidence on the same? An active legal threat to "a > developer writing an open source implementation of NDI"? > > With that in place, it wouldn't be ignored as a material fact, would it? > https://trac.ffmpeg.org/ticket/7589 Discussed in there. A few people in the community can corroborate this. But it's not the job of the person who was threatened to publicise this in detail. Kieran ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick : > In this case NDI took prompt action and removed the said binaries from their > website immediately. This is not true, please stop spreading this wrong claim. > A similar violation was done by Amazon some time back > (https://trac.ffmpeg.org/ticket/7214) and > we closed that issue as Amazon took down binaries from their website and > provided the source > code of their plugin Yes. Note that as somebody who is rather outspoken but not a native speaker your email sounds to me as if you are trying to bad-mouth Amazon: Do you believe that they did not handle above ticket correctly? Or do I simply misunderstand? > (In this case, NDI plugin is already open source). No. If this were true, there would be no license violation. Do I understand correctly that you write twice in your long text that the license violation is ongoing, but not done by NDI? This would make no sense to me, could you elaborate? And finally: What do you suggest to "punish the violator"? Sorry, your mail is very difficult to understand, Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 5/3/19, Gyan wrote: > > > On 29-04-2019 01:32 AM, Marton Balint wrote: >> 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? > > No. > Yes. > Gyan > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 29-04-2019 01:32 AM, Marton Balint wrote: 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? No. Gyan ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Fri, May 3, 2019, 10:22 Kieran Kunhya wrote: > On Fri, 3 May 2019, 06:27 Jeyapal, Karthick, wrote: > > > > > On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote: > > > > > (In this case, NDI plugin is already open source). > > > This is untrue. > > Furthermore, I am amazed you are all ignoring the fact this is an Open > Source hostile company, actively sending legal threats to a developer > writing an Open Source implementation of NDI. > > Kieran > Kieran, Can you point to evidence on the same? An active legal threat to "a developer writing an open source implementation of NDI"? With that in place, it wouldn't be ignored as a material fact, would it? ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 4/28/19, Marton Balint 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, yes. > > 2) Should patches using closed source libraries which are not considered > "System Libraries" according to the GPL be rejected? Yes, yes, yes. > > 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". ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Fri, 3 May 2019, 06:27 Jeyapal, Karthick, wrote: > > On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote: > > > (In this case, NDI plugin is already open source). This is untrue. Furthermore, I am amazed you are all ignoring the fact this is an Open Source hostile company, actively sending legal threats to a developer writing an Open Source implementation of NDI. Kieran ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, Apr 28, 2019 at 4:02 PM Marton Balint 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? No. My thoughts (All thoughts expressed are solely mine, and does not represent the company I work for) : Open source violation by NDI is a serious issue that needs to be addressed. But removing the libndi plugin from the ffmpeg repository will not address the issue of violation. A willful violator can still distribute ffmpeg binaries with his own copy of libndi plugin(or any other non-free code). In this case NDI took prompt action and removed the said binaries from their website immediately. A similar violation was done by Amazon some time back (https://trac.ffmpeg.org/ticket/7214) and we closed that issue as Amazon took down binaries from their website and provided the source code of their plugin(In this case, NDI plugin is already open source). We didn't remove x264 plugin from ffmpeg because Amazon violated the GPL terms. Just because the violator here(Newtek) is the manufacturer of the hardware that utilizes the libndi plugin we don't have to remove it. By removing libndi we are achieving the following. - Punishing the lawful users of the libndi plugin - Nothing done to prevent the willful license violation of ffmpeg - Punishing NDI by removing their plugin from ffmpeg (An inconvenience for them, to maintain and distribute the libndi plugin sources separately) As per any rule of law, the innocents' rights will have to be protected first. In this case the rights of lawful users of libndi plugin should be protected. The violator will have to be punished without punishing the lawful users. Whatever punishment we come up with should be applicable to all violators, including those who don't have a plugin in ffmpeg repo that interacts with the violator's hardware(like Amazon's example). Regards, Karthick ___ 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". ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Am Do., 2. Mai 2019 um 12:30 Uhr schrieb Timo Rothenpieler : > > On 28/04/2019 22:02, Marton Balint wrote: > > 1) Should libNDI support be removed from the ffmpeg codebase? > > No What do you suggest instead? Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 28/04/2019 22:02, Marton Balint 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? No 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? They should have a very good reason to be included, but not generally be rejected just on that basis. On the example of NDI, its widespread use in video equipment and lack of alternatives gives it plenty of reason to be part of FFmpeg. So if this was still for vote in the current form, I'd say "No" here as well. smime.p7s Description: S/MIME Cryptographic Signature ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Marton Balint (12019-04-28): > 1) Should libNDI support be removed from the ffmpeg codebase? Yes. > 2) Should patches using closed source libraries which are not considered > "System Libraries" according to the GPL be rejected? Yes to that too, even though the vote was withdrawn pending clarification. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 4/29/2019 1:34 AM, Gyan wrote: > > > On 29-04-2019 05:37 AM, Marton Balint wrote: >> >> >> On Sun, 28 Apr 2019, Marton Balint 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? >>> >>> 2) Should patches using closed source libraries which are not >>> considered "System Libraries" according to the GPL be rejected? >> >> I revoke the vote request on the 2nd question (some invalid references >> and ambiguity was pointed out in it), please only vote on the 1st. >> Second question will be rephrased and submitted to a vote later, in a >> different thread. > > For those new to voting, what's the procedure? > > Gyan Reply to the first email in the thread with a yes or a no to the issue subjected to a vote. In this case, only the 1) question. See what Ronald did just now. ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Hi, On Sun, Apr 28, 2019 at 4:02 PM Marton Balint 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. Ronald ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Mon, Apr 29, 2019 at 8:35 PM Marton Balint wrote: > We can't really change this for the better unless there is a somewhat > "recognized" authority which has the power to make decisions, rules, and > enforce them. > > I hoped that this can be the voting comitte. The voting commitee is pretty much everyone, and as such way too many people. I would've preferred a small "steering board" of maybe 5 people or whatever you like to call it, but in the meeting this was decided in, a vote choose otherwise... :) - Hendrik ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-29 20:34 GMT+02:00, Marton Balint : > Voting is important, because people typically accept > majority decisions even if they don't agree with them. Sounds like an interesting argument. > I believe that this is why several people including > me expressed that NDI removal should only have > happened after a vote. This still sounds to me as if you believe there would have been an alternative to removing the library. Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Marton Balint (12019-04-29): > At the moment, it looks to me that FFmpeg is a community without leadership, > enforced rules and consequences. In fact, I consider this the main reason > why people consider working in it an unfriendly experience. > > We can't really change this for the better unless there is a somewhat > "recognized" authority which has the power to make decisions, rules, and > enforce them. I fully agree with that analysis. > I hoped that this can be the voting comitte. But not that point: the voting committee is too large to ac as an executive body. It cannot act efficiently on small decisions. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote: 2019-04-29 1:02 GMT+02:00, Marton Balint : On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote: 2019-04-28 22:02 GMT+02:00, Marton Balint : 1) Should libNDI support be removed from the ffmpeg codebase? This sounds to me as if you know of an alternative to not endorsing a company that profits from FFmpeg while at the same time violating the copyright of the FFmpeg developers? What could this alternative be? We could list them on our webpage hall of shame, or whatever. Could you be more specific? Both about the "webpage" and about our suggested message of both endorsing and shaming a software company at the same time? To be frank, I consider this vote to be more important for our project/community to make sure everyone's voice is heard, than the actual outcome. I probably fail to parse this sentence as it makes no sense whatsoever to me;-( At the moment, it looks to me that FFmpeg is a community without leadership, enforced rules and consequences. In fact, I consider this the main reason why people consider working in it an unfriendly experience. We can't really change this for the better unless there is a somewhat "recognized" authority which has the power to make decisions, rules, and enforce them. I hoped that this can be the voting comitte. Voting is important, because people typically accept majority decisions even if they don't agree with them. I believe that this is why several people including me expressed that NDI removal should only have happened after a vote. If we don't vote about this, but simply accept that somebody pushed this without consensus, then it is a dangerous precedent, one that will only prove that you don't really have to play by the rules here. So that is what I mean, when I write that voting about this is important for the community. Because the NDI issue and the way it was handled is a manifestation of our bigger problems. Regards, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-29 1:02 GMT+02:00, Marton Balint : > > On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote: > >> 2019-04-28 22:02 GMT+02:00, Marton Balint : >> >>> 1) Should libNDI support be removed from the ffmpeg codebase? >> >> This sounds to me as if you know of an alternative to not endorsing >> a company that profits from FFmpeg while at the same time >> violating the copyright of the FFmpeg developers? >> What could this alternative be? > > We could list them on our webpage hall of shame, or whatever. Could you be more specific? Both about the "webpage" and about our suggested message of both endorsing and shaming a software company at the same time? > To be frank, I consider this vote to be more important for our > project/community to make sure everyone's voice is heard, > than the actual outcome. I probably fail to parse this sentence as it makes no sense whatsoever to me;-( Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 4/29/2019 4:23 AM, Reimar Döffinger wrote: > On 28.04.2019, at 22:02, Marton Balint 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 don't see myself qualified to vote You can vote if you want, you're on the list of allowed contributors. ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 28.04.2019, at 22:02, Marton Balint 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 don't see myself qualified to vote, and I'd rather have this vote not happen, because I don't think this specific case justifies the divisions such discussions and votes encourage. In the end, why should we really care? Yes, we should respect our users, but those users are PAYING customers of a company. Why should we be taking responsibility for them and not the company that gets paid? They can maintain their own FFmpeg patches. And it's a case of a company that decided to go closed source and to violate the license. At some point it's "you made your bed, now you get to lie in it". That said, I am not truly arguing for the taken approach, but I argue it is a bad cause to create more divisions (for example I already see the "who gets to vote" thing coming up). I also feel that some people might have other concerns triggered by this. Maybe it would be better to discuss these instead and try to reach common ground. I hope I have not offended anyone, and I admit I don't even read emails on this list nowadays. So you are under no obligation to listen to me, but I still kind of love this project and wish for it to have as healthy a community as possible when people with different world views meet head-on, and hope you can discuss in that spirit :) Best regards, Reimar Döffinger ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 29-04-2019 05:37 AM, Marton Balint wrote: On Sun, 28 Apr 2019, Marton Balint 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? 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? I revoke the vote request on the 2nd question (some invalid references and ambiguity was pointed out in it), please only vote on the 1st. Second question will be rephrased and submitted to a vote later, in a different thread. For those new to voting, what's the procedure? Gyan ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Hi, On Sun, Apr 28, 2019 at 8:14 PM Marton Balint wrote: > On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote: > > On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote: > >> >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: > >> >>> 2) Should patches using closed source libraries which are not > considered > >> >>> "System Libraries" according to the GPL be rejected? > >> >> > >> >> You mean "major components"? > >> >> (at no point does the GPLv2 mention "System Libraries". > >> > > >> > I meant the sytem libraries as in GPL v3. > >> > >> Okay, now I am really confused, I thought the GPLv3 refers to the > system > >> libraries as the drivers interfaces, but that might not be a case, > because > >> that is also the major component? > >> > >> If that is the case, then my intention was obvisouly major component, > but > >> I wonder what the system library means then in GPL v3? > > > > As to that, I have no clue. I feel that the GPLv3 did not help on that > part, and makes it more confusing (and many other parts). > > > > My understanding of major components of the OS, in GPLv2sense, is > kernel+libc+compiler+init/shell+drivers+libraries-installed-with-the-previous. > > Ok, I just revoked the vote request on the 2nd question. Sorry for the > mess. > > It looks like people prefer if GPL is not referenced at all in the > question, so please propose a (preferably short, but still precise) > wording for the vote about this. Should decklink be removed? (Even if the headers are BSD, the end-user functionality depends on closed-source libraries.) Should future patches depending on any closed-source component be approved of by a vote from this committee before being merged? We could even do a vote on the nvidia stuffies, just so we've had that too. Ronald ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote: On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote: >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: >>> 2) Should patches using closed source libraries which are not considered >>> "System Libraries" according to the GPL be rejected? >> >> You mean "major components"? >> (at no point does the GPLv2 mention "System Libraries". > > I meant the sytem libraries as in GPL v3. Okay, now I am really confused, I thought the GPLv3 refers to the system libraries as the drivers interfaces, but that might not be a case, because that is also the major component? If that is the case, then my intention was obvisouly major component, but I wonder what the system library means then in GPL v3? As to that, I have no clue. I feel that the GPLv3 did not help on that part, and makes it more confusing (and many other parts). My understanding of major components of the OS, in GPLv2sense, is kernel+libc+compiler+init/shell+drivers+libraries-installed-with-the-previous. Ok, I just revoked the vote request on the 2nd question. Sorry for the mess. It looks like people prefer if GPL is not referenced at all in the question, so please propose a (preferably short, but still precise) wording for the vote about this. Thanks, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Marton Balint 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? 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? I revoke the vote request on the 2nd question (some invalid references and ambiguity was pointed out in it), please only vote on the 1st. Second question will be rephrased and submitted to a vote later, in a different thread. Thanks, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote: 2019-04-28 22:02 GMT+02:00, Marton Balint : 1) Should libNDI support be removed from the ffmpeg codebase? This sounds to me as if you know of an alternative to not endorsing a company that profits from FFmpeg while at the same time violating the copyright of the FFmpeg developers? What could this alternative be? We could list them on our webpage hall of shame, or whatever. To be frank, I consider this vote to be more important for our project/community to make sure everyone's voice is heard, than the actual outcome. Regards, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-28 22:02 GMT+02:00, Marton Balint : > 1) Should libNDI support be removed from the ffmpeg codebase? This sounds to me as if you know of an alternative to not endorsing a company that profits from FFmpeg while at the same time violating the copyright of the FFmpeg developers? What could this alternative be? Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote: > >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: > >>> 2) Should patches using closed source libraries which are not considered > >>> "System Libraries" according to the GPL be rejected? > >> > >> You mean "major components"? > >> (at no point does the GPLv2 mention "System Libraries". > > > > I meant the sytem libraries as in GPL v3. > > Okay, now I am really confused, I thought the GPLv3 refers to the system > libraries as the drivers interfaces, but that might not be a case, because > that is also the major component? > > If that is the case, then my intention was obvisouly major component, but > I wonder what the system library means then in GPL v3? As to that, I have no clue. I feel that the GPLv3 did not help on that part, and makes it more confusing (and many other parts). My understanding of major components of the OS, in GPLv2sense, is kernel+libc+compiler+init/shell+drivers+libraries-installed-with-the-previous. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Marton Balint wrote: On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote: On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? You mean "major components"? (at no point does the GPLv2 mention "System Libraries". I meant the sytem libraries as in GPL v3. Okay, now I am really confused, I thought the GPLv3 refers to the system libraries as the drivers interfaces, but that might not be a case, because that is also the major component? If that is the case, then my intention was obvisouly major component, but I wonder what the system library means then in GPL v3? Thanks, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Mark Thompson wrote: On 28/04/2019 21:02, Marton Balint wrote: ... closed source libraries which are not considered "System Libraries" according to the GPL ... Please can you define this in a precise way which does not rely upon interpreting the GPL? There are certainly differing opinions about exactly what it means, and we need to know exactly what we are voting on. It is amazingly hard to define this precisely, and I have a feeling that whatever we come up with, somebody will be able to find holes in it. If something is debated to be a "System Library", then we can always do a vote on a case by case basis. (not whether or not it is a system library, but if we accept it into the codebase anyways). Regards, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-28 23:34 GMT+02:00, Marton Balint : > > On Sun, 28 Apr 2019, Carl Eugen Hoyos wrote: > >> 2019-04-28 22:02 GMT+02:00, Marton Balint : >>> 2) Should patches using closed source libraries which are not >>> considered "System Libraries" according to the GPL be rejected? >> >> Do I understand correctly that this question is equivalent to >> requesting the removal of the decklink wrapper? > > I think not, because as far as I understand there is no debate that > DeckLink libraries are System Libraries DeckLink libraries are definitely not a system library. Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote: On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? You mean "major components"? (at no point does the GPLv2 mention "System Libraries". I meant the sytem libraries as in GPL v3. Regards, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Carl Eugen Hoyos wrote: 2019-04-28 22:02 GMT+02:00, Marton Balint : 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? Do I understand correctly that this question is equivalent to requesting the removal of the decklink wrapper? I think not, because as far as I understand there is no debate that DeckLink libraries are System Libraries, because they are installed with the driver. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241501.html Regards, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-28 23:29 GMT+02:00, Jean-Baptiste Kempf : > On Sun, 28 Apr 2019, at 22:44, Carl Eugen Hoyos wrote: >> 2019-04-28 22:02 GMT+02:00, Marton Balint : >> > 2) Should patches using closed source libraries which are not >> > considered "System Libraries" according to the GPL be rejected? >> >> Do I understand correctly that this question is equivalent to >> requesting the removal of the decklink wrapper? > > No, it is not. I don't think you can answer this question. But I hope it is obvious to everybody that if a majority votes yes on above question, we will have to remove the decklink wrapper. Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: > 2) Should patches using closed source libraries which are not considered > "System Libraries" according to the GPL be rejected? You mean "major components"? (at no point does the GPLv2 mention "System Libraries". -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 28/04/2019 21:02, Marton Balint wrote: > ... closed source libraries which are not considered "System Libraries" > according to the GPL ... Please can you define this in a precise way which does not rely upon interpreting the GPL? There are certainly differing opinions about exactly what it means, and we need to know exactly what we are voting on. For example, you might consider rejecting a library only if none of the following are true: (1) Full human-readable source code is available for everything which runs on the same processor as FFmpeg does. (2) It implements a standardised API independent of any particular vendor (common to at least three separate vendors?). (3) It interfaces with some common consumer hardware: a whole PC-like system containing it can be widely purchased off-the-shelf for less than 1000 EUR/USD, with all closed-source components provided as part of the operating system. ... or something like that. Thanks, - Mark ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, at 22:44, Carl Eugen Hoyos wrote: > 2019-04-28 22:02 GMT+02:00, Marton Balint : > > 2) Should patches using closed source libraries which are not > > considered "System Libraries" according to the GPL be rejected? > > Do I understand correctly that this question is equivalent to > requesting the removal of the decklink wrapper? No, it is not. Decklink is a set of BSD headers that are useful to access the driver, like nVidia. This would be considered "major components". As it is a curious case (BSD headers in a .zip that has a EULA), I would suggest a vote only on this part. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
> > [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html There are numerous inactive people in the voting committee, some for years. Why are they arbitrarily allowed to vote on this? Kieran ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, James Almer wrote: On 4/28/2019 5:02 PM, Marton Balint 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? This question needs some context for people to know why the library was removed, and what they are voting for. The trac ticket and relevant discussion threads should be linked to, or summarized. http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237070.html http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/240878.html http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241233.html https://trac.ffmpeg.org/ticket/7589 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? In addition to the threads above these might also be of some relevance: https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-for-librv11-and-rmhd-muxer-demuxer#post1 http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/240913.html http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241067.html Feel free to add more threads with relevant discussion if I missed them. Deadline for voting is 7 days from now. This could use a longer deadline, IMO. Especially if discussion could happen before some people decide to cast a vote. Ok, let's it make 14 days from now the deadline then. Thanks, Marton ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-28 22:02 GMT+02:00, Marton Balint : > 2) Should patches using closed source libraries which are not > considered "System Libraries" according to the GPL be rejected? Do I understand correctly that this question is equivalent to requesting the removal of the decklink wrapper? Carl Eugen ___ 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 4/28/2019 5:02 PM, Marton Balint 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? This question needs some context for people to know why the library was removed, and what they are voting for. The trac ticket and relevant discussion threads should be linked to, or summarized. > > 2) Should patches using closed source libraries which are not considered > "System Libraries" according to the GPL be rejected? > > Deadline for voting is 7 days from now. This could use a longer deadline, IMO. Especially if discussion could happen before some people decide to cast a vote. > > 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". ___ 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".
