[ffmpeg] package is configured as non-redistributable

[ghost]

--enable-nonfree is required for some components, including libfdk_aac, that are not considered to be compatible with the (L)GPL .

It appears that your ffmpeg package(s) are being distributed with --enable-nonfree and --enable-gpl configure options and are therefore not in compliance with the license.

To fix this do not include --enable-nonfree (and therefore --enable-libfdk-aac) when compiling the distributed packages. This will remove support for the libfdk-aac AAC encoder, but users can use the built-in AAC encoder instead (-c:a aac).

These compile options can remain for users who use spksrc to compile the package for themselves as long as they do not distribute it.

Secondly, Makefile shows LICENSE = LGPL 2.1, but --enable-gpl and -enable-version3 are being used. It should be changed to LICENSE = GPLv3.

[ymartin59]

Thanks for these tips - I am aware something is wrong about I tried to fullfil users' requirements first and I think AAC was not the only support concerned.

[ymartin59]

CC @m4tt075

[m4tt075]

Just did some reading. @lLogan is right and we need to tackle it. I'm AFK, but can look into it Sunday and/or Monday. Let's remove libfdk-aac and see whether that is sufficient. If it is, the fix is really easy. If not, we'll have to go through configuration option by option. Agreed?

[m4tt075]

@ymartin59 @Diaoul
I've looked into this yesterday and today. Thanks to @lLogan's very kind guidance and the truely excellent ffmpeg documentation and implementation, I believe we have a viable way forward.

Relevant sources first:

1. https://www.ffmpeg.org/legal.html
2. https://ffmpeg.org/doxygen/3.4/md_LICENSE.html
3. https://ffmpeg.org/ffmpeg-codecs.html
4. http://www.linuxfromscratch.org/blfs/view/8.3/multimedia/ffmpeg.html

Here my thoughts and findings for your consideration:

1. As outlined by @lLogan already, libfdk-aac is neither compatible with GPL nor with LGPL licenses. If we wish to continue publishing (and thus distributing) ffmpeg packages, it needs to go. There is no other option. However, as Lou outlined as well, the built-in AAC encoder can be used instead, so I don't see any real downside for users with this.
2. You were right, @ymartin59. Removing --enable-libfdk-aac --enable-nonfree alone is not sufficient, but exposes a second issue: The --enable-gpl option conflicts with --enable-openssl (licenses not compatible). Removing --enable-gpl is most likely not an option, as we require it to combine ffmpeg with x264 and x265 and to enable other options (c.f. sources 2 and 3). However, we can keep the GPL license, i.e. --enable-gpl, and work around the issue by replacing --enable-openssl by --enable-gnutls, which is licensed under LGPL instead (c.f. the alternative options in source 4). We have the gnutls cross package already, so this should not be a big deal from an implementation perspective either.
3. If we then change the LICENSE information to GPLv3, as @lLogan suggested, we should indeed be OK moving forward.

I've have just successfully compiled a bromolow-6.1 package this way. My working branch can be found here: https://github.com/m4tt075/spksrc/commits/ffmpeg-free. So far, so good. However:

4. This does not address the packages we currently distribute via https://synocommunity.com/package/ffmpeg#. All of them contain libfdk-aac already. To be honest, I think we should remove them ASAP. [Edit: Packages have been removed already in the meantime.]
5. I'd then suggest republishing fixed packages for 5.2+ toolchains, incrementing the revision, so that the fix is pushed out.

Do you agree with this proposal? And if so, could you please unpublish ffmpeg until we are done fixing and testing? [Edit: Already done]

@lLogan : Please do let us know if you should have any further comments or advice on an appropriate way forward.

[cytec]

@m4tt075 @ymartin59 i've disabled all previous builds for now! while that doesn't affect already installed packages it'll at least prevent users from installing it from now on till we publish a fixed version!

[m4tt075]

Yes. Thank You, @cytec. Btw, great to see you still being actively involved! 👍

[cytec]

giving my best with my sadly very limited time lately :)

[ghost]

@lLogan : Please do let us know if you should have any further comments or advice on an appropriate way forward.

Not sure how I missed the non-free openssl...I thought I searched for that. For future reference you can refer to EXTERNAL_LIBRARY_NONFREE_LIST in the FFmpeg configure for a list of components that are considered to be non-free. Currently, this includes: decklink, libndi_newtek, libfdk_aac, openssl, and libtls. This will be apt to change anytime due to the level of development activity in FFmpeg.

This only caught my attention due to Synology's poor record for complying with the (L)GPL. They were (are?) distributing non-free ffmpeg packages; some with modified source code that was not being made available despite repeated requests. Multiple queries, including some by me, to Synology to address this were ignored.

It's been some time, but wanted to check the current status after a user recently requested help with one of these builds. I don't own any Synology products so I was unable to find out more about the current situation with the limited time I spent (assistance will be appreciated), but only found recent details on SynoCommunity provided packages.

Thank you for being so responsive.

[ymartin59]

Even if I do not agree with immediate ffmpeg unpublishment, it is not only concerned... as embedded in chromaprint and tvheadend (and maybe others, I have not done a full review)
My opinion is we should invest efforts on compiling ffmpeg v4 and fixing licensing troubles at the same time... and reject requests about recent dts support

[m4tt075]

@lLogan Got it and appreciated. Just to be clear, the "SynoCommunity" is not related to or affiliated with the company "Synology" whatsoever. We are free-time open source developers, who've taken interest in cross-compiling all kind of packages for Synology NAS systems, mostly because we wanted to run software on our NASes, that was not available when we looked for it. As such, we obviously cannot and will not take accountability for any shortfalls of Synology. Of course we can fix whatever we distribute via the SynoCommunity platform. In real life, I work in an industry that very heavily relies on the acknowledgement of IP protections by third parties, so I'll always strive for doing the same.

@ymartin59 Yes, the ffmpeg cross package is embedded in chromaprint, comskip, rtmpdump and tvheadend. I don't see synergies between working on fixing the licensing issue and upgrading ffmpeg, as the path to fixing the licensing issue won't change with the ffmpeg version. I agree that pushing out the licensing fix together with an ffmpeg upgrade would be phantastic though, as it provided a nice incentive for people to upgrade.

I've been working on the licensing aspects today and believe that I can PR a fix soon, hopefully by tomorrow. I know that you have been looking into the upgrade question before. If you've made progress already, please just let me know the branch you are working on and how I might assist you.

[ymartin59]

In fact I have only tried to include libva for optimization on intel platforms but got stuck. I have not even started ffmpeg upgrade to v4 itself. So you are free to investigate if interested to do so in a separate branch-PR created from that one (I propose to work together on that branch - so create draft PR as soon as work is started), so that we may merge only licensing fix if we are not satisfied in ffmpeg v4 progress.

[ghost]

@lLogan Just to be clear, the "SynoCommunity" is not related to or affiliated with the company "Synology" whatsoever.

That's what I figured. I just wanted to mention what brought this up in the first place.

As for FFmpeg 4 are you planning on upgrading to the FFmpeg 4.1 release branch? It supports mbed TLS (but I am not familiar with it) if gnutls isn't suitable for whatever reason. FFmpeg 4.0 does not include this. Please let me know when you have a draft Makefile available for FFmpeg 4.x. I have a few minor comments regarding the configure options that are unrelated to this particular issue.

[m4tt075]

@lLogan Yes, 4.1 for now. Will reach out to you when we are closing in. Your support is much appreciated! Many thanks!

[ymartin59]

Published.

[AythamiEsp]

DSM doesn't load ffmpeg package in package center