Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Tue, 26 Mar 2019, at 10:03, Tomas Härdin wrote: > You can include LGPL code in a proprietary library if you provide the > object files for the proprietary parts, such that you can modify the > LGPL part and still link together a functioning library. I don't think > I've ever seen that done however Google release of Sparrow on iOS is a clear case of this: to allow effective changing of the LGPL library in it, they gave all the objects pre-linking. So you could recompile the LGPL library part completely, and relink and reship on your device. -- 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] [PATCH] News: Removal of libndi
On Tue, 26 Mar 2019, at 09:45, Tobias Rapp wrote: > > I know that means that you can do more or less the same feature, but that > > means the architecture must be different. > > I thought that section 7 would allow to combine a 3rd party library with > a LGPL library to create a new library but now when reading it again I > stumble over the word "side-by-side" which indicates that the two parts > should not interact with each other. Yep, you can have program A that includes both library B LGPL and library C whatever-license. You cannot have program A that includes library B, which itself would include C. > So yes, your interpretation looks correct to me (IANAL). I got bitten by it, in the past, that's why I now know. -- 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] [PATCH] News: Removal of libndi
tis 2019-03-26 klockan 09:45 +0100 skrev Tobias Rapp: > On 25.03.2019 18:02, Jean-Baptiste Kempf wrote: > > On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote: > > > > Most of those hardware libraries are glorified ioctls around > > > > the driver and shipped with the drivers. > > > > And I see this with nVidia, Intel MFX and Decklink (lots of > > > > "acquire C++ interface, set param" there, release the C++ > > > > interface). > > > > > > > > Matrox seems to do something else, though, introducing a > > > > special library for FFmpeg consumption, and I doubt that feels > > > > like a driver... > > > > > > The GPL is mentioned a lot in this thread. Maybe it would make > > > sense to > > > distinguish the two cases where FFmpeg is compiled with --enable- > > > gpl and > > > without it -- as the LGPL applies in that case. > > > > That does not change a thing, sorry. > > The section 6 of the LGPLv2.1 is similar to the section 3 of the > > GPL, and mentions exactly the same limitations and exceptions for > > major components of the OS. > > > > The fact that you can combine the library with a 3rd party library > > inside your program does not allow you to ship non-LGPL-compatible > > code inside the library. (The library must be changeable + > > redistributable by the user). > > > > I know that means that you can do more or less the same feature, > > but that means the architecture must be different. > > I thought that section 7 would allow to combine a 3rd party library with > a LGPL library to create a new library but now when reading it again I > stumble over the word "side-by-side" which indicates that the two parts > should not interact with each other. You can include LGPL code in a proprietary library if you provide the object files for the proprietary parts, such that you can modify the LGPL part and still link together a functioning library. I don't think I've ever seen that done however /Tomas ___ 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] [PATCH] News: Removal of libndi
On 25.03.2019 18:02, Jean-Baptiste Kempf wrote: On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote: Most of those hardware libraries are glorified ioctls around the driver and shipped with the drivers. And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface, set param" there, release the C++ interface). Matrox seems to do something else, though, introducing a special library for FFmpeg consumption, and I doubt that feels like a driver... The GPL is mentioned a lot in this thread. Maybe it would make sense to distinguish the two cases where FFmpeg is compiled with --enable-gpl and without it -- as the LGPL applies in that case. That does not change a thing, sorry. The section 6 of the LGPLv2.1 is similar to the section 3 of the GPL, and mentions exactly the same limitations and exceptions for major components of the OS. The fact that you can combine the library with a 3rd party library inside your program does not allow you to ship non-LGPL-compatible code inside the library. (The library must be changeable + redistributable by the user). I know that means that you can do more or less the same feature, but that means the architecture must be different. I thought that section 7 would allow to combine a 3rd party library with a LGPL library to create a new library but now when reading it again I stumble over the word "side-by-side" which indicates that the two parts should not interact with each other. So yes, your interpretation looks correct to me (IANAL). Regards, Tobias ___ 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] [PATCH] News: Removal of libndi
On Mon, Mar 25, 2019 at 18:51:15 +0100, Nicolas George wrote: > Yufei He (12019-03-25): > > Yes, it's part of the installation for the driver of the card. People > > who have the card will install it. > Why does it have "ffmpeg" in its name? It looks like deliberate > circumvention; if it is, then no, thanks. In other words: Kindly make the library's code part of your patch for ffmpeg (with a liberal license), and then things start to look different. Or release the library under such a license as open source. Yes, it's really that easy. ;-) (Almost) Moritz ___ 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] [PATCH] News: Removal of libndi
Yufei He (12019-03-25): > Yes, it's part of the installation for the driver of the card. People > who have the card will install it. Why does it have "ffmpeg" in its name? It looks like deliberate circumvention; if it is, then no, thanks. > On 03/25/2019 01:04 PM, Jean-Baptiste Kempf wrote: Please remember that top-posting is not accepted on this list. If you forgot what it means, look it up. 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] [PATCH] News: Removal of libndi
Yes, it's part of the installation for the driver of the card. People who have the card will install it. Thanks. Yufei On 03/25/2019 01:04 PM, Jean-Baptiste Kempf wrote: > On Mon, 25 Mar 2019, at 14:02, Yufei He wrote: >> Matrox card is very similar to cards from other companies in terms of >> accesses. > Then why do you have this specific libmvM264Ffmpeg library? > What is it? Is it part of the driver? Is it installed at the same time as the > driver? > ___ 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] [PATCH] News: Removal of libndi
On Mon, 25 Mar 2019, at 14:02, Yufei He wrote: > Matrox card is very similar to cards from other companies in terms of > accesses. Then why do you have this specific libmvM264Ffmpeg library? What is it? Is it part of the driver? Is it installed at the same time as the driver? -- 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] [PATCH] News: Removal of libndi
On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote: > > Most of those hardware libraries are glorified ioctls around the driver and > > shipped with the drivers. > > And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ > > interface, set param" there, release the C++ interface). > > > > Matrox seems to do something else, though, introducing a special library > > for FFmpeg consumption, and I doubt that feels like a driver... > > The GPL is mentioned a lot in this thread. Maybe it would make sense to > distinguish the two cases where FFmpeg is compiled with --enable-gpl and > without it -- as the LGPL applies in that case. That does not change a thing, sorry. The section 6 of the LGPLv2.1 is similar to the section 3 of the GPL, and mentions exactly the same limitations and exceptions for major components of the OS. The fact that you can combine the library with a 3rd party library inside your program does not allow you to ship non-LGPL-compatible code inside the library. (The library must be changeable + redistributable by the user). I know that means that you can do more or less the same feature, but that means the architecture must be different. -- 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] [PATCH] News: Removal of libndi
On Mon, 25 Mar 2019 at 13:56 Kieran Kunhya wrote: > On Mon, 25 Mar 2019 at 13:02 Yufei He wrote: > >> Hardware codecs and software codecs are taking different responsibilities. >> >> Thanks a lot. >> >> Yufei. >> > > Hi, > > You should expose the APIs to the hardware, people will buy more of them > if they can program the chip to do things as they want. > I appreciate it's difficult for hardware companies to understand open > source, since you all are very secretive and live in a world of IP. > But what people actually want is low-level access to the hardware APIs. > > Kieran > I would add that most/all APIs to hardware are terrible, hardware engineers can't design good APIs. Just let us talk to the chip. 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] [PATCH] News: Removal of libndi
On Mon, 25 Mar 2019 at 13:02 Yufei He wrote: > Hardware codecs and software codecs are taking different responsibilities. > > Thanks a lot. > > Yufei. > Hi, You should expose the APIs to the hardware, people will buy more of them if they can program the chip to do things as they want. I appreciate it's difficult for hardware companies to understand open source, since you all are very secretive and live in a world of IP. But what people actually want is low-level access to the hardware APIs. 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] [PATCH] News: Removal of libndi
Hi Matrox card is very similar to cards from other companies in terms of accesses. I suggest that we should differentiate hardware codec and software codec. Hardware codecs are very strong help to FFmpeg for high resolution video encoding and decoding like 4k. though gradually software codec will be stronger and stronger with CPU grows. Currently, it's very hard to trancode a quadhd mxf file to a streaming .mp4 file with cpu. Actually, I don't know what we can get from code to access the hardware, it's all detailed hardware access api. Hardware codecs and software codecs are taking different responsibilities. Thanks a lot. Yufei. On 03/24/2019 04:14 PM, Jean-Baptiste Kempf wrote: > On Sun, 24 Mar 2019, at 20:10, Ronald S. Bultje wrote: >> The GPL does not mention hardware (instead, they use the word "system >> library"). Going from here, I don't consider enterprise-level hardware like >> Matrox $$$ priced stuff to be a system library at all. My system certainly >> has no hardware or drivers or system-level libraries that are >> API+ABI+functionally compatible with Matrox' tools and wares - under any >> license, not open-source and not closed-source. How can the system library >> exception possibly apply here? > Drivers have always been considered part of the OS, whatever the price of the > hardware. > The Linux kernel has drivers for pieces of hardware that are way more > expensive than Matrox hardware. > > So, if the library is part of the driver (installed at the same time), it is > considered part of the "major components of the OS", because if you don't > install the driver, you cannot use the hardware. > This is the opinion of the Linux Foundation, the FSF, FSFE and so many others. > > Usually, the "major components" (as mentioned in the GPL and not "system > libraries", which is the shortcut) explicitly mention 3 parts: kernel, > compiler and "others." > The common understanding is that everything that runs in Kernel-Land, aka > kernel + drivers is the kernel part of the "major components". libc, compiler > and libraries linked by compilers, if distributed with the OS, are the second > part of the "major components"; and the last part, "others" cover the other > core parts of the OS (usually the "base" in linux distributions), and covers > init and the shell, and the basic services normally installed by default (at, > cron, etc..). > > Yes, this meaning is very dated, but GPLv2 is from 1991. > > > Most of those hardware libraries are glorified ioctls around the driver and > shipped with the drivers. > And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ > interface, set param" there, release the C++ interface). > > Matrox seems to do something else, though, introducing a special library for > FFmpeg consumption, and I doubt that feels like a driver... > > ___ 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] [PATCH] News: Removal of libndi
On 24.03.2019 21:14, Jean-Baptiste Kempf wrote: On Sun, 24 Mar 2019, at 20:10, Ronald S. Bultje wrote: The GPL does not mention hardware (instead, they use the word "system library"). Going from here, I don't consider enterprise-level hardware like Matrox $$$ priced stuff to be a system library at all. My system certainly has no hardware or drivers or system-level libraries that are API+ABI+functionally compatible with Matrox' tools and wares - under any license, not open-source and not closed-source. How can the system library exception possibly apply here? Drivers have always been considered part of the OS, whatever the price of the hardware. The Linux kernel has drivers for pieces of hardware that are way more expensive than Matrox hardware. So, if the library is part of the driver (installed at the same time), it is considered part of the "major components of the OS", because if you don't install the driver, you cannot use the hardware. This is the opinion of the Linux Foundation, the FSF, FSFE and so many others. Usually, the "major components" (as mentioned in the GPL and not "system libraries", which is the shortcut) explicitly mention 3 parts: kernel, compiler and "others." The common understanding is that everything that runs in Kernel-Land, aka kernel + drivers is the kernel part of the "major components". libc, compiler and libraries linked by compilers, if distributed with the OS, are the second part of the "major components"; and the last part, "others" cover the other core parts of the OS (usually the "base" in linux distributions), and covers init and the shell, and the basic services normally installed by default (at, cron, etc..). Yes, this meaning is very dated, but GPLv2 is from 1991. Most of those hardware libraries are glorified ioctls around the driver and shipped with the drivers. And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface, set param" there, release the C++ interface). Matrox seems to do something else, though, introducing a special library for FFmpeg consumption, and I doubt that feels like a driver... The GPL is mentioned a lot in this thread. Maybe it would make sense to distinguish the two cases where FFmpeg is compiled with --enable-gpl and without it -- as the LGPL applies in that case. Regards, Tobias ___ 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] [PATCH] News: Removal of libndi
On Sun, 24 Mar 2019, at 20:10, Ronald S. Bultje wrote: > The GPL does not mention hardware (instead, they use the word "system > library"). Going from here, I don't consider enterprise-level hardware like > Matrox $$$ priced stuff to be a system library at all. My system certainly > has no hardware or drivers or system-level libraries that are > API+ABI+functionally compatible with Matrox' tools and wares - under any > license, not open-source and not closed-source. How can the system library > exception possibly apply here? Drivers have always been considered part of the OS, whatever the price of the hardware. The Linux kernel has drivers for pieces of hardware that are way more expensive than Matrox hardware. So, if the library is part of the driver (installed at the same time), it is considered part of the "major components of the OS", because if you don't install the driver, you cannot use the hardware. This is the opinion of the Linux Foundation, the FSF, FSFE and so many others. Usually, the "major components" (as mentioned in the GPL and not "system libraries", which is the shortcut) explicitly mention 3 parts: kernel, compiler and "others." The common understanding is that everything that runs in Kernel-Land, aka kernel + drivers is the kernel part of the "major components". libc, compiler and libraries linked by compilers, if distributed with the OS, are the second part of the "major components"; and the last part, "others" cover the other core parts of the OS (usually the "base" in linux distributions), and covers init and the shell, and the basic services normally installed by default (at, cron, etc..). Yes, this meaning is very dated, but GPLv2 is from 1991. Most of those hardware libraries are glorified ioctls around the driver and shipped with the drivers. And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface, set param" there, release the C++ interface). Matrox seems to do something else, though, introducing a special library for FFmpeg consumption, and I doubt that feels like a driver... -- 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] [PATCH] News: Removal of libndi
Hi, On Sun, Mar 24, 2019 at 2:21 PM Jean-Baptiste Kempf wrote: > On Sun, 24 Mar 2019, at 18:50, Marton Balint wrote: > > > - do we want to keep any components requiring linking with non-system, > > > closed-source software? (this might or might not include blackmagic) > > > > > > or some other variant that also includes system software like nvidia > stuff? > > > Or ask a simple yes/no for each component separately? (Although that > > > wouldn't set a more general policy.) > > > > I prefer votes on a case by case basis, because it is hard to categorize > > closed source components. > > I disagree. > First you should vote for the global concept of non-hardware closed source > libraries. > It will avoid doing 20 votes for each time this action will come. > > > (ok, maybe not NDI, but for > > M264/Nvidia/Blackmagic it is definitely not trivial). > > Those are hardware based libraries, done to access hardware. > They are very easy to differentiate from non-hardware libraries. I disagree with the whole hardware concept. The GPL does not mention hardware (instead, they use the word "system library"). Going from here, I don't consider enterprise-level hardware like Matrox $$$ priced stuff to be a system library at all. My system certainly has no hardware or drivers or system-level libraries that are API+ABI+functionally compatible with Matrox' tools and wares - under any license, not open-source and not closed-source. How can the system library exception possibly apply here? (I understand nvidia may be a special case because the interface is actually entirely through ioctl()s and there are opensource drivers and the userland compatibility library is enitrely opensource - maybe the system-library exception actually applies here - even though binary blobs are loaded, I don't know. But matrox and blackmagic? This seems crazy.) Ronald (Also, aside from all of this, my concern is philosophical as much as it's legal. But I'll leave that for some other email.) ___ 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] [PATCH] News: Removal of libndi
On Sat, 23 Mar 2019, Ronald S. Bultje wrote: Hi, On Sat, Mar 23, 2019 at 11:03 AM Thilo Borgmann wrote: Am 21.03.19 um 11:55 schrieb Michael Niedermayer: > On Wed, Mar 20, 2019 at 05:41:31PM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Wed, Mar 20, 2019 at 4:15 PM Gyan wrote: >> >>> >>> >>> On 21-03-2019 01:32 AM, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: >> >>> On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: As I described in similar threads before, whether or not the >> project want >> closed source support for NDI is a subjective issue, >> please start a vote >> about the removal of libndi if you want to >> seek this through. >>> >>> The removal of libndi is actually done and committed. >> >> That is just sad an unfair. > > Sad, maybe. > Unfair, I disagree. If NDI wants to be in, they know what to do. It is unfair towards the people who expressied disapproval, yet this change was committed without neither vote nor consensus. >>> >>> +1. This was a political decision, not a technical one. A formal(-ish) >>> survey should have happened on the ML. >>> >> >> I agree we need a formal vote on this. I would like to set a wider project >> policy w.r.t. closed-source software integration, this is just one instance >> of a more general issue. > I think there should have been a vote before pushing a commit as there where > FFmpeg developers objecting to it. > Ignoring people causes nothing good. Had there been a vote people would be > alot less upset about it as everyones oppinion would be counted equally > > It makes me unhappy that one FFmpeg developer apparently decided to leave > the project already because of this. > I think we should fix this, make a proper policy, with a proper vote > and then hopefully noone feels the need to leave. +1 >> >> Who wants to organize it? > > Thilo organized the last vote, maybe he wants to do it ? > but if noone else wants to do it i can do one too if people want and > there is consensus who can vote > If i search for "open source vote free" on google it points to > vote.heliosvoting.org as first hit > this seems rather basic but for simple yes/no questions it could work > maybe someone has a better suggestion we could use for more complex future > cases that is multiple choice votes in teh future (schulze STV / CPO-STV > for multiwinner or ScottishSTV (used by SPI), schulze method (used by debian) > for one winner of N choices would be nice to have) Including for simple yes/no votes we can use the same LimeSurvey host we got provided from KDE for the survey. Also for anonymous votes. I think what we have to figure out is whether we want to ask: - do we want to keep (or remove) NDI? I think this is definitely needed to justify the recent events. or - do we want to keep any components requiring linking with non-system, closed-source software? (this might or might not include blackmagic) or some other variant that also includes system software like nvidia stuff? Or ask a simple yes/no for each component separately? (Although that wouldn't set a more general policy.) I prefer votes on a case by case basis, because it is hard to categorize closed source components. (ok, maybe not NDI, but for M264/Nvidia/Blackmagic it is definitely not trivial). 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] [PATCH] News: Removal of libndi
On Sat, 23 Mar 2019, Thilo Borgmann wrote: Am 21.03.19 um 11:55 schrieb Michael Niedermayer: On Wed, Mar 20, 2019 at 05:41:31PM -0400, Ronald S. Bultje wrote: Hi, On Wed, Mar 20, 2019 at 4:15 PM Gyan wrote: On 21-03-2019 01:32 AM, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: As I described in similar threads before, whether or not the project want >> closed source support for NDI is a subjective issue, please start a vote >> about the removal of libndi if you want to seek this through. The removal of libndi is actually done and committed. That is just sad an unfair. Sad, maybe. Unfair, I disagree. If NDI wants to be in, they know what to do. It is unfair towards the people who expressied disapproval, yet this change was committed without neither vote nor consensus. +1. This was a political decision, not a technical one. A formal(-ish) survey should have happened on the ML. I agree we need a formal vote on this. I would like to set a wider project policy w.r.t. closed-source software integration, this is just one instance of a more general issue. I think there should have been a vote before pushing a commit as there where FFmpeg developers objecting to it. Ignoring people causes nothing good. Had there been a vote people would be alot less upset about it as everyones oppinion would be counted equally It makes me unhappy that one FFmpeg developer apparently decided to leave the project already because of this. I think we should fix this, make a proper policy, with a proper vote and then hopefully noone feels the need to leave. +1 Who wants to organize it? Thilo organized the last vote, maybe he wants to do it ? but if noone else wants to do it i can do one too if people want and there is consensus who can vote If i search for "open source vote free" on google it points to vote.heliosvoting.org as first hit this seems rather basic but for simple yes/no questions it could work maybe someone has a better suggestion we could use for more complex future cases that is multiple choice votes in teh future (schulze STV / CPO-STV for multiwinner or ScottishSTV (used by SPI), schulze method (used by debian) for one winner of N choices would be nice to have) Including for simple yes/no votes we can use the same LimeSurvey host we got provided from KDE for the survey. Also for anonymous votes. If people want it, we can setup a poll anytime. Most important would be a list of people allowed to vote (as of mail subscribed to FFmpeg-devel). The last time we used the Voting Committe these people were on it: Original committe: Michael Niedermayer Clément Bœsch James Almer Paul B Mahol Carl Eugen Hoyos Andreas Cadhalpun Ronald S. Bultje wm4 Lukasz Marek Rostislav Pehlivanov Hendrik Leppkes Christophe Gisquet Reynaldo H. Verdejo Pinochet First extension: Nicolas George Rodger Combs Stefano Sabatini Timothy Gu Second extension: Ganesh Ajjanagadde Lou Logan Marton Balint Philip Langdale Reimar Döffinger (There was a 3rd extension attempt but that was rejected in the discussion phase) Emails can be generated from git log relatively easily for each member (the last 50 commits are queried to be able to notice ambiguities): git log -n 50 --pretty=format:%ce --committer='Author Name <' |sort | uniq I suggest we first do a vote one the extension. Michael used this in the past to propose the list of people to add: git log libav/master..master --no-merges --since=2014-10-25T00:00:00Z --until 2015-10-25T00:00:00Z --pretty=fuller | grep '^Commit:' | sed 's/<.*//' |sort | uniq -c | sort -nr (https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182057.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] [PATCH] News: Removal of libndi
Hi, On Sat, Mar 23, 2019 at 11:03 AM Thilo Borgmann wrote: > Am 21.03.19 um 11:55 schrieb Michael Niedermayer: > > On Wed, Mar 20, 2019 at 05:41:31PM -0400, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Wed, Mar 20, 2019 at 4:15 PM Gyan wrote: > >> > >>> > >>> > >>> On 21-03-2019 01:32 AM, Marton Balint wrote: > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > >> > >>> On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > As I described in similar threads before, whether or not the > >> project want >> closed source support for NDI is a subjective issue, > >> please start a vote >> about the removal of libndi if you want to > >> seek this through. > >>> > >>> The removal of libndi is actually done and committed. > >> > >> That is just sad an unfair. > > > > Sad, maybe. > > Unfair, I disagree. If NDI wants to be in, they know what to do. > > It is unfair towards the people who expressied disapproval, yet this > change was committed without neither vote nor consensus. > >>> > >>> +1. This was a political decision, not a technical one. A formal(-ish) > >>> survey should have happened on the ML. > >>> > >> > >> I agree we need a formal vote on this. I would like to set a wider > project > >> policy w.r.t. closed-source software integration, this is just one > instance > >> of a more general issue. > > > I think there should have been a vote before pushing a commit as there > where > > FFmpeg developers objecting to it. > > Ignoring people causes nothing good. Had there been a vote people would > be > > alot less upset about it as everyones oppinion would be counted equally > > > > It makes me unhappy that one FFmpeg developer apparently decided to leave > > the project already because of this. > > I think we should fix this, make a proper policy, with a proper vote > > and then hopefully noone feels the need to leave. > > +1 > > >> > >> Who wants to organize it? > > > > Thilo organized the last vote, maybe he wants to do it ? > > but if noone else wants to do it i can do one too if people want and > > there is consensus who can vote > > If i search for "open source vote free" on google it points to > > vote.heliosvoting.org as first hit > > this seems rather basic but for simple yes/no questions it could work > > maybe someone has a better suggestion we could use for more complex > future > > cases that is multiple choice votes in teh future (schulze STV / CPO-STV > > for multiwinner or ScottishSTV (used by SPI), schulze method (used by > debian) > > for one winner of N choices would be nice to have) > > Including for simple yes/no votes we can use the same LimeSurvey host we > got provided from KDE for the survey. Also for anonymous votes. I think what we have to figure out is whether we want to ask: - do we want to keep (or remove) NDI? or - do we want to keep any components requiring linking with non-system, closed-source software? (this might or might not include blackmagic) or some other variant that also includes system software like nvidia stuff? Or ask a simple yes/no for each component separately? (Although that wouldn't set a more general policy.) 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] [PATCH] News: Removal of libndi
Am 21.03.19 um 11:55 schrieb Michael Niedermayer: > On Wed, Mar 20, 2019 at 05:41:31PM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Wed, Mar 20, 2019 at 4:15 PM Gyan wrote: >> >>> >>> >>> On 21-03-2019 01:32 AM, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: >> >>> On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: As I described in similar threads before, whether or not the >> project want >> closed source support for NDI is a subjective issue, >> please start a vote >> about the removal of libndi if you want to >> seek this through. >>> >>> The removal of libndi is actually done and committed. >> >> That is just sad an unfair. > > Sad, maybe. > Unfair, I disagree. If NDI wants to be in, they know what to do. It is unfair towards the people who expressied disapproval, yet this change was committed without neither vote nor consensus. >>> >>> +1. This was a political decision, not a technical one. A formal(-ish) >>> survey should have happened on the ML. >>> >> >> I agree we need a formal vote on this. I would like to set a wider project >> policy w.r.t. closed-source software integration, this is just one instance >> of a more general issue. > I think there should have been a vote before pushing a commit as there where > FFmpeg developers objecting to it. > Ignoring people causes nothing good. Had there been a vote people would be > alot less upset about it as everyones oppinion would be counted equally > > It makes me unhappy that one FFmpeg developer apparently decided to leave > the project already because of this. > I think we should fix this, make a proper policy, with a proper vote > and then hopefully noone feels the need to leave. +1 >> >> Who wants to organize it? > > Thilo organized the last vote, maybe he wants to do it ? > but if noone else wants to do it i can do one too if people want and > there is consensus who can vote > If i search for "open source vote free" on google it points to > vote.heliosvoting.org as first hit > this seems rather basic but for simple yes/no questions it could work > maybe someone has a better suggestion we could use for more complex future > cases that is multiple choice votes in teh future (schulze STV / CPO-STV > for multiwinner or ScottishSTV (used by SPI), schulze method (used by debian) > for one winner of N choices would be nice to have) Including for simple yes/no votes we can use the same LimeSurvey host we got provided from KDE for the survey. Also for anonymous votes. If people want it, we can setup a poll anytime. Most important would be a list of people allowed to vote (as of mail subscribed to FFmpeg-devel). -Thilo ___ 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] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019 at 18:17, Jean-Baptiste Kempf wrote: > > > On Thu, 21 Mar 2019, at 16:14, Ali KIZIL wrote: > > I think the source code itself doesn't violate GPL. It use an external > lib, > > just like drivers. > > Drivers have a GPL exception. > external libraries do not. > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > > NewTek can only get off the hook by releasing their libraries under the GPL. The damage done prior cannot be reversed by a plain takedown of the infringing SDK version. What message does that send to these profiting off similar violations in the community? Abuse the GPL, get a slap on the wrist, rinse, wash and repeat? Based on prevailing factors surrounding this case, this is the most logical outcome. It's not necessarily fair, but its' logical. For these tilted by its' removal, fork FFmpeg, revert the commit and carry on, but let us avoid ad hominems. Be excellent to each other. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019 at 17:54, Maksym Veremeyenko wrote: > On 20.03.2019 22:13, Dennis Mungai wrote: > [...] > > The primary agitator here seems to be kierank: > > https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10#comment:5 > > > > What undisclosed history do you have with Newtek (see the reference to > > "Andrew") above that isn't disclosed above? > > Secondly, you're quite influential in the broadcast industry: > > https://www.obe.tv/author/obe/ > > > > There's an aura of hostility around this commit, and whatever that is > seems > > to have spilled over into this. > > dropping NDI from ffmpeg can make more efforts to > https://www.obe.tv/portfolio/interface-conversion/# ? > > -- > Maksym Veremeyenko > > > For all we know, (a). Kieran is an independent developer. Whatever history he may have with NDI is undisclosed. Whatever vendetta / ill intent he may hold against NDI still remains irrelevant to the breach of the GPL, as shown in (b). (b). Here's where NDI really nailed their fate in the coffin: >ffmpeg -L NewTek NDI Copyright (C)2015-2018 NewTek, inc. v3.7.1.0 ffmpeg version 4.0 Copyright (c) 2000-2018 the FFmpeg developers built with Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64 configuration: --toolchain=msvc --prefix=/d/Builds/User/Cary/ffmpeg/build --bindir=/d/Builds/User/Cary/ffmpeg/build/bin/x64/release --datadir=/d/Builds/User/Cary/ffmpeg/build/bin/x64/release/ffpresets --incdir=/d/Builds/User/Cary/ffmpeg/build/include --libdir=/d/Builds/User/Cary/ffmpeg/build/lib/x64/release --shlibdir=/d/Builds/User/Cary/ffmpeg/build/bin/x64/release --disable-shared --enable-static --disable-postproc --disable-ffplay --enable-debug --enable-optimizations --optflags='-O2 -Oy- -Oi' --extra-cflags='-GS -analyze- -Gy -Zc:wchar_t -Zc:forScope -Gm- -fp:precise -WX- -Gd -MD -EHsc -we4013 -DX264_API_IMPORTS' --extra-ldflags='-NXCOMPAT -DYNAMICBASE -DEBUG -OPT:REF -OPT:ICF ' --enable-zlib --enable-libmfx --enable-libndi_newtek --enable-nonfree --enable-libx264 --enable-gpl libavutil 56. 14.100 / 56. 14.100 libavcodec 58. 18.100 / 58. 18.100 libavformat58. 12.100 / 58. 12.100 libavdevice58. 3.100 / 58. 3.100 libavfilter 7. 16.100 / 7. 16.100 libswscale 5. 1.100 / 5. 1.100 libswresample 3. 1.100 / 3. 1.100 This version of ffmpeg has nonfree parts compiled in. Therefore it is not legally redistributable. This is their offending ticket: https://trac.ffmpeg.org/ticket/7589 It is self evident that Newtek sabotaged themselves here, and that counts against them. Kieran's actions cannot be construed as an extension of assumptions made in (a), but rather, maintenance duty. -Dennis. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, Mar 21, 2019, 5:54 PM Maksym Veremeyenko wrote: > On 20.03.2019 22:13, Dennis Mungai wrote: > [...] > > The primary agitator here seems to be kierank: > > https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10#comment:5 > > > > What undisclosed history do you have with Newtek (see the reference to > > "Andrew") above that isn't disclosed above? > > Secondly, you're quite influential in the broadcast industry: > > https://www.obe.tv/author/obe/ > > > > There's an aura of hostility around this commit, and whatever that is > seems > > to have spilled over into this. > > dropping NDI from ffmpeg can make more efforts to > https://www.obe.tv/portfolio/interface-conversion/# ? > > -- > Maksym Veremeyenko > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel Unfortunately, I had the same feeling. I use NDI for SDI to/from IP conversation at contribution encoding against J2K at zero cost, which is also compatible with NDI equipments. I wasn't brave enough like Maksyn to spread the word. I think the source code itself doesn't violate GPL. It use an external lib, just like drivers. Newtek stopped distributing the binary. I don't understand how removing source code from FFmpeg repo punishes Newtek. It just discourage developers and took users out of notice for some days. Anyone can make an external repo with a patch to apply to use it back at a point where this removal is still under questioning. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 20.03.2019 22:13, Dennis Mungai wrote: [...] The primary agitator here seems to be kierank: https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10#comment:5 What undisclosed history do you have with Newtek (see the reference to "Andrew") above that isn't disclosed above? Secondly, you're quite influential in the broadcast industry: https://www.obe.tv/author/obe/ There's an aura of hostility around this commit, and whatever that is seems to have spilled over into this. dropping NDI from ffmpeg can make more efforts to https://www.obe.tv/portfolio/interface-conversion/# ? -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019 at 12:52, Jean-Baptiste Kempf wrote: > On Thu, 21 Mar 2019, at 07:35, Dennis Mungai wrote: > > And apparently calling out specific parties involved in this was > translated > > as an ad hominem attack. > > Single-outing one person, when you don't know half of the discussion is > not a nice way of interacting within this project. > Especially when you accuse another developer of the project, and claim > they do what they do to profit from it for business reasons. > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > My sincerest apologies. > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019 at 16:56, Jean-Baptiste Kempf wrote: > On Thu, 21 Mar 2019, at 12:48, Ronald S. Bultje wrote: > > So that's nvidia stuff (npp/cuda) and blackmagic. (I'm filtering out the > > various ssl/aac components because they may be GPL-incompatible, but they > > are opensource.) > > I explained the case for those 2 cases. > I've asked for clarifications to BlackMagic on the header weirdness. > I'll ask Bradley about the compiler part. > > > I'm not mentioning quicksync because it's not in the nonfree list, but I > > want to mention that our wiki does mention the use of closed-source code > > [1]. I don't know what to make of this... > > libmfx is open source and loads the drivers, at least on Windows. > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > The right step for Newtek at this point should be to release the NDI libraries under the GPL. Intent does not erase impact. At one point, they deliberately violated the GPL. Posting an unrefistributable build, then removing it after coming under pressure, isn’t a fix. The only way to regain the rights to use works authored under the GPL should be to release their libraries as such, or forever forfeit integration with the likes of ffmpeg. Their removal is justified. For these with doubts, go through ticket 7589. See the notes on that ffmpeg build. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019, at 12:48, Ronald S. Bultje wrote: > So that's nvidia stuff (npp/cuda) and blackmagic. (I'm filtering out the > various ssl/aac components because they may be GPL-incompatible, but they > are opensource.) I explained the case for those 2 cases. I've asked for clarifications to BlackMagic on the header weirdness. I'll ask Bradley about the compiler part. > I'm not mentioning quicksync because it's not in the nonfree list, but I > want to mention that our wiki does mention the use of closed-source code > [1]. I don't know what to make of this... libmfx is open source and loads the drivers, at least on Windows. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019, at 12:29, Maksym Veremeyenko wrote: > >> when do you plan to remove nVidia and BlackmagicDesign parts that is > >> /closed source and userland/ ? > > > > 0) addressing me directly like that is unfair, and unjust; > > i just extrapolated your main statement *The work was removed because So extrapolation. So basically, you put words in my mouth that I did not say. Just to smear at me. Very nice and fair. > > notably when NDI was not removed by me. > > you supported it And I explained why. Many times. With legal arguments; not with "you do that because you don't like this company" or "you do that because you don't like me". > [...] > > 3b) > > Decklink headers are open source, but are normally distributed in a package > > that is not open-source. > > Whether the license of the headers is stronger than the package license is > > not clear. It is also not clear if someone who agreed to the package > > license can redistribute those headers to the other people? > > GPL code that runtime load close-source proprietary library... Please start reading the arguments instead of twisting them and start reading the GPL. I suggest the end of paragraph 3, about the exception for libraries. NDI is not addressing system libraries and drivers. The exception does not hold for them. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Hi, On Thu, Mar 21, 2019 at 7:31 AM Nicolas George wrote: > Maksym Veremeyenko (12019-03-21): > > i just extrapolated your main statement *The work was removed because the > > library is 100% closed source and userland.* that should be applied to > any > > parts of ffmpeg... or not? > > Please stop being shifty: what parts of FFmpeg precisely are you > suggesting to remove? > Presumably everything in EXTERNAL_LIBRARY_NONFREE_LIST and EXTERNAL_LIBRARY_NONFREE_LIST which is actually closed-source? So that's nvidia stuff (npp/cuda) and blackmagic. (I'm filtering out the various ssl/aac components because they may be GPL-incompatible, but they are opensource.) I'm not mentioning quicksync because it's not in the nonfree list, but I want to mention that our wiki does mention the use of closed-source code [1]. I don't know what to make of this... Ronald [1] https://trac.ffmpeg.org/wiki/Hardware/QuickSync - search for "Licence status of i965 VAAPI driver" [typo!] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Maksym Veremeyenko (12019-03-21): > i am just trying to get attention on way and reason of how code was removed > and floating reasons from to remove... Then please stop your whataboutism. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 21.03.2019 13:31, Nicolas George wrote: Maksym Veremeyenko (12019-03-21): i just extrapolated your main statement *The work was removed because the library is 100% closed source and userland.* that should be applied to any parts of ffmpeg... or not? Please stop being shifty: what parts of FFmpeg precisely are you suggesting to remove? i am just trying to get attention on way and reason of how code was removed and floating reasons from to remove... somebody says it was removed because of *library is 100% closed source and userland.*, somebody says it because license violation case, somebody just blame NewTek. it was applied to code without any strong objection, patches that implement runtime-library loading was rejected... and now: *lets drop it!* -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Maksym Veremeyenko (12019-03-21): > i just extrapolated your main statement *The work was removed because the > library is 100% closed source and userland.* that should be applied to any > parts of ffmpeg... or not? Please stop being shifty: what parts of FFmpeg precisely are you suggesting to remove? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 20.03.2019 21:36, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 18:03, Maksym Veremeyenko wrote: On 20.03.2019 17:37, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: [...] We don't talk about a contribution remove for technical reason. But a contributor's work remove in order to try to annoy a licence violator. Absolutely not. The work was removed because the library is 100% closed source and userland. when do you plan to remove nVidia and BlackmagicDesign parts that is /closed source and userland/ ? 0) addressing me directly like that is unfair, and unjust; i just extrapolated your main statement *The work was removed because the library is 100% closed source and userland.* that should be applied to any parts of ffmpeg... or not? notably when NDI was not removed by me. you supported it [...] 3b) Decklink headers are open source, but are normally distributed in a package that is not open-source. Whether the license of the headers is stronger than the package license is not clear. It is also not clear if someone who agreed to the package license can redistribute those headers to the other people? GPL code that runtime load close-source proprietary library... -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, Mar 20, 2019 at 05:41:31PM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 20, 2019 at 4:15 PM Gyan wrote: > > > > > > > On 21-03-2019 01:32 AM, Marton Balint wrote: > > > > > > > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > > > >> On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > > >>> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > >>> > > >>> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > > >>> >> As I described in similar threads before, whether or not the > > >>> project want >> closed source support for NDI is a subjective issue, > > >>> please start a vote >> about the removal of libndi if you want to > > >>> seek this through. > > >>> > > > >>> > The removal of libndi is actually done and committed. > > >>> > > >>> That is just sad an unfair. > > >> > > >> Sad, maybe. > > >> Unfair, I disagree. If NDI wants to be in, they know what to do. > > > > > > It is unfair towards the people who expressied disapproval, yet this > > > change was committed without neither vote nor consensus. > > > > +1. This was a political decision, not a technical one. A formal(-ish) > > survey should have happened on the ML. > > > > I agree we need a formal vote on this. I would like to set a wider project > policy w.r.t. closed-source software integration, this is just one instance > of a more general issue. I think there should have been a vote before pushing a commit as there where FFmpeg developers objecting to it. Ignoring people causes nothing good. Had there been a vote people would be alot less upset about it as everyones oppinion would be counted equally It makes me unhappy that one FFmpeg developer apparently decided to leave the project already because of this. I think we should fix this, make a proper policy, with a proper vote and then hopefully noone feels the need to leave. > > Who wants to organize it? Thilo organized the last vote, maybe he wants to do it ? but if noone else wants to do it i can do one too if people want and there is consensus who can vote If i search for "open source vote free" on google it points to vote.heliosvoting.org as first hit this seems rather basic but for simple yes/no questions it could work maybe someone has a better suggestion we could use for more complex future cases that is multiple choice votes in teh future (schulze STV / CPO-STV for multiwinner or ScottishSTV (used by SPI), schulze method (used by debian) for one winner of N choices would be nice to have) Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019, at 07:35, Dennis Mungai wrote: > And apparently calling out specific parties involved in this was translated > as an ad hominem attack. Single-outing one person, when you don't know half of the discussion is not a nice way of interacting within this project. Especially when you accuse another developer of the project, and claim they do what they do to profit from it for business reasons. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, Mar 21, 2019, 02:35 Ali KIZIL wrote: > Dennis Mungai , 20 Mar 2019 Çar, 23:20 tarihinde şunu > yazdı: > > > On Wed, 20 Mar 2019 at 23:02, Marton Balint wrote: > > > > > > > > > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > > > > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > > > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > >> > > > >> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > > > >> >> As I described in similar threads before, whether or not the > > project > > > want > > > >> >> closed source support for NDI is a subjective issue, please > start a > > > vote > > > >> >> about the removal of libndi if you want to seek this through. > > > >> > > > > >> > The removal of libndi is actually done and committed. > > > >> > > > >> That is just sad an unfair. > > > > > > > > Sad, maybe. > > > > Unfair, I disagree. If NDI wants to be in, they know what to do. > > > > > > It is unfair towards the people who expressied disapproval, yet this > > > change was committed without neither vote nor consensus. > > > > > > Regards, > > > Marton > > > > > > > > > > > At the very best, the lack of consensus on this implies vindictive > intent. > > Is there something that the FFmpeg developers (see below) have against > > Newtek, as a company? > > Clearly, they took down the offending FFmpeg build: > > https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10 > > > > We've seen other violations, such as this one by Amazon: > > https://trac.ffmpeg.org/ticket/7214 that were handled in a much more > > graceful manner. > > > > The primary agitator here seems to be kierank: > > https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10#comment:5 > > > > What undisclosed history do you have with Newtek (see the reference to > > "Andrew") above that isn't disclosed above? > > Secondly, you're quite influential in the broadcast industry: > > https://www.obe.tv/author/obe/ > > > > There's an aura of hostility around this commit, and whatever that is > seems > > to have spilled over into this. > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > The way of removal is not nice. There were an expectation to have a voting > for removal at the previous ML chain. > It feels the feeling of the patch is committed without any notice. > Sad, for the users who follow git-master and get notice for removal after > the commit. > And apparently calling out specific parties involved in this was translated as an ad hominem attack. Citing Newtek NDI as a "common" violator of the GPL *without* offering any evidence (a history of repeated prior behavior) is simply vindictive. What's the point of a consensus when it's assumed "the majority" agreed *without* an ML vote on the same? At this point, Kizil: Let sleeping dogs lie. This removal is purely political. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Dennis Mungai , 20 Mar 2019 Çar, 23:20 tarihinde şunu yazdı: > On Wed, 20 Mar 2019 at 23:02, Marton Balint wrote: > > > > > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > >> > > >> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > > >> >> As I described in similar threads before, whether or not the > project > > want > > >> >> closed source support for NDI is a subjective issue, please start a > > vote > > >> >> about the removal of libndi if you want to seek this through. > > >> > > > >> > The removal of libndi is actually done and committed. > > >> > > >> That is just sad an unfair. > > > > > > Sad, maybe. > > > Unfair, I disagree. If NDI wants to be in, they know what to do. > > > > It is unfair towards the people who expressied disapproval, yet this > > change was committed without neither vote nor consensus. > > > > Regards, > > Marton > > > > > > > At the very best, the lack of consensus on this implies vindictive intent. > Is there something that the FFmpeg developers (see below) have against > Newtek, as a company? > Clearly, they took down the offending FFmpeg build: > https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10 > > We've seen other violations, such as this one by Amazon: > https://trac.ffmpeg.org/ticket/7214 that were handled in a much more > graceful manner. > > The primary agitator here seems to be kierank: > https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10#comment:5 > > What undisclosed history do you have with Newtek (see the reference to > "Andrew") above that isn't disclosed above? > Secondly, you're quite influential in the broadcast industry: > https://www.obe.tv/author/obe/ > > There's an aura of hostility around this commit, and whatever that is seems > to have spilled over into this. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel The way of removal is not nice. There were an expectation to have a voting for removal at the previous ML chain. It feels the feeling of the patch is committed without any notice. Sad, for the users who follow git-master and get notice for removal after the commit. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Hi, On Wed, Mar 20, 2019 at 4:15 PM Gyan wrote: > > > On 21-03-2019 01:32 AM, Marton Balint wrote: > > > > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > >> On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > >>> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > >>> > >>> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > >>> >> As I described in similar threads before, whether or not the > >>> project want >> closed source support for NDI is a subjective issue, > >>> please start a vote >> about the removal of libndi if you want to > >>> seek this through. > >>> > > >>> > The removal of libndi is actually done and committed. > >>> > >>> That is just sad an unfair. > >> > >> Sad, maybe. > >> Unfair, I disagree. If NDI wants to be in, they know what to do. > > > > It is unfair towards the people who expressied disapproval, yet this > > change was committed without neither vote nor consensus. > > +1. This was a political decision, not a technical one. A formal(-ish) > survey should have happened on the ML. > I agree we need a formal vote on this. I would like to set a wider project policy w.r.t. closed-source software integration, this is just one instance of a more general issue. Who wants to organize it? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 21:20, Dennis Mungai wrote: > At the very best, the lack of consensus on this implies vindictive intent. > Is there something that the FFmpeg developers (see below) have against > Newtek, as a company? > Clearly, they took down the offending FFmpeg build: > https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10 That does not make the library NDI open-source or free... > We've seen other violations, such as this one by Amazon: > https://trac.ffmpeg.org/ticket/7214 that were handled in a much more > graceful manner. Amazon does not have a library inside FFMpeg that profits from the FFmpeg project. > The primary agitator here seems to be kierank: > > What undisclosed history do you have with Newtek (see the reference to > "Andrew") above that isn't disclosed above? > Secondly, you're quite influential in the broadcast industry: > https://www.obe.tv/author/obe/ Please refrain from ad hominem attacks. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 21:20, Nicolas George wrote: > Jean-Baptiste Kempf (12019-03-20): > > 2) Both of those are addressing drivers for actual cards. > > So we're not talking about userland, but accessing drivers which are > > part of the OS, and are therefore exempted by the GPL. > > I am not sure I agree with that interpretation. The wording is quite > [...] > It is not relevant for drivers, because drivers are not called directly, > [...] > That is my interpretation. Furthermore, the wording makes the case of This is the current interpretation by most people from the FSF and people from the open source legal community: "drivers and libraries installed usually with the drivers" are covered by the GPL exception. I checked last time with Bradley and Karen, but I can re-check next time I talk to them, if you do wish. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Jean-Baptiste Kempf (12019-03-20): > 2) Both of those are addressing drivers for actual cards. > So we're not talking about userland, but accessing drivers which are > part of the OS, and are therefore exempted by the GPL. I am not sure I agree with that interpretation. The wording is quite obscure, even for legalese, but the way I understand it, a library is a system library if, when somebody uses that particular operating system, we can be sure they have that library. It is not relevant for drivers, because drivers are not called directly, they are called by the kernel, and applications only call standard kernel interfaces. If some piece of hardware requires a library to be used, that library is not really a driver, and it does not count as a system library. That is my interpretation. Furthermore, the wording makes the case of system libraries an exception to the general rune, and AFAIK, in legal documents, exceptions are supposed to be interpreted in a very narrow way. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019 at 23:02, Marton Balint wrote: > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > >> > >> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > >> >> As I described in similar threads before, whether or not the project > want > >> >> closed source support for NDI is a subjective issue, please start a > vote > >> >> about the removal of libndi if you want to seek this through. > >> > > >> > The removal of libndi is actually done and committed. > >> > >> That is just sad an unfair. > > > > Sad, maybe. > > Unfair, I disagree. If NDI wants to be in, they know what to do. > > It is unfair towards the people who expressied disapproval, yet this > change was committed without neither vote nor consensus. > > Regards, > Marton > > > At the very best, the lack of consensus on this implies vindictive intent. Is there something that the FFmpeg developers (see below) have against Newtek, as a company? Clearly, they took down the offending FFmpeg build: https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10 We've seen other violations, such as this one by Amazon: https://trac.ffmpeg.org/ticket/7214 that were handled in a much more graceful manner. The primary agitator here seems to be kierank: https://trac.ffmpeg.org/ticket/7589?cversion=0_hist=10#comment:5 What undisclosed history do you have with Newtek (see the reference to "Andrew") above that isn't disclosed above? Secondly, you're quite influential in the broadcast industry: https://www.obe.tv/author/obe/ There's an aura of hostility around this commit, and whatever that is seems to have spilled over into this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 21:02, Marton Balint wrote: > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > >> > >> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > >> >> As I described in similar threads before, whether or not the project > >> >> want > >> >> closed source support for NDI is a subjective issue, please start a > >> >> vote > >> >> about the removal of libndi if you want to seek this through. > >> > > >> > The removal of libndi is actually done and committed. > >> > >> That is just sad an unfair. > > > > Sad, maybe. > > Unfair, I disagree. If NDI wants to be in, they know what to do. > > It is unfair towards the people who expressied disapproval, yet this > change was committed without neither vote nor consensus. Sorry, from my understanding, the majority is for removal. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 21-03-2019 01:32 AM, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: >> As I described in similar threads before, whether or not the project want >> closed source support for NDI is a subjective issue, please start a vote >> about the removal of libndi if you want to seek this through. > > The removal of libndi is actually done and committed. That is just sad an unfair. Sad, maybe. Unfair, I disagree. If NDI wants to be in, they know what to do. It is unfair towards the people who expressied disapproval, yet this change was committed without neither vote nor consensus. +1. This was a political decision, not a technical one. A formal(-ish) survey should have happened on the ML. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: >> As I described in similar threads before, whether or not the project want >> closed source support for NDI is a subjective issue, please start a vote >> about the removal of libndi if you want to seek this through. > > The removal of libndi is actually done and committed. That is just sad an unfair. Sad, maybe. Unfair, I disagree. If NDI wants to be in, they know what to do. It is unfair towards the people who expressied disapproval, yet this change was committed without neither vote nor consensus. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > >> As I described in similar threads before, whether or not the project want > >> closed source support for NDI is a subjective issue, please start a vote > >> about the removal of libndi if you want to seek this through. > > > > The removal of libndi is actually done and committed. > > That is just sad an unfair. Sad, maybe. Unfair, I disagree. If NDI wants to be in, they know what to do. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Marton Balint (12019-03-20): > That is just sad an unfair. Maybe. But let us be very clear about this: the people to blame for this mess are those who chose a proprietary license for their library in the first place. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: As I described in similar threads before, whether or not the project want closed source support for NDI is a subjective issue, please start a vote about the removal of libndi if you want to seek this through. The removal of libndi is actually done and committed. That is just sad an unfair. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > As I described in similar threads before, whether or not the project want > closed source support for NDI is a subjective issue, please start a vote > about the removal of libndi if you want to seek this through. The removal of libndi is actually done and committed. So I would suggest you start a vote to get the inclusion of libndi instead. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 18:03, Maksym Veremeyenko wrote: > On 20.03.2019 17:37, Jean-Baptiste Kempf wrote: > > On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: > [...] > >> We don't talk about a contribution remove for technical reason. > >> But a contributor's work remove in order to try to annoy a licence > >> violator. > > > > Absolutely not. The work was removed because the library is 100% closed > > source and userland. > > when do you plan to remove nVidia and BlackmagicDesign parts that is > /closed source and userland/ ? 0) addressing me directly like that is unfair, and unjust; notably when NDI was not removed by me. But let's say that this is just a miscommunication, and not a personal attack; so I will try to do a summary about those issues. 1) First, I've been quite vocal on those 2 topics, in the last few weeks, including today, about those 2, on IRC. And I've talked to the maintainers of those parts, notably Philip. 2) Both of those are addressing drivers for actual cards. So we're not talking about userland, but accessing drivers which are part of the OS, and are therefore exempted by the GPL. This is the case for both nVidia and Decklink. Not NDI. So, your point about userland does not really stand. 3) Both of those have headers that are open source. Not NDI. 3a) nVidia headers have a repository, that is actually maintained by people from this very project. The question about non-free on nVidia is about the compiler nvcc that is not open source. There is currently no-consensus whether this compiler is covered by the GPL exemption: are we in a similar case than java before openjdk, or the GNU project before gcc was created? 3b) Decklink headers are open source, but are normally distributed in a package that is not open-source. Whether the license of the headers is stronger than the package license is not clear. It is also not clear if someone who agreed to the package license can redistribute those headers to the other people? Best, -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Maksym Veremeyenko (12019-03-20): > when do you plan to remove nVidia and BlackmagicDesign parts that is /closed > source and userland/ ? "They were talking too" is not a good strategy when the teacher tells you to be quiet. But I count you as one vote for removing any non-free components. Thanks. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: > > >+Support for the nonfree NDI protocol has been removed, it had > > > been a common source of GPL violations. > > > > > This doesn't justify to break user tools (who respect the ffmpeg licence) > > tools who depend on a license violation are violating the license too... > FFmpeg can be compile with GPL and non free component, if the build is not redistributed. There is no licence violation in this case. The non-free flag was done for incompatible open source license, and used for complex compiler licensing issue. Not for obviously-closed-userland libraries. It's not because some people doesn't respect the licence, that every user of non free component do the same. Sorry, but that ship has sailed. Complaining over and over will not change it. > > and remove contributor's work. > > Sorry, but lots of contributor work were removed over the years. A > software lives. We don't talk about a contribution remove for technical reason. But a contributor's work remove in order to try to annoy a licence violator. Absolutely not. The work was removed because the library is 100% closed source and userland. Then I suggest to put that into the news entry instead. As I described in similar threads before, whether or not the project want closed source support for NDI is a subjective issue, please start a vote about the removal of libndi if you want to seek this through. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 20.03.2019 17:37, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: [...] We don't talk about a contribution remove for technical reason. But a contributor's work remove in order to try to annoy a licence violator. Absolutely not. The work was removed because the library is 100% closed source and userland. when do you plan to remove nVidia and BlackmagicDesign parts that is /closed source and userland/ ? -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: > > > >+Support for the nonfree NDI protocol has been removed, it had > > > > been a common source of GPL violations. > > > > > > > This doesn't justify to break user tools (who respect the ffmpeg licence) > > > > tools who depend on a license violation are violating the license too... > > > > FFmpeg can be compile with GPL and non free component, if the build is not > redistributed. > There is no licence violation in this case. The non-free flag was done for incompatible open source license, and used for complex compiler licensing issue. Not for obviously-closed-userland libraries. > It's not because some people doesn't respect the licence, that every user > of non free component do the same. Sorry, but that ship has sailed. Complaining over and over will not change it. > > > and remove contributor's work. > > > > Sorry, but lots of contributor work were removed over the years. A > > software lives. > > We don't talk about a contribution remove for technical reason. > But a contributor's work remove in order to try to annoy a licence > violator. Absolutely not. The work was removed because the library is 100% closed source and userland. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Martin Vignali (12019-03-20): > FFmpeg can be compile with GPL and non free component, if the build is not > redistributed. > There is no licence violation in this case. > > It's not because some people doesn't respect the licence, that every user > of non free component do the same. Making it easy to infringe can be considered acting as an accessory. FFmpeg is being an accessory to infringing its own license! Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
> > >+Support for the nonfree NDI protocol has been removed, it had > > > been a common source of GPL violations. > > > > > This doesn't justify to break user tools (who respect the ffmpeg licence) > > tools who depend on a license violation are violating the license too... > FFmpeg can be compile with GPL and non free component, if the build is not redistributed. There is no licence violation in this case. It's not because some people doesn't respect the licence, that every user of non free component do the same. > > > and remove contributor's work. > > Sorry, but lots of contributor work were removed over the years. A > software lives. > We don't talk about a contribution remove for technical reason. But a contributor's work remove in order to try to annoy a licence violator. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Tue, 19 Mar 2019, at 21:37, Martin Vignali wrote: > >+Support for the nonfree NDI protocol has been removed, it had > > been a common source of GPL violations. > > > This doesn't justify to break user tools (who respect the ffmpeg licence) tools who depend on a license violation are violating the license too... > and remove contributor's work. Sorry, but lots of contributor work were removed over the years. A software lives. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
2019-03-19 20:11 GMT+01:00, Gyan : > > > On 20-03-2019 12:03 AM, Kieran Kunhya wrote: > > >From a84db9c39d382a37f76ae72e490d25ca451155c4 Mon Sep 17 00:00:00 2001 > >From: Kieran Kunhya > >Date: Tue, 19 Mar 2019 18:31:39 + > >Subject: [PATCH] News: Removal of libndi > > > >--- > > src/index | 5 + > > 1 file changed, 5 insertions(+) > > > >diff --git a/src/index b/src/index > >index 0dcf6c1..a5de03e 100644 > >--- a/src/index > >+++ b/src/index > >@@ -37,6 +37,11 @@ > > News > > > > > >+ March 19th, 2019, libndi removed. > >+ > >+Support for the nonfree NDI protocol has been removed, > > it had been a common source of GPL violations. common? > Do you have citations for these violation*s*? I'm only aware > of Newtek's distribution of ffmpeg in their SDK, as reported > in trac #7589. Are there others? I wish this would have been addressed. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
>+Support for the nonfree NDI protocol has been removed, it had > been a common source of GPL violations. > > This doesn't justify to break user tools (who respect the ffmpeg licence) and remove contributor's work. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 20-03-2019 12:03 AM, Kieran Kunhya wrote: >From a84db9c39d382a37f76ae72e490d25ca451155c4 Mon Sep 17 00:00:00 2001 >From: Kieran Kunhya >Date: Tue, 19 Mar 2019 18:31:39 + >Subject: [PATCH] News: Removal of libndi > >--- > src/index | 5 + > 1 file changed, 5 insertions(+) > >diff --git a/src/index b/src/index >index 0dcf6c1..a5de03e 100644 >--- a/src/index >+++ b/src/index >@@ -37,6 +37,11 @@ > News > > >+ March 19th, 2019, libndi removed. >+ >+ Support for the nonfree NDI protocol has been removed, it had been a common source of GPL violations. Do you have citations for these violation*s*? I'm only aware of Newtek's distribution of ffmpeg in their SDK, as reported in trac #7589. Are there others? >+ >+ > November 6th, 2018, FFmpeg 4.1 "al-Khwarizmi" > > FFmpeg 4.1 "al-Khwarizmi", a new >-- >1.9.1 > > Trailing whitespace present. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
