[FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Carl Eugen Hoyos]

Hi!

It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.

Patch untested.

Please comment, Carl Eugen

[Gyan Doshi]

Post by Carl Eugen Hoyos
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.

What's the link to the blog post?

Also, is anyone from Newtek on the ML - if not, is there someone we can
invite for input?


Gyan

[Carl Eugen Hoyos]

Post by Gyan Doshi

Post by Carl Eugen Hoyos
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.

I should clarify that I did not verify the issue myself, ie in theory it
could be that NewTek does not distribute non-free binaries based on
FFmpeg source code.

Post by Gyan Doshi
What's the link to the blog post?
Also, is anyone from Newtek on the ML - if not, is there someone we
can invite for input?

What kind of input would seem useful to you in this case?

Carl Eugen

[Gyan Doshi]

Post by Carl Eugen Hoyos

Post by Gyan Doshi
What's the link to the blog post?
Also, is anyone from Newtek on the ML - if not, is there someone we
can invite for input?

What kind of input would seem useful to you in this case?

Insight on what they were thinking. If it's a careless oversight, it can
be remedied and this patch is not needed. But we should hear from them,
ideally.

Gyan

[Kyle Schwarz]

Post by Gyan Doshi

Post by Carl Eugen Hoyos
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.

What's the link to the blog post?

https://www.newtek.com/blog/introducing-ndi-3-5/

Post by Gyan Doshi
... and we even include FFMPEG for Windows with NDI support for your convenience, eliminating the hassle of working out how to compile it yourself.

[Nicolas George]

Post by Kyle Schwarz
https://www.newtek.com/blog/introducing-ndi-3-5/

Post by Gyan Doshi
... and we even include FFMPEG for Windows with NDI support for your convenience, eliminating the hassle of working out how to compile it yourself.

That is not how it is supposed to work. If they want to include FFmpeg
for their users' convenience, they have to make their software
LGPL-compatible.

Because "their users' convenience" is good publicity for them, they have
to pay for it, not us.

Regards,

[Dennis Mungai]

In this case , Carl's decision to strip their code from FFmpeg is valid.
This is a clear violation of the license terms.

Post by Gyan Doshi

Post by Kyle Schwarz
https://www.newtek.com/blog/introducing-ndi-3-5/

Post by Gyan Doshi
... and we even include FFMPEG for Windows with NDI support for your

convenience, eliminating the hassle of working out how to compile it
yourself.
That is not how it is supposed to work. If they want to include FFmpeg
for their users' convenience, they have to make their software
LGPL-compatible.
Because "their users' convenience" is good publicity for them, they have
to pay for it, not us.
Regards,
--
Nicolas George
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Nicolas George]

Post by Dennis Mungai
In this case , Carl's decision to strip their code from FFmpeg is valid.
This is a clear violation of the license terms.

Indeed.

And please stop top-posting. If you do not know what it means, look it
up.

Regards,

[Dennis Mungai]

Hello there,

Has Newtek NDI been given a chance to rectify this from their end? This is
clearly a license violation, but taking drastic steps such as stripping
support for their protocols is a knee jerk reaction.

Let them respond before merging this PR.

Regards,

Dennis.

Post by Carl Eugen Hoyos
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.
Please comment, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Carl Eugen Hoyos]

Post by Dennis Mungai
Has Newtek NDI been given a chance to rectify this from their end?

Why do you believe that this would be a useful way to go?

Post by Dennis Mungai
This is clearly a license violation, but taking drastic steps such
as stripping support for their protocols is a knee jerk reaction.

Why?
Have you ever dealt with open-source license violations?

Please do not top-post here, Carl Eugen

[Dennis Mungai]

Carl,

If it is indeed an abuse of the license terms, as you've purported, it
would be wise to get their input on this, as Gyan Doshi has elaborated
above. They are contributors to this project, and it falls to reason that
the burden of addressing this falls on them.

Moving forward with such drastic steps only portrays arrogance , which is
uncalled for. I've seen contributors here deal with the likes of Amazon
(the recent NGCodec patch license issue comes to mind) and had that issue
resolved in an amicable manner. So why can't the same be done with Newtek?

Post by Carl Eugen Hoyos

Post by Dennis Mungai
Has Newtek NDI been given a chance to rectify this from their end?

Why do you believe that this would be a useful way to go?

Post by Dennis Mungai
This is clearly a license violation, but taking drastic steps such
as stripping support for their protocols is a knee jerk reaction.

Why?
Have you ever dealt with open-source license violations?
Please do not top-post here, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Timo Rothenpieler]

I contacted NewTek about this, here's the pretty much immediate response

Yikes, I am pretty surprised by this to be honest I think that our intent might have been entirely misconstrued.
We are in no way trying to abuse anything anyone did and if they want us to not distribute FFMPEG then we'd be very happy to stop doing that ... we did this purely as a public service because loads of people complained (hundreds) to use about NDI not being part of the FFMPEG nightly builds. We had initially tried to help make it part of the nightly builds but got a lot of push-back and it did not seem worth the fight (our headers are MIT licensed and you can download our run-times for free, so it is no different than say nvEnc, etc... that are all parts of the builds). At the end of the day, we make no money of NDI and just give it away and support it for free so it is hardly part of an evil ploy to corrupt anyone ;)
I'd prefer not to jump in the middle of the thread, but we are happy to work with anyone on this, our only goal is to serve people using NDI and if FFMPEG do not want us to distribute it then we're happy to do that, likewise if they want us to change the options we're also happy to do that. We'd be happy to do what we reasonably can for it to be part of the nightly builds as well ...
Feel free to pass this along and anyone can email me directly who wants too.
Andrew

I think the easiest way out here would be to make an LGPL build instead?
libndi can still be enabled then, but the build isn't nonfree.
libx264 would have to go, but that's probably still better for them than
removing ffmpeg entirely.

[Carl Eugen Hoyos]

Post by Timo Rothenpieler
I contacted NewTek about this, here's the pretty much immediate response

Yikes, I am pretty surprised by this to be honest I think that our intent
might have been entirely misconstrued.

(Note that this is hard to believe but this is not relevant.)

Post by Timo Rothenpieler

We are in no way trying to abuse anything anyone did and if they want us
to not distribute FFMPEG then we'd be very happy to stop doing that ... we
did this purely as a public service because loads of people complained
(hundreds) to use about NDI not being part of the FFMPEG nightly builds.
We had initially tried to help make it part of the nightly builds but got
a lot of push-back and it did not seem worth the fight (our headers are
MIT licensed and you can download our run-times for free, so it is no
different than say nvEnc, etc... that are all parts of the builds). At the
end of the day, we make no money of NDI and just give it away and support
it for free so it is hardly part of an evil ploy to corrupt anyone ;)
I'd prefer not to jump in the middle of the thread, but we are happy to
work with anyone on this, our only goal is to serve people using NDI and
if FFMPEG do not want us to distribute it then we're happy to do that,
likewise if they want us to change the options we're also happy to do
that. We'd be happy to do what we reasonably can for it to be part of the
nightly builds as well ...
Feel free to pass this along and anyone can email me directly who wants too.

Don't you agree that there is something missing in this message?

Post by Timo Rothenpieler

Andrew

I think the easiest way out here would be to make an LGPL build instead?

What kind of message does this send to future license violators?

Carl Eugen

[Jan Ekström]

Post by Carl Eugen Hoyos
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.
Please comment, Carl Eugen

On the general idea of this - agreed.

Separately I think we should at least bring up a possible rethink of
our policy about non-open source nonfree components.

If it's:
- Not part of the OS
or
- Not open source

...maybe we should not include such a component upstream?

Best regards,
Jan

[Paul B Mahol]

Post by Jan Ekström

Post by Carl Eugen Hoyos
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.
Please comment, Carl Eugen

On the general idea of this - agreed.
Separately I think we should at least bring up a possible rethink of
our policy about non-open source nonfree components.
- Not part of the OS
or
- Not open source
...maybe we should not include such a component upstream?

Yes, remove all hardware stuff +1.

[Ali KIZIL]

Post by Paul B Mahol

Post by Jan Ekström

Post by Carl Eugen Hoyos
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.
Please comment, Carl Eugen

On the general idea of this - agreed.
Separately I think we should at least bring up a possible rethink of
our policy about non-open source nonfree components.
- Not part of the OS
or
- Not open source
...maybe we should not include such a component upstream?

Yes, remove all hardware stuff +1.
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
While there is a non-free option and while there are lots of HW related
implementations done by developers in such condition for long time, I
believe it is not right to remove all thesd valuable work. This will
definitely break to courage to submit new developments to FFmpeg.

I also think, Newtek is not in a way to hide things as they share the post.
I believe they thought their approach is normal, when considering the
current case examples.

[Jan Ekström]

Post by Paul B Mahol

Post by Jan Ekström

Post by Carl Eugen Hoyos
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.
Please comment, Carl Eugen

On the general idea of this - agreed.
Separately I think we should at least bring up a possible rethink of
our policy about non-open source nonfree components.
- Not part of the OS
or
- Not open source
...maybe we should not include such a component upstream?

Yes, remove all hardware stuff +1.

That's something different, though.

- dxva2 and d3d11va are Windows APIs, thus fall under "OS"
- VT on mac/iOS does the same
- vaapi and the kernel API seem to be compatible with GPL (at least
currently), so they would stay.
- out of similar things such as NDI, SRT seems to be open source now?

Jan

[Martin Vignali]

Post by Carl Eugen Hoyos
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.
Please comment, Carl Eugen

This patch looks wrong to me.

It's seems like removing features for personal opinion.

Ticket 7589, mention an incorrect build redistribution.

So, right way to fix this ticket, will be (for people interesting in this
kind of thing)
to indicate, what need to be done, in order to have a licence compliant
build.
And if building in LGPL, it's a solution for provide a right binary,
doesn't really understand, what
it's not better mention in this ticket.

And if some people have personal issue with this company, i doesn't think
this mailing list and trac it's really the right place for discussing it.

I agree with Ali Kizil,
And the answer of newtek looks not so bad for me.
The problem is maybe a licence violation (don't know and don't care),
but it's very far away of selling a software with licence violation in it.

This kind of agressive patch, send a very strange signal to current and
future contributors/users.

FFmpeg keep some options for compatibility in long term, but can remove a
future useful for some people so fast (just because some people would like
to send a sanction/message) ?

Martin

[Carl Eugen Hoyos]

Post by Martin Vignali

Post by Carl Eugen Hoyos
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.
Please comment, Carl Eugen

This patch looks wrong to me.
It's seems like removing features for personal opinion.

This is a lie.
(I don't care.)

Post by Martin Vignali
Ticket 7589, mention an incorrect build redistribution.
So, right way to fix this ticket, will be (for people interesting in this
kind of thing)
to indicate, what need to be done, in order to have a licence compliant
build.

Again: What message would this send to future license violators?

Since you are throwing accusations:
Please remind me how many license violations you have worked on.

Carl Eugen

[Ali KIZIL]

Post by Carl Eugen Hoyos

Post by Martin Vignali

Post by Carl Eugen Hoyos
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See

Ticket

Post by Martin Vignali

Post by Carl Eugen Hoyos
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.
Please comment, Carl Eugen

This patch looks wrong to me.
It's seems like removing features for personal opinion.

This is a lie.
(I don't care.)

Post by Martin Vignali
Ticket 7589, mention an incorrect build redistribution.
So, right way to fix this ticket, will be (for people interesting in this
kind of thing)
to indicate, what need to be done, in order to have a licence compliant
build.

Again: What message would this send to future license violators?
Please remind me how many license violations you have worked on.
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Newtek representative says, they will remove the binary from SDK right away
and will stop distributing as its current state with passing their
apologies, while accepting their mistake.

I do not understand that how it is being decided to remove a complete work
against a non-free distribution.

I suggest to not to take immediate harsh actions without fully discussing
the side effects.

Personally, I do not believe they break the license on purpose. If so, they
wouldn't announce it. They would fo as some others do, by trying hide. So
personally, I think removal of code is a very strong decision for this
kind of revertible violation, as Newtek also gets in response asap.

[Nicolas George]

Post by Ali KIZIL
Personally, I do not believe they break the license on purpose. If so, they

They are a commercial entity, they have a legal department. "Not on
purpose" is not an excuse for them.

Post by Ali KIZIL
wouldn't announce it. They would fo as some others do, by trying hide. So
personally, I think removal of code is a very strong decision for this
kind of revertible violation, as Newtek also gets in response asap.

The only acceptable response from them now is to comply with the GPL.
This is exactly how the GPL is stated: a failure to comply with the
copyleft clauses rescinds all rights to use the original GPLed code.

Note that they did not only infringe on FFmpeg's license, they also
infringed on x264.

Regards,

[Carl Eugen Hoyos]

Post by Ali KIZIL
Newtek representative says, they will remove the binary from SDK right away

Could you please read the sentence you sent?
Particularly the words "says" and "will".

They did not remove the binariy when informed about the
license violations!
(At least, there is no indication they did.)

Post by Ali KIZIL
Personally, I do not believe they break the license on purpose.

Did you read the post on their support forum where the very
person claiming now he had no idea it is wrong answered to
the information that distributing such binaries is illegal?

Carl Eugen

[Ali KIZIL]

Post by Carl Eugen Hoyos

Post by Ali KIZIL
Newtek representative says, they will remove the binary from SDK right

away
Could you please read the sentence you sent?
Particularly the words "says" and "will".
They did not remove the binariy when informed about the
license violations!
(At least, there is no indication they did.)

Post by Ali KIZIL
Personally, I do not believe they break the license on purpose.

Did you read the post on their support forum where the very
person claiming now he had no idea it is wrong answered to
the information that distributing such binaries is illegal?
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

https://trac.ffmpeg.org/ticket/7589

Sent by across:
...
If we have offended anyone then I sincerely apologize and please accept
that it was not our intent. We will remove FFMPEG entirely from our SDK and
get it patched online today.
...

Post by Carl Eugen Hoyos
I didn't read the forums, yet I take care of what he is saying and if they
are going to remove compiled binary from their SDK with an official
apology.

[Paul B Mahol]

Post by Carl Eugen Hoyos

Post by Martin Vignali
Ticket 7589, mention an incorrect build redistribution.
So, right way to fix this ticket, will be (for people interesting in this
kind of thing)
to indicate, what need to be done, in order to have a licence compliant
build.

Again: What message would this send to future license violators?
Please remind me how many license violations you have worked on.

What is this now? Why are you still here?

[Jean-Baptiste Kempf]

Post by Carl Eugen Hoyos
Again: What message would this send to future license violators?

A bad one.

I would remove this.

[Jan Ekström]

Post by Martin Vignali
This patch looks wrong to me.
It's seems like removing features for personal opinion.
Ticket 7589, mention an incorrect build redistribution.
So, right way to fix this ticket, will be (for people interesting in this
kind of thing)
to indicate, what need to be done, in order to have a licence compliant
build.
And if building in LGPL, it's a solution for provide a right binary,
doesn't really understand, what
it's not better mention in this ticket.

Actually, I'm not 100% sure if a closed source blob is LGPL compatible
this way - although the other way a closed source blob can include an
LGPL component as long as they provide the sources and the means to
replace the LGPL component (aka either shared libraries, or object
files for static linking). I don't remember who exactly was it whom
planted this idea in my mind (unrelated to NDI completely for the
record), but it did pop up in some discussion. Hopefully that someone
can chime in once again if he notices this.

Post by Martin Vignali
And if some people have personal issue with this company, i doesn't think
this mailing list and trac it's really the right place for discussing it.

I think rather than having an issue with the company, some people are
having an issue with how it seems to have dealt with people who have
attempted to implement their protocol in open source (legal threats
were mentioned). Whether that is true or not I do not know, but as far
as I last saw on the issue tracker's thread there seems to be an
attempt of making it look better than it is.

I remember looking at their site and seeing their solution being
marketed as a "standard", yet there was no specification and they
clearly were only interested in their blob. But knowing nothing much
else, it was mostly on the "meh" level and thus I did not enough
strength to put enough care into looking into it more (at the time of
the patches).

Post by Martin Vignali
I agree with Ali Kizil,
And the answer of newtek looks not so bad for me.
The problem is maybe a licence violation (don't know and don't care),
but it's very far away of selling a software with licence violation in it.
This kind of agressive patch, send a very strange signal to current and
future contributors/users.

Yes, I agree. We should have a more clear policy on non-OSS
contributions. Although to be completely honest the whole FFmpeg
development process is a mess. But I think we should keep this
discussion to NDI.

Post by Martin Vignali
FFmpeg keep some options for compatibility in long term, but can remove a
future useful for some people so fast (just because some people would like
to send a sanction/message) ?

If you think NDI is useful, I dearly hope you agree that it would be
more useful to you compatible with OSS licenses. Or even more so if it
was open source.

Jan

[Jean-Baptiste Kempf]

Post by Paul B Mahol

Post by Jan Ekström
On the general idea of this - agreed.
Separately I think we should at least bring up a possible rethink of
our policy about non-open source nonfree components.
- Not part of the OS
or
- Not open source
...maybe we should not include such a component upstream?

Yes, remove all hardware stuff +1.

Libraries to access hardware, notably those that are talking directly with something that was shipped with the drivers, are usually considered part of the OS. This is a bit weird, but this extend the Linux way to other (broken) OSes.

That would make nvenc and such acceptable.

NDI is not hardware. (Nor is faac)

[Marton Balint]

Post by Jean-Baptiste Kempf

Post by Paul B Mahol

Post by Jan Ekström
On the general idea of this - agreed.
Separately I think we should at least bring up a possible rethink of
our policy about non-open source nonfree components.
- Not part of the OS
or
- Not open source
...maybe we should not include such a component upstream?

Yes, remove all hardware stuff +1.

Libraries to access hardware, notably those that are talking directly with something that was shipped with the drivers, are usually considered part of the OS. This is a bit weird, but this extend the Linux way to other (broken) OSes.
That would make nvenc and such acceptable.
NDI is not hardware. (Nor is faac)

I really don't want to troll here, but there is an NDI PTZ camera:

https://www.newtek.com/camera/ndihx-ptz1/

So is it really that different to a USB camera just because the
singalling is going through ethernet and not USB?

Regards,
Marton

[Ali KIZIL]

Post by Jean-Baptiste Kempf

Post by Jean-Baptiste Kempf

Post by Paul B Mahol

Post by Jan Ekström
On the general idea of this - agreed.
Separately I think we should at least bring up a possible rethink of
our policy about non-open source nonfree components.
- Not part of the OS
or
- Not open source
...maybe we should not include such a component upstream?

Yes, remove all hardware stuff +1.

Libraries to access hardware, notably those that are talking directly

with something that was shipped with the drivers, are usually considered
part of the OS. This is a bit weird, but this extend the Linux way to other
(broken) OSes.

Post by Jean-Baptiste Kempf
That would make nvenc and such acceptable.
NDI is not hardware. (Nor is faac)

https://www.newtek.com/camera/ndihx-ptz1/
So is it really that different to a USB camera just because the
singalling is going through ethernet and not USB?
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

+1 or PCIe

Just a suggestion: there can be a request from well known brands who are
making contributions to FFmpeg to donate for hiring a lawyer who has
proficiency on OSS subject for both US and EU laws. It will be for their
and community's benefit, as there will be an independent point of view. I
believe there can be donators from community too. Time to time, it is
noticable users as asking for non-free compile subject.

This approach can bring a proper action for similar cases and avoid in
further. The lawyer can be supportive on CoC subject either.

[Jean-Baptiste Kempf]

Post by Marton Balint

Post by Jean-Baptiste Kempf
Libraries to access hardware, notably those that are talking directly with something that was shipped with the drivers, are usually considered part of the OS. This is a bit weird, but this extend the Linux way to other (broken) OSes.
That would make nvenc and such acceptable.
NDI is not hardware. (Nor is faac)

https://www.newtek.com/camera/ndihx-ptz1/
So is it really that different to a USB camera just because the
singalling is going through ethernet and not USB?

Yes, because NDI is a network protocol. Those cameras exposes streams, like RTSP.
They are servers, so they are not part of your machine.

[Martin Vignali]

There is a mix of several discussion in this thread, which need to be
discuss separately.

1 - Licence violation on a build.
2 - Opinion on Newtek behaviour
3 - Inclusion of non open source part
4 - Removal of libndi device

1 :
Doesn't really understand, how this licence violation can be fix in
modifying the source code.
Removing features used by people which doesn't respect the licence, seems a
very bad thing.

2 - Nothing to do in this mailing list. Except trying to influence
technical aspect, with emotional stuff.
"It appears to me that NewTek abused our willingness..."
or "Newtek is a big bully against open source developers, threatening to
sue."
is not really what we can call "a technical argument".
The choice of adding or removing a feature, is (i hope) not link, to the
behaviour of the original creator.

3 - Need a proper definition, and a dedicated discussion. To avoid
including code that it's not conform to the global policy of this project.
Reading this thread, it's seems like there is lot of interpretation about
acceptable and non acceptable not opensource part.
- ok for not open source part from os
- ok for not open source part for "hardware thing", because we can think
it's like os thing !
- ok from not open source part, if it's useful ? or not ?
What definition of useful ? (and everything related to broadcast is not
useless, just because not everyone use it !)

4 - libndi device is part of ffmpeg for now. Removing it without at least a
deprecation period, will just break by surprise every working tools based
on that
even for user who respect the terms of the licence and build themselves
ffmpeg with this support (like mention by Marton Balint).
Bad message send to people who respect the licence ! :-)

And yes, it's better to have full opensource ndi support, instead of the
current situation.
But it's not a reason to remove features for users.


Martin

[Carl Eugen Hoyos]

Post by Martin Vignali
There is a mix of several discussion in this thread, which need to be
discuss separately.
1 - Licence violation on a build.

[...]

Post by Martin Vignali
Doesn't really understand, how this licence violation can be fix in
modifying the source code.

Where was this claimed / who thinks so?

Carl Eugen

[Jean-Baptiste Kempf]

Helllo,

Post by Martin Vignali
Removing features used by people which doesn't respect the licence, seems a
very bad thing.

I disagree with you.
Helping people violating open source licenses is not a good idea.

Post by Martin Vignali
3 - Need a proper definition, and a dedicated discussion. To avoid
including code that it's not conform to the global policy of this project.
Reading this thread, it's seems like there is lot of interpretation about
acceptable and non acceptable not opensource part.

The thing is, the license is the license, and there are a lot of explanations from FSF, FSFE, SFLC, and sooo many others.

Post by Martin Vignali
- ok for not open source part from os
- ok for not open source part for "hardware thing", because we can think
it's like os thing !

Yes, and this is quite documented, as part of all the GPL family of licenses, as part of "System Libraries".

Post by Martin Vignali
- ok from not open source part, if it's useful ? or not ?
What definition of useful ? (and everything related to broadcast is not
useless, just because not everyone use it !)

You cannot define usefulness easily.

Post by Martin Vignali
And yes, it's better to have full opensource ndi support, instead of the
current situation.
But it's not a reason to remove features for users.

But then, you will get absolutely all the integration from ALL the various non-open source multimedia libraries, because it is useful to someone. Including shims for Adobe, Dolby and others.
And what is the incentive to do open source alternatives?

[Martin Vignali]

Post by Jean-Baptiste Kempf
Helllo,

Post by Martin Vignali
Removing features used by people which doesn't respect the licence,

seems a

Post by Martin Vignali
very bad thing.

I disagree with you.
Helping people violating open source licenses is not a good idea.

It's not just about helping Newtek or not.
My intervention in this discussion is mainly about annoy ndi/ffmpeg user
(including those who respect licence)

Of course Newtek have some interest of having ndi support inside ffmpeg
but some user can also have an interest to have this feature.

It's similar for me to other manufacturer things (for example decklink
device support have a benefit for blackmagic
and for user who need SDI record/playback).

Post by Jean-Baptiste Kempf

Post by Martin Vignali
3 - Need a proper definition, and a dedicated discussion. To avoid
including code that it's not conform to the global policy of this

project.

Post by Martin Vignali
Reading this thread, it's seems like there is lot of interpretation about
acceptable and non acceptable not opensource part.

The thing is, the license is the license, and there are a lot of
explanations from FSF, FSFE, SFLC, and sooo many others.

Post by Martin Vignali
- ok for not open source part from os
- ok for not open source part for "hardware thing", because we can think
it's like os thing !

Yes, and this is quite documented, as part of all the GPL family of
licenses, as part of "System Libraries".

Post by Martin Vignali
- ok from not open source part, if it's useful ? or not ?
What definition of useful ? (and everything related to broadcast is not
useless, just because not everyone use it !)

You cannot define usefulness easily.

That's exactly what I meant.

For including or not, some not opensource part, there will be two case
- the part which can be included in redistributable build
(i let people who have knowledge on this to decide which part can be in
these builds)

- the part which can not be included in redistributable build, and need
that the user compile himself
to enable some functionnality.
If this is just about having the right (in licence point of view) to
include or not in these kind of build,
here too i will let people with licence knowledge decide.

But if including or not, a not opensource part, it's about opinion on
utility of this part, this need to be better define.
This will avoid discussion about being useful or not, depending of opinion
of each one at the moment of a patch submission.

An impartial way, can be for example, if the component is free (in the
sense without additionnal cost) and provide a functionality not available
in another way.

Post by Jean-Baptiste Kempf

Post by Martin Vignali
And yes, it's better to have full opensource ndi support, instead of the
current situation.
But it's not a reason to remove features for users.

But then, you will get absolutely all the integration from ALL the various
non-open source multimedia libraries, because it is useful to someone.
Including shims for Adobe, Dolby and others.

I'm probably disagree with you on this subject ! :-)

Post by Jean-Baptiste Kempf
And what is the incentive to do open source alternatives?

In a manufacturer point of view : having the functionnality available to a
wider audience, because it can be included in distributable build.

In user/contributor point of view : having more sustainability on a
feature. A full opensource code can still working if some people
have an interest of maintain/improve it.

Martin

[Ronald S. Bultje]

Hi,

Post by Jean-Baptiste Kempf

Post by Jean-Baptiste Kempf
But then, you will get absolutely all the integration from ALL the

various

Post by Jean-Baptiste Kempf
non-open source multimedia libraries, because it is useful to someone.
Including shims for Adobe, Dolby and others.

I'm probably disagree with you on this subject ! :-)

https://patchwork.ffmpeg.org/patch/7329/ (see also my response to that [1])

Or just on IRC today (!)
"<LigH> JVET VVC just got ready to be built with MSYS/MinGW too ... so I
guess it is not yet in a stage to be considered to be linked into ffmpeg.
What would be your criteria to consider this encoder? How would we get to
know that you start considering it? Looking for a thread in the mailing
list?"

I'm surprised this patch made it in, I've always assumed we were
uncomfortable with closed-source software and that the hardware-support was
a corner-case. Can I submit a wrapper for my closed-source VP9 encoder?

Ronald

[1]
https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-for-librv11-and-rmhd-muxer-demuxer#post35

[Jean-Baptiste Kempf]

Post by Martin Vignali

Post by Jean-Baptiste Kempf
But then, you will get absolutely all the integration from ALL the various
non-open source multimedia libraries, because it is useful to someone.
Including shims for Adobe, Dolby and others.

I'm probably disagree with you on this subject ! :-)

Then, this is the crux of the discussion: do you want every non-open-source library to be in FFmpeg?
For hardware acceleration and drivers, the cut is quite clear. For the rest, I'm not so sure.

If so, be prepared for a LOT of patches, for everything under the world, starting with librv11, and Eve and so on.

[Nicolas George]

Post by Jan Ekström
Separately I think we should at least bring up a possible rethink of
our policy about non-open source nonfree components.
- Not part of the OS
or
- Not open source
...maybe we should not include such a component upstream?

I agree.

Maybe we can make an exception when the non-free upstream is dead yet
useful, like faac was for some time. But for contributors like this NDI
thing, either they make the build components (L)GPL-compatible or they
do not enjoy the benefit of being included.

Regards,

[Marton Balint]

Post by Carl Eugen Hoyos
Hi!
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.

You should think about our users who compile and use ffmpeg with
NDI. This change affects them negatively, so I don't support it.

Regards,
Marton

[Nicolas George]

You should think about our users who compile and use ffmpeg with NDI. This
change affects them negatively, so I don't support it.

They chose to use hardware that only works with non-free software. They
made their bed.

I support the removal.

Regards,

[Jean-Baptiste Kempf]

Post by Carl Eugen Hoyos
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.

+1, please apply.

Newtek is a big bully against open source developers, threatening to sue.

This is a violation, done on purpose (see the message when running the binary, and see the blogpost where they knew about it for months), of both FFmpeg and maybe x264.

Keeping this wrapper just helps people violate the FFmpeg license and the GPL.

Best,

[Carl Eugen Hoyos]

Post by Carl Eugen Hoyos
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.

After several people have objected claiming NewTek would fix this
situation, a week has passed: No visible reaction whatsoever, not
even requesting more time.
What are those suggesting who were against this patch?

Contact Newtek with your concerns and a deadline and what
action you're considering beyond the deadline.

Done.

Thank you, Carl Eugen

[Ali KIZIL]

Post by Carl Eugen Hoyos
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.
Patch untested.

After several people have objected claiming NewTek would fix this
situation, a week has passed: No visible reaction whatsoever, not
even requesting more time.
What are those suggesting who were against this patch?

Contact Newtek with your concerns and a deadline and what action you're
considering beyond the deadline.
Gyan

Newtek released 3.7.1 version of their SDK which does not include ffmpeg.exe

md5sum is:
e2a29174333f20cb6cc66ec5e27ccbf3 Downloads/NewTek NDI 3.7.1 SDK.exe