NewTek distributing non-free FFmpeg build

[Zeranoe]

It looks like NewTek is providing a non-free FFmpeg build with their Windows 3.7 NDI SDK:

>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
  libavformat    58. 12.100 / 58. 12.100
  libavdevice    58.  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.

[Carl Eugen Hoyos]

Patch sent, thank you for the report!

[NewTek]

Thanks a lot for this bug report and I sincerely apologize if we have done anything at all that was not correct, that certainly was not the goal at all. We included ffmpeg pre-compiled in our SDK purely as a convenience for users (we have had hundreds of requests for this) and we took care to avoid misrepresenting anything.

Ultimately we just have a very large number of people who want to use NDI with ffmpeg and do not want the hassle of working out how to compile it. Our preferred goal would always be to find a way for others to do this and we changed out header files to an MIT license and our run-time libraries are an entirely separate download that has entirely separate functionality.

Regardless, if someone wants to contact us we're more than happy to do whatever the ffmpeg community wants here. Our ultimate goal is to make things easy for everyone and help anyone who wants to use NDI have an easy way to do so. Feel free to each out to me if anyone wants to talk about the best way to handle this and we are open to helping in any way we can (across AT newtek DOT com.)

[Carl Eugen Hoyos]

What steps have you taken so far?

[NewTek]

Replying to cehoyos:

What steps have you taken so far?

Well, I only learn of this issue about 10 minutes ago, so I am trying to get to the bottom of the concern and how everyone would like to see us resolve it. Certainly if anyone thinks we are trying to steal anything they have misunderstood our intent.

[Kieran Kunhya]

I find it hilarious Andrew that you send legal threats to Open Source developers for independently implementing NDI yet you want to suddenly make use of FFmpeg when it's useful for you. You are a complete hypocrite.

[Carl Eugen Hoyos]

Replying to across:

Thanks a lot for this bug report and I sincerely apologize if we have done anything at all that was not correct, that certainly was not the goal at all.

This is hard to believe but I accept it.

We included ffmpeg pre-compiled in our SDK purely as a convenience for users (we have had hundreds of requests for this) and we took care to avoid misrepresenting anything.

I don't think this is useful as an answer to us informing you that you are violating our copyright.
Sorry for distributing [put your favorite blockbuster here], we had hundreds of requests!

Ultimately we just have a very large number of people who want to use NDI with ffmpeg and do not want the hassle of working out how to compile it.

Our preferred goal would always be to find a way for others to do this

I don't think this is true, would you like to elaborate on what you write here?

and we changed out header files to an MIT license and our run-time libraries are an entirely separate download that has entirely separate functionality.

How is this related?

Regardless, if someone wants to contact us we're more than happy to do whatever the ffmpeg community wants here.

Honestly? No, I prefer to spend time on fixing bugs, not on contacting people who violate my copyright.

Our ultimate goal is to make things easy for everyone and help anyone who wants to use NDI have an easy way to do so. Feel free to each out to me if anyone wants to talk about the best way to handle this and we are open to helping in any way we can (across AT newtek DOT com.)

Did you already stop violating our copyright by distributing non-free binaries based on FFmpeg source code?

[Carl Eugen Hoyos]

Replying to kierank:

I find it hilarious Andrew that you send legal threats to Open Source developers for independently implementing NDI yet you want to suddenly make use of FFmpeg when it's useful for you. You are a complete hypocrite.

Did you inform us about this?

[Kieran Kunhya]

Replying to cehoyos:

Replying to kierank:

I find it hilarious Andrew that you send legal threats to Open Source developers for independently implementing NDI yet you want to suddenly make use of FFmpeg when it's useful for you. You are a complete hypocrite.

Did you inform us about this?

The threat was not to me and was unrelated to FFmpeg.

[Carl Eugen Hoyos]

Replying to cehoyos:

Replying to across:

Thanks a lot for this bug report and I sincerely apologize if we have done anything at all that was not correct, that certainly was not the goal at all.

This is hard to believe but I accept it.

Sorry, I have to take this back:
​https://forums.newtek.com/showthread.php?155773-Windows-amp-Zeranoe-FFmpeg-Builds-with-NewTek-NDI-Built-In
You were informed here by user jules43 that FFmpeg compiled with [libndi] will never be legally redistributable, so above is not believable at all.

[NewTek]

I honestly did not see the post on the forums, the official way to report bugs and problems with the SDK is ​NDI@newtek.com and the forums are largely for the community (although some of our employees tend to post there and from time to time I respond on issues brought to my attention.) I am clearly aware of this issue now and will make sure it is taken care of.

I know that because we are a company that there is going to be an inclination to dis-believe that we just where trying to help here and I do not see a lot to gain in trying getting into an argument about that. We make no money off NDI and we give it away to free (even to our competitors).

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. We will continue to document and support anyone using NDI within FFMPEG as best we possible can and strongly believe and support the FFMPEG project.

[Kieran Kunhya]

Replying to across:

I know that because we are a company that there is going to be an inclination to dis-believe that we just where trying to help here and I do not see a lot to gain in trying getting into an argument about that. We make no money off NDI and we give it away to free (even to our competitors).

So helpful that you sue people who try and independently implement NDI and find security holes in it.

[Gyan]

Replying to across:

I honestly did not see the post on the forums...

There is a reply by you immediately following the post Carl quoted.

[NewTek]

Replying to Gyan:

Replying to across:

I honestly did not see the post on the forums...

There is a reply by you immediately following the post Carl quoted.

This conversation occurred before we ever added a pre-built FFMPEG to our SDK distribution and I believed that I believe that I was pointing out that we made our header files distributable and our library easy to use via dynamic loading, allowing you to build projects without even needing our libraries.

If we incorrectly included pre-built versions (which was what the thread quoted was asking for) then I apologize again and we will remove these immediately. We absolutely respect the work of FFMPEG and it's license.

[jeeb]

I think more than just the "distributing a binary with enable-nonfree configured" part, people are seeing this as an example of where a company takes advantage of open source components such as libx264 or FFmpeg, while not keeping it all kosher. It may not have been your intent, but that's how it comes out when a company producing a blob that is only usable with enable-nonfree decides to publish a binary that contains useful utilities covered by libraries linked into it - which are not supposed to be license-compatible with each other.

To put it more specifically, your SDK is not compatible with GPL, yet clearly someone felt like having fabulous H.264 encoding through libx264 was something that would "sell" (not necessarily regarding money, that is) your solution even better. Otherwise enable-gpl and enable-libx264 would have not been set. Or the clearly manually added x264-related define. And I don't disagree. Having x264 in a binary with your input reading makes it much more feasible for various usage.

Now - unfortunately - your own license and x264 do not match up with this. Your license and GPL are not compatible with each other. You are not an OS library/feature, and you're not something that at least apparently would also be source distributable under the GPL (since GPL is viral, after all).

Of course, now, the fun little thing after you have published a binary like this, is that I think technically anyone who received this binary can request the full code under the GPL - including your NDI library. Of course IANAL, but ┐(´д｀)┌.

[Carl Eugen Hoyos]

Replying to JEEB:

Of course, now, the fun little thing after you have published a binary like this, is that I think technically anyone who received this binary can request the full code under the GPL - including your NDI library. Of course IANAL, but ┐(´д｀)┌.

This is not true in (continental) Europe.

[j-b]

Of course, this is not an "honest mistake", the build is configured with "--enable-libndi_newtek --enable-nonfree", so this is done on purpose. The message explains that clearly.

Also, as mentionned, across here knows about this build since January, not since a few days. So
clearly not an honest mistake either.

[j-b]

Replying to kierank:

I find it hilarious Andrew that you send legal threats to Open Source developers for independently implementing NDI yet you want to suddenly make use of FFmpeg when it's useful for you. You are a complete hypocrite.

I totally corroborate kierank point here. I was witness of that.

You send legal threats and threat about suing open source developers, and then you violate Open Source licenses?

[jeeb]

Replying to cehoyos:

Replying to JEEB:

Of course, now, the fun little thing after you have published a binary like this, is that I think technically anyone who received this binary can request the full code under the GPL - including your NDI library. Of course IANAL, but ┐(´д｀)┌.

This is not true in (continental) Europe.

I would really love it if you were more verbose about this. If the binary package contained the NDI library as well as the FFmpeg binary that was specifically set to be GPL, I would think these two would constitute a set of derivative work.

Also if the build was clearly meant to work with a dynamically loaded library, but was not explicitly linked against it (furthered by the fact that they'd be distributed together), I'd think the generally idea of a "derivative work" would apply in this case as well.

[Carl Eugen Hoyos]

Replying to JEEB:

Replying to cehoyos:

Replying to JEEB:

Of course, now, the fun little thing after you have published a binary like this, is that I think technically anyone who received this binary can request the full code under the GPL - including your NDI library. Of course IANAL, but ┐(´д｀)┌.

This is not true in (continental) Europe.

I would really love it if you were more verbose about this.

I don't think it can be argued that NewTek ever wanted to comply with the GPL when they decided to distribute a binary based on FFmpeg and x264 source code. Therefore no contract ever came into effect between the FFmpeg developers and NewTek and therefore you cannot demand any obligations that result from such a contract.
Der Dieb schuldet nicht.

[j-b]

Replying to cehoyos:

Replying to JEEB:

Replying to cehoyos:

Replying to JEEB:

Of course, now, the fun little thing after you have published a binary like this, is that I think technically anyone who received this binary can request the full code under the GPL - including your NDI library. Of course IANAL, but ┐(´д｀)┌.

This is not true in (continental) Europe.

I would really love it if you were more verbose about this.

I don't think it can be argued that NewTek ever wanted to comply with the GPL when they decided to distribute a binary based on FFmpeg and x264 source code. Therefore no contract ever came into effect between the FFmpeg developers and NewTek and therefore you cannot demand any obligations that result from such a contract.

Copyright does not need to be agreed on to be fully in force.

The GPL is a software license, therefore a contract.

By distributing the software, they agreed to the contract, that they breached.

However, I doubt that this discussion is for this topic.

[Carl Eugen Hoyos]

I received many comments about my suggestion to remove libndi support from FFmpeg. Some people have pointed out that such a quick reaction may not be appropriate and that the FFmpeg developers (and myself) should instead try to find a consensual solution for the copyright infringement, especially since Andrew Cross has reacted so quickly and assured us that he indeed is interested in cooperating with us to solve the issue.
After careful consideration, I suggest we take the same approach as was done with Amazon in ticket #7214: NewTek releases the source code for the needed libndi library under GPL or a less strict and compatible license to comply with the GPL (as is required anyway by US copyright law) and in return, I personally (and hopefully all other FFmpeg developers) will not insist on NewTek stopping the distribution of binaries based on FFmpeg source code after th copyright of the FFmpeg developers was violated by NewTek. I am hopeful that this will also be acceptable for the x264 developers.
@across: Please comment if this is an acceptable path for you, I suggest to discuss this in public, according to common open-source practice and as it was done with Amazon.

[Kieran Kunhya]

@cehoyos

Having sent legal threats to OSS developers for reverse engineering libndi, I really doubt they are going to suddenly release it under GPL.

We need to remove libndi ASAP and ignore Andrew's crocodile tears

[Michael Niedermayer]

ive been asked about my opinion about this issue ...

I think it would be wise from newtek to release libndi under the GPL or a compatible license. The alternative wise thing for newtek would be to hire a lawyer from the FSF.

Also legal threats for reverse engeneering are not wise. I know no details of this case but if the impression I got from what ive read is representative and if i was in charge at newtek i would search for a new employee to replace whoever sent that legal threat. I mean this was not in the interest of newtek at all.

about removing or keeping the code, this is the decision of the community not mine

just my 2 cents as i was asked.

[Carl Eugen Hoyos]

Replying to Zeranoe:

It looks like NewTek is providing a non-free FFmpeg build with their Windows 3.7 NDI SDK:

Please run md5sum on this installer.

[Zeranoe]

Replying to cehoyos:

Replying to Zeranoe:

It looks like NewTek is providing a non-free FFmpeg build with their Windows 3.7 NDI SDK:

Please run md5sum on this installer.

MD5:
fb464e5cf8f97517f0477d3cf801e240 *NewTek NDI 3.7 SDK.exe

SHA1:
5844c790aaaf385ac3f895c5bd134911da0e901a *NewTek NDI 3.7 SDK.exe

[Carl Eugen Hoyos]

It was suggested that my last post here is missing a deadline.
@across: Please explain how you plan to fulfill the obligations of the GPL until December 16th.

[NewTek]

On the day that this was reported to us, we removed ffmpeg from the NDI SDK.

[Cigaes]

That is not enough. You distributed software without complying with the license. Furthermore, since you explicitly set --enable-nonfree, it cannot be considered an honest mistake.

Therefore, according to the clauses of the GPL, you lost all rights to distribute any FFmpeg-based and x264-based code. Furthermore, you lost the goodwill of the community.

cehoyos just gave you an ultimatum: comply retroactively with the terms of the GPL, and you will win back the goodwill. If you do not, then we will acknowledge that you do not want our goodwill and stop providing its effects.

[Kieran Kunhya]

We have had no response so we should remove NDI within 24 hours.

[Kieran Kunhya]

It should be possible to integrate the open source libndi library to resolve the receive part of this issue:

​https://code.videolan.org/jbk/libndi