ffmpeg built with fdk-aac make it non-redistributable

[kwizart]

According to ffmpeg upstream, using fdk-aac-devel requires the nonfree switch that you have enabled. It means that using both --nonfree and --gpl is incompatible and willl not allow the resulting binary to be redistributed to a 3rd party.

This is the very much reason why the RPM Fusion do not have the fdk-aac enabled. (it is not a miss).

I would like to understand your position on this topic ? Can you explain what you think of this ?

Thx

[scaronni]

Hello, I know that is not redistributable and it's not a miss in RPMFusion. Also HandBrake has disabled it in its official builds, and FFmpeg has suggested using aacenc as its replacement.

Sorry for the long explanation that follows, but the answer is a bit broader :)

It's not the only non-free bit actually. There's ton of stuff that is non redistributable if various degrees of link/bundling/packaging happens or just because the license forbids it. Out of memory: OpenH264, the 3GPP headers here and there (libaacplus, gpac), the Plex Media Player (probably, as it contains a bundle of proprietary and non proprietary software), Skype 4 (not using it anymore), rar, Spotify, cdrtools, Flash plugin, libdvdcss, Display Link stuff... basically most of the stuff that's here. I guess also all the things that are linked to the Nvidia libraries make binaries non redistributable (Blender, MPV, Plex Media Player, ffmpeg, Gstreamer plugins); but I'm not sure. If FFmpeg was redistributable I guess Nvidia would ship at least a statically built binary of their own.

I got tired of getting one bit at a time from a thousand places, rebuild packages locally for additional enablements and for newer versions so in the end I decided to put everything that I need in a big cauldron and just ignore all this stuff and all the packages are maybe built with changes that I need. If I can, I just rebuild stuff across all releases to make things easier. If I miss anything, I just add it to the same repository so I can have a one stop shop for my needs.

What's in the "multimedia" repository now overwrites base packages, ignores licenses, and gets constant rebases of things to get the stuff that I need working (for example I need ffmpeg3 compiled with CUDA support on RHEL, CUDA enabled Blender packages for Fedora and HandBrake with working UTF-8 subtitles in RHEL). This is all against the policy of any repository out there, so I did not push anything anywhere. I was actually also thinking of using the same set of Gstreamer1 packages across all distributions, pretty much as this guy is doing here: http://awel.domblogger.net/

If any of the company or committees (3gpp?) ask me to remove stuff I would probably just remove the repository from online visibility, as I would probably have no other choice. But for the moment I'm just parking all the stuff in there. Lots of people have done it in the past 20 years everywhere, so I don't see much of a difference. There's tons of repositories out here that combine non redistributable stuff.

If you think that this might be a threat to RPMFusion, fear not, as this is not going to change. It's not open for external contributions (just pull requests) as I don't have time nor resources to add an infrastructure to it and I have absolutely no plan to add stuff that I don't use personally and I have no plan on just providing packges that do not overwrite base packages. So this is not the place for everyone.

At work we use Mesos (http://mesos.apache.org/) with GPU support, so I took ownership of the orphaned Mesos in Fedora, hoping to at least bring it up to the latest release and see if I could build it with conditionals or package addons. No way, it requires Nvidia headers at the time of building (which they ship with their tarball) and uses its own Java libraries and what not, so again it will probably land here packaged in a non-redistributable format.

At a minimum I'm trying to at least push conditionals where I can in the various Fedora packages (FreeRDP, Blender, etc), but that's not really possible everywhere, as for most non-free things people package stuff as they want and I can't add proper Build Requirements. Other examples, like HandBrake: I started everything by packaging it years and years ago (at least 5) and at the beginning there was no way to unbundle libraries, so it was not suitable for RPMFusion inclusion. With time it got better, and when it was almost free of bundled libraries, I got stuck with the libav/UTF-8 thing and was planning to post it for review keeping the bundled library as it is now allowed, but then Dominik picked it up for RPMFusion and dropped the bundle. I'm curious to see if we will get bug reports for this once Fedora 26 is released.

Now with the new work and the kid my free time is almost gone, but I still have the plan to put some stuff for review in RPMFusion if no one beats me at it, like MakeMKV, kvazaar, etc. But still, I will keep the repository here because of all the other forbidden/unredistributable/broken stuff.

Cheers!

[scaronni]

I will add the same explanation on the blog/repository page.

[kuboosoft]

Hi, I remember the same history some years ago with it.... my frustration made a "ffmpeg-full" rpm with specific purposes and a popular project... the license fdk-aac is a shit as others. Nicolas doesn't love fdk-aac in ffmpeg since much years ago... Do not be surprised about it, same history with vo-aacenc... some Deprecated/removed recently..

[kwizart]

This is not a personal decision alone to "like" fdk-aac or not. But one need to understand that the problem with this package is not at all about patent. Which might be allowed or not dependending on what country. It's about copyright violation of FFmpeg developers license. This is illegal in every country on earth.

With publicly redistributing GPL ffmpeg built with nonfree code, you are making a counterfeit. In France, this offense is punished by up to 3 years of jail and 300 000€ of penalty. One do not have the right to redistribute such item. You simply are making an out of law choice. And if you are a FLOSS Contributor, you should really care about licenses respect, this is no other way around.

This would have been an issue with no solution few years ago, but the that the problem still arise nowadays is astonishing. FFmpeg has grown an internal AAC encoder that is nearly as good a fdk-aac. So I really do not get the point to enable fdk-aac still given the legal constraint.

The workaround we would have picked was to use lpf. It's not perfect but it can be improved.

So I'm not going to discuss this issue further here. Personally I don't care. Do whatever you want. But don't make false claim, you are exposing your users to illegal things for no benefit.

The others points you have raised are serious. The time is missing to everyone. But you are not making a right use of your time but also other contributor if you are "duplicating the work".

The RPM Fusion project welcome anyone who is willing to help making a good Fedora complementary repository.

[kuboosoft]

So I'm not going to discuss this issue further here.

Ironic... For your question; It was obvious that you will receive answers like this. I remember being devoured in rpmfusion for the suggestion about fdk-aac in ffmpeg... It does not matter, time passes. And new things appear or overwrite. A simple example, winff converts without problem and doesn't need fdk-aac. Drink a cup of linden, it's very good. :)

[scaronni]

I just saw that this is getting built for RPMFusion along with libdvdcss etc. Honestly I think is a good thing:

http://koji.rpmfusion.org/koji/packageinfo?packageID=477