Bug 1501522

I see it's licensed under a new type of license - FDK-AAC. What's the compatibility of this one? We're shipping unmodified fdk-aac library currently as nonfree in one of the 3rd party repositories, so clarification is necessary.

We consider the license on this package to be Free. We haven't reached out to the FSF for an opinion on compatibility.

Lifting FE-Legal.

> We're shipping unmodified fdk-aac library currently as nonfree in one of the 3rd party repositories, so clarification is necessary.

As far as I can tell, the problematic clause (that the (copyright) license only covers compliant AAC implementations, a use case restriction) appears to have been removed. That explains why Legal now considers the license Free.

There is a "no patent license" statement in the new license, but apparently RH Legal does not see a patent being infringed, and it is their call.

Great news, taking review.

I sent some comments regarding the forked code in a separate e-mail.

* Missing BuildRequires for gcc, gcc-c++, autoconf and automake
* find %{buildroot} -name '*.la' -exec rm -f {} ';' -> find %{buildroot} -name '*.la' -print -delete

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- Sources used to build the package don't match the upstream source, as provided
  in the spec URL.

diff -U2 -r /home/rathann/build/review/1501522-fdk-aac/upstream-unpacked/Source0/fdk-aac-0.1.5/Makefile.am /home/rathann/build/review/1501522-fdk-aac/srpm-unpacked/fdk-aac-0.1.5-stripped.tar.gz-extract/fdk-aac-0.1.5/Makefile.am
--- /home/rathann/build/review/1501522-fdk-aac/upstream-unpacked/Source0/fdk-aac-0.1.5/Makefile.am      2017-10-10 13:22:48.000000000 +0200
+++ /home/rathann/build/review/1501522-fdk-aac/srpm-unpacked/fdk-aac-0.1.5-stripped.tar.gz-extract/fdk-aac-0.1.5/Makefile.am    2017-10-11 10:10:14.000000000 +0200
@@ -134,4 +134,5 @@
     $(top_srcdir)/autogen.sh \
     $(top_srcdir)/MODULE_LICENSE_FRAUNHOFER \
+    $(top_srcdir)/README.fedora \
     $(top_srcdir)/NOTICE \
     $(top_srcdir)/Android.bp \
diff -U2 -r /home/rathann/build/review/1501522-fdk-aac/upstream-unpacked/Source0/fdk-aac-0.1.5/Makefile.in /home/rathann/build/review/1501522-fdk-aac/srpm-unpacked/fdk-aac-0.1.5-stripped.tar.gz-extract/fdk-aac-0.1.5/Makefile.in
--- /home/rathann/build/review/1501522-fdk-aac/upstream-unpacked/Source0/fdk-aac-0.1.5/Makefile.in      2017-10-10 13:22:51.000000000 +0200
+++ /home/rathann/build/review/1501522-fdk-aac/srpm-unpacked/fdk-aac-0.1.5-stripped.tar.gz-extract/fdk-aac-0.1.5/Makefile.in    2017-10-11 10:11:15.000000000 +0200
@@ -546,4 +546,5 @@
     $(top_srcdir)/autogen.sh \
     $(top_srcdir)/MODULE_LICENSE_FRAUNHOFER \
+    $(top_srcdir)/README.fedora \
     $(top_srcdir)/NOTICE \
     $(top_srcdir)/Android.bp \
Only in /home/rathann/build/review/1501522-fdk-aac/srpm-unpacked/fdk-aac-0.1.5-stripped.tar.gz-extract/fdk-aac-0.1.5: README.fedora

Looks like you need to include README.fedora as Source1: and to plug it into the
build system with a patch or use the same upstream commit for both SRPM and
upstream tarball.

- Missing BRs: for gcc-c++ and automake (will pull in autoconf, too).

===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Header files in -devel subpackage, if present.
[x]: ldconfig called in %post and %postun if required.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.
[x]: Development (unversioned) .so files in -devel subpackage, if present.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
[x]: License file installed when any subpackage combination is installed.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 788480 bytes in 4 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[!]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Fully versioned dependency in subpackages if applicable.
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Scriptlets must be sane, if used.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: The placement of pkgconfig(.pc) files are correct.
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on debuginfo package(s).
     Note: There are rpmlint messages (see attachment).
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Package should not use obsolete m4 macros
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: fdk-aac-0.1.5-3.fc26.x86_64.rpm
          fdk-aac-devel-0.1.5-3.fc26.x86_64.rpm
          fdk-aac-debuginfo-0.1.5-3.fc26.x86_64.rpm
          fdk-aac-0.1.5-3.fc26.src.rpm
fdk-aac.x86_64: W: invalid-license FDK-AAC
fdk-aac-devel.x86_64: W: invalid-license FDK-AAC
fdk-aac-devel.x86_64: W: only-non-binary-in-usr-lib
fdk-aac-debuginfo.x86_64: W: invalid-license FDK-AAC
fdk-aac.src: W: invalid-license FDK-AAC
fdk-aac.src: W: file-size-mismatch fdk-aac-0.1.5-stripped.tar.gz = 1673800, https://people.freedesktop.org/~wtay/fdk-aac-0.1.5-stripped.tar.gz = 1673650
4 packages and 0 specfiles checked; 0 errors, 6 warnings.




Rpmlint (debuginfo)
-------------------
Checking: fdk-aac-debuginfo-0.1.5-3.fc26.x86_64.rpm
fdk-aac-debuginfo.x86_64: W: invalid-license FDK-AAC
1 packages and 0 specfiles checked; 0 errors, 1 warnings.





Rpmlint (installed packages)
----------------------------
sh: /usr/bin/python: No such file or directory
fdk-aac-debuginfo.x86_64: W: invalid-license FDK-AAC
fdk-aac-debuginfo.x86_64: W: invalid-url URL: https://cgit.freedesktop.org/~wtay/fdk-aac/log/?h=stripped2 <urlopen error [Errno -2] Name or service not known>
fdk-aac-devel.x86_64: W: invalid-license FDK-AAC
fdk-aac-devel.x86_64: W: invalid-url URL: https://cgit.freedesktop.org/~wtay/fdk-aac/log/?h=stripped2 <urlopen error [Errno -2] Name or service not known>
fdk-aac-devel.x86_64: W: only-non-binary-in-usr-lib
fdk-aac.x86_64: W: invalid-license FDK-AAC
fdk-aac.x86_64: W: invalid-url URL: https://cgit.freedesktop.org/~wtay/fdk-aac/log/?h=stripped2 <urlopen error [Errno -2] Name or service not known>
3 packages and 0 specfiles checked; 0 errors, 7 warnings.



Requires
--------
fdk-aac-debuginfo (rpmlib, GLIBC filtered):

fdk-aac-devel (rpmlib, GLIBC filtered):
    /usr/bin/pkg-config
    fdk-aac(x86-64)
    libfdk-aac.so.1()(64bit)

fdk-aac (rpmlib, GLIBC filtered):
    /sbin/ldconfig
    libc.so.6()(64bit)
    libm.so.6()(64bit)
    rtld(GNU_HASH)



Provides
--------
fdk-aac-debuginfo:
    fdk-aac-debuginfo
    fdk-aac-debuginfo(x86-64)

fdk-aac-devel:
    fdk-aac-devel
    fdk-aac-devel(x86-64)
    pkgconfig(fdk-aac)

fdk-aac:
    fdk-aac
    fdk-aac(x86-64)
    libfdk-aac.so.1()(64bit)



Source checksums
----------------
https://people.freedesktop.org/~wtay/fdk-aac-0.1.5-stripped.tar.gz :
  CHECKSUM(SHA256) this package     : 7cb2c0b5d9ba01bc1eab4b98b420a081defc4b42d6700a2443465e866314f74d
  CHECKSUM(SHA256) upstream package : cc91dc365610ac0a03e4e3ffa3487606fb629f42ed16a018a7d29157bb7779e6
diff -r also reports differences


Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02
Command line :/usr/bin/fedora-review -b 1501522
Buildroot used: fedora-26-x86_64
Active plugins: Generic, Shell-api, C/C++
Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

fedora fdk-aac seems like a shit idea, why strip it?
If you can't ship it complete why bother at all!

Looks like we need an fdk-aac-freeworld.

fdk-aac in official is great! but if the stripped version disable important functionalities then a fdk-aac-freeworld is necessary... exist people not using 3rd party repositories; then for them sound great. in 3rd party repos only handbrake needs fdk-aac...

(In reply to Kevin Kofler from comment #8)
> Looks like we need an fdk-aac-freeworld.

Or just epoch the stripped package.

(In reply to Kevin Kofler from comment #8)
> Looks like we need an fdk-aac-freeworld.

In fact why do we?
I believe the fedora fdk-aac package should be renamed to fdk-aac-stripped and use it's own directories to avoid conflicts.

(In reply to David Vásquez from comment #9)
> fdk-aac in official is great! but if the stripped version disable important
> functionalities then a fdk-aac-freeworld is necessary... exist people not
> using 3rd party repositories; then for them sound great. in 3rd party repos
> only handbrake needs fdk-aac...

With fdk-aac being free, we can enable it in FFmpeg.

(In reply to Dominik 'Rathann' Mierzejewski from comment #12)
> (In reply to David Vásquez from comment #9)
> > fdk-aac in official is great! but if the stripped version disable important
> > functionalities then a fdk-aac-freeworld is necessary... exist people not
> > using 3rd party repositories; then for them sound great. in 3rd party repos
> > only handbrake needs fdk-aac...
> 
> With fdk-aac being free, we can enable it in FFmpeg.

But if the 3rd party repos enable fdk-aac in ffmpeg with the striped version, I have doubts of it; We could get something incomplete. Other problem, ffmpeg is part of packages who requires massive rebuild (yes in "so" bump); but exist the possibilty of constantly changes = contantly rebuilds...

> Or just epoch the stripped package.

I assume you mean the unstripped one? But replacing Fedora packages that way is against RPM Fusion policy, the user must opt in to every *-freeworld package explicitly.

> > Looks like we need an fdk-aac-freeworld.
>
> In fact why do we?
> I believe the fedora fdk-aac package should be renamed to fdk-aac-stripped and > use it's own directories to avoid conflicts.

The advantage of doing a -freeworld (set up like freetype-freeworld or qt5-qtwebengine-freeworld) is that it should be possible (assuming the stripping does not break the ABI) to replace the stripped Fedora version with the complete RPM Fusion version at runtime, without recompiling dependent packages. (freetype-freeworld and qt5-qtwebengine-freeworld don't even include a -devel package, you just build against the Fedora version and make sure you don't have an rpath on %{_libdir}, ld.so does the rest.)

After some reading (wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_AAC) and closer look at the diff between this and original source, I'm afraid important features are missing and hence I'd like to ask the submitter to accommodate the existing package in RPMFusion and name this differently than fdk-aac (for example, fdk-aac-free) or at least do the necessary legwork for RPMFusion package and send a patch to rename to -freeworld and support parallel installation like Kevin said in comment #14. It'd be great if you could become co-maintainer there, too, to coordinate updates.

According to a link:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694257#20
on that wiki page, Debian thinks that the following clause is non-free and GPL-incompatible:
> You may not charge copyright license fees for anyone to use, copy or distribute
> the FDK AAC Codec software or your modifications thereto.

FWIW abipkgdiff claims fdk-aac and fdk-aac-stripped are binary-compatible.

I'm thinking of naming the package fdk-aac-free. There would need to be an update to the fdk-aac in rpmfusion to replace this -free package instead of causing a conflict.

The stripped and unstripped .so files are API and ABI compatible so you would not need to recompile anything to get the complete version.

(In reply to Wim Taymans from comment #18)
> I'm thinking of naming the package fdk-aac-free. There would need to be an
> update to the fdk-aac in rpmfusion to replace this -free package instead of
> causing a conflict.
> 
> The stripped and unstripped .so files are API and ABI compatible so you
> would not need to recompile anything to get the complete version.


fdk-aac-free name, and ABI/API compatible, sounds great.

Do you also reflect the stripping in the GStreamer caps to try to install the rpmfusion version on higher profiles ?

> There would need to be an update to the fdk-aac in rpmfusion to replace this
> -free package instead of causing a conflict.

Whoever is going to take care of it should take a close look at how the freetype-freeworld and qt5-qtwebengine-freeworld packages I maintain are set up and do the same. (And to give credit where credit is due, I did not invent this scheme, I myself copied it from the atlas-sse* packages and the old (pre-glvnd) nvidia driver packaging.)

> Do you also reflect the stripping in the GStreamer caps to try to install the
> rpmfusion version on higher profiles ?

How so? The GStreamer plugin would not change at all between the fdk-aac versions because they are drop-in replacements of each other, just with a different (smaller or larger) feature set compiled in.

Ok, I tested ffmpeg-3.3.4 compiled against this stripped library and I don't think it's a good idea to have this in Fedora at all. Playback of the reference HE-AAC file (https://www2.iis.fraunhofer.de/AAC/SBRtestStereoAot29Sig2.mp4) is wrong with ffplay -acodec libfdk_aac (compared to FFmpeg's built-in aac decoder). In my opinion, until we can include the unmodified code, it makes no sense for Fedora to ship it.

I'm attaching two wave files produced from the above mp4 file with:
ffmpeg -c:a libfdk_aac -i ./SBRtestStereoAot29Sig2.mp4 ./SBRtestStereoAot29Sig2-fdk_aac-stripped.wav

ffmpeg -i ./SBRtestStereoAot29Sig2.mp4 ./SBRtestStereoAot29Sig2-aac.wav

You can hear the difference yourselves (top frequencies are not decoded and simply missing in the first case).

Created attachment 1338930 [details]
Reference HE-AAC file decoded with fdk-aac-stripped

Created attachment 1338931 [details]
Reference HE-AAC file decoded with FFmpeg's aac decoder

So, I am actually rejecting this review request on the grounds that it doesn't work as advertised (applications linking against this library expect it to support HE-AAC fully, including SBR). However, I'm open to hearing arguments to convince me that it's still a good idea to have a broken AAC codec in Fedora. Right now, I'm convinced it would only give Fedora a bad name.

(In reply to Dominik 'Rathann' Mierzejewski from comment #25)
> So, I am actually rejecting this review request on the grounds that it
> doesn't work as advertised (applications linking against this library expect
> it to support HE-AAC fully, including SBR). However, I'm open to hearing
> arguments to convince me that it's still a good idea to have a broken AAC
> codec in Fedora. Right now, I'm convinced it would only give Fedora a bad
> name.

Ok, the test show the differences. It fails.

Maybe we can just give it a different soname and then have the GStreamer plugin register under a different name "fdk-aac-mini" that will only claim to accept the profiles that are really support, that is the non HE profiles. I'm afraid that may also require some work on aacparse to actually recognize those profiles as we don't have full profile recognition in there yet.

The GStreamer plugins have the ability to clearly negotiate the profiles they support, so not supporting all possible profiles is not a good reason to not ship this. If people need the less used profiles they will keep having the ability to download software from various places that support those.

Christian, supporting HE-AAC encoding is the raison d'être of fdk-aac. Otherwise FFmpeg's aac codec is good enough for all other use cases. We already have gstreamer1-libav in RPMFusion covering these, so having a crippled fdk-aac in Fedora is no gain. See https://trac.ffmpeg.org/wiki/Encode/AAC for more information. Unless we're looking at several years until unstripped fdk-aac can be included in Fedora, I think it's not worth the effort to add support for this stripped version to FFmpeg and other multimedia software and we should just wait.

What is in Fedora is what we ship in Fedora repositories or at the very least allowed to include as a 3rd party repository, what might exist in other repositories that we are not even allowed to mention in public announcements is of no consequence here. We can't base our operating system user experience on a policy of 'oh, that doesn't work? Well there might be something out there that can help you *wink* *wink*'

We are looking at years before we can ship a different version and libav/ffmpeg might never be shipable.

So what we could look at though is trying to ship this as something parallel-installable with other versions of this library, don't know how feasible that is.

Out there in the real world, no serious user uses Fedora without the codecs from RPM Fusion. (Well, maybe some do now that at least MP3 can be shipped in Fedora, but still.) It is just a waste of everybody's time to try to ship crippled codecs that only make it harder to install the ones that actually work.

From the GStremer point of view, doing what Christian wants is easy, the steps that need to happen are:

1. Import aacparse to recognize the HE-AAC profiles that the cut down fdk-aac doesn't support. It's a bit of bitstream parsing, but nothing too complex for Wim ;)
2. Change the soname of the cut-down fdk-aac library
3. Fork the GStreamer plugin with a different name, more restricted caps and a lower rank

Then if you have files that it can play, it will just work without rpmfusion. For other caps that the crippled fdk-aac can't handle, the plugin install magic will still work and fetch it from rpmfusion or wherever. Once the rpmfusion plugin is installed, it will just hide the fdk-aac one.  For applications that don'T use GStreamer, well, that's too sad for them!

P.S. I guess you can alwasy keep the same soname and have the GStreamer plugin recognize which one is installed in a way that changes the rank and caps when the rpmfusion one is installed, I'm just not sure how feasible it is to replace a rpm with another like this with current rpm/dnf/packagekit.

I was thinking that we don't fork the GStreamer plugin but let it decide what caps to advertise and support based on the fdk-aac implementation (we could ask it to parse a config descriptor and see if it fails or not, for example). It would need some plugin changes but that's not too complicated.

I guess for the codec installer we then need some way to install the other, more complete, fdk-aac implementation, not sure how we can do that...

After some more thinking I think we need to try to achieve:

1) Be practical about what we can support and allow for tradeoffs between
   desired and allowed functionality.   
2) Keep it simple, don't try to patch too much stuff or be too clever, don't
   requires relinking or different versions of apps etc..
3) have things work somewhat reasonably by default in most cases
4) provide easy way to 'upgrade' to the real-but-non-free version if the user
   explicitly wants this

What I propose is this:

- Have fdk-aac be the default stipped version of the aac codec that we include
  in Fedora. The -devel packages etc will be fdk-aac-devel etc.. Similar to
  freetype
- Have fdk-aac-freeworld in rpmfusion that installs the same .so in
  /usr/lib64/fdk-aac-freeworld/ and adds this path to /etc/ld.so.conf.d/
  This is similar to freetype-freeworld, see comment #14, comment #15
- make rpmfusion packages Require: fdk-aac-freeworld. This would make apps
  installed from rpmfusion also pull in the -freeworld version with complete
  functionality.

Practically:
  gstreamer1-plugins-bad would build against fdk-aac-devel and play a subset of
  aac files with full quality and others with reduced quality. Other apps can
  do the same. Installing the -freeworld package enables full quality in all
  apps.

Updates SPEC and SRPMS with fixes for above review:

https://people.freedesktop.org/~wtay/SPECS/fdk-aac.spec
https://people.freedesktop.org/~wtay/SRPMS/fdk-aac-0.1.5-4.fc26.src.rpm


Some answers:

Comment #11: why not have fdk-aac-stripped?
  - Looking at freetype, and because the library is API and ABI compatible,
    it's better to have fdk-aac as the base name for the -devel and -debug.
    That way all packages can build against the more natural fdk-aac-devel and
    have the -freeworld package enhance it at runtime.
    
Comment #12: yay, we can enable it in ffmpeg
  - build against fdk-aac and require fdk-aac-freeworld to pull in the full
    version when installing ffmpeg from rpmfusion.

Comment #22 ffmpeg fails with fdk-aac!
  - ffmpeg would be installed from rpmfusion and pull in the fdk-aac-freeworld
    package and thus would work correctly because it decodes and encodes with
    full quality.

Comment #7, Comment #31 it doesn't do everything, why bother?
Comment #25, it doesn't work as advertised, convince me..
  - The argument is that we can decode all AAC files, some with reduced
    quality/functionality (not unlike the reduced quality of freetype,
    albeit arguably more noticeable by non-experts). The path to full
    quality is the same as it was before. On a scale from 0 to 10 we go
    from a solid 0 to a positive score >0, which is an infinite increase
    in betterness :).
  - The question of "why doesn't this sound as good as it does on $OTHER_OS"
    is the same as "why do my fonts look so much worse than on $OTHER_OS". It
    can be an educational moment instead of something to avoid.

Comments that fail rule 2:
  Comment #20, Comment #21, Comment #27
  patching GStreamer elements or parsers to somehow force the installation of
  fdk-aac-freeworld.
  - Arguably we could then even put the automatic installation of the library
    inside the stripped fdk-aac library when it detects reduced functionality
    and have things work outside of GStreamer as well. We could add a
    Provides: fdk-aac-full in the rmpfusion version and ask the installer to
    install something that provides fdk-aac-full, or something like that.

(In reply to Wim Taymans from comment #34)
> What I propose is this:
> 
> - Have fdk-aac be the default stipped version of the aac codec that we
> include
>   in Fedora. The -devel packages etc will be fdk-aac-devel etc.. Similar to
>   freetype
> - Have fdk-aac-freeworld in rpmfusion that installs the same .so in
>   /usr/lib64/fdk-aac-freeworld/ and adds this path to /etc/ld.so.conf.d/
>   This is similar to freetype-freeworld, see comment #14, comment #15
> - make rpmfusion packages Require: fdk-aac-freeworld. This would make apps
>   installed from rpmfusion also pull in the -freeworld version with complete
>   functionality.


The fdk-aac-freeworld name isn't acceptable as the package is considered nonfree,
 the name should be fdk-aac-nonfree

https://admin.rpmfusion.org/pkgdb/package/nonfree/fdk-aac/

(In reply to Wim Taymans from comment #34)
...
> The fdk-aac-freeworld name isn't acceptable as the package is considered
> nonfree,
>  the name should be fdk-aac-nonfree

Can someone explain why the hell are you going to accept a non-free software into Fedora in the first step ?

https://trac.ffmpeg.org/wiki/Encode/AAC, quoting:
"FFmpeg supports two AAC-LC encoders (aac and libfdk_aac) and one HE-AAC (v1/2) encoder (libfdk_aac). The license of libfdk_aac is not compatible with GPL, so the GPL does not permit distribution of binaries containing incompatible code when GPL-licensed code is also included. Therefore this encoder have been designated as "non-free", and you cannot download a pre-built ffmpeg that supports it. This can be resolved by compiling ffmpeg yourself. "

In others words, we are talking about having a nonfree software (fdk-aac) to compete with a GPL compatible AAC-LC implementation provided by a FLOSS project (ffmpeg) ? 

If gst (which is LGPL) wants to (<<<legally can) have this plugin because of some weird analysis, that's the gst issue. But I would prevent any GPL compatible code (even within fedora) to link to such fdk-acc because, so far, it is illegal. 

As a consequence, I don't see a need to have your (forked) fdk-aac as a separate package at all in fedora, but I wouldn't care to have it buried into the gst plugin package (built statically or with a custom SONAME).

If Fedora considers the copyright license free, RPM Fusion probably should, too.

Please note, however, that Debian thinks that the license is non-free (see comment #16) and that the FSF should probably be asked. (Last I checked, they were not asked yet according to Spot.) I object to approving this package as long as this is not done.

If the FSF agrees with Debian the license is non-free, then this code is not allowed in Fedora at all, neither as a package nor bundled anywhere else.

If the FSF says the license is free, then we should go with the FSF's judgement.

Fedora Legal aka Red Hat legal has reviewed this license and is fine with it as a free license. What the FSF or some random people at Debian thinks is of very limited interest here.
So can we please stop playing laywer here and leave that to the actual lawyers.

As for the name of the rpmfusion package that will be up to rpmfusion and we should not spend time discussing it here.

What we need to figure out here is how we package this code in Fedora and how we can structure it in a way that allows other parties like rpmfusion to enhance the offering if they are interested. I think Wims proposal addresses that pretty well.

It is a Fedora policy that licenses allowed in Fedora must be free according to the FSF.

https://fedoraproject.org/wiki/Licensing:Main also says:
> This list is based on the licenses approved by the Free Software Foundation , OSI and consultation with Red Hat Legal.
and all the licenses in the list so far:
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses
are approved by the FSF (in 2 cases, under certain conditions that are required to be satisfied for software under those licenses to be allowed in Fedora).

Approving a license considered non-free by the FSF would be a significant policy change that needs approval from the Council and that I am strongly opposed against (and I hope I am not the only one).

See also https://fedoraproject.org/wiki/Licensing:FAQ#Freedom

Oh, and for the technical issues:

(In reply to Wim Taymans from comment #34)
> Comment #11: why not have fdk-aac-stripped?
>   - Looking at freetype, and because the library is API and ABI compatible,
>     it's better to have fdk-aac as the base name for the -devel and -debug.
>     That way all packages can build against the more natural fdk-aac-devel
>     and have the -freeworld package enhance it at runtime.

You can build fdk-aac-{stripped,free,patentfree,whatever} and fdk-aac-devel from the same package, either a fdk-aac.spec with no main package, or by using %package -n, or by using a virtual Provides (Provides: fdk-aac-devel in the %package devel of your fdk-aac-*.spec).

So I still don't think shipping this as just fdk-aac is helpful, both for honesty to users and for upgrade path reasons. The model to follow is gstreamer-plugins-bad-free, not freetype, which is the way it is for historical reasons mostly.

But of course this discussion is absolutely moot if the license turns out not to be acceptable to begin with. Debian's opinion does not per se count, but the FSF needs to be asked.

(In reply to Kevin Kofler from comment #40)
> It is a Fedora policy that licenses allowed in Fedora must be free according
> to the FSF.
> 
> https://fedoraproject.org/wiki/Licensing:Main also says:
> > This list is based on the licenses approved by the Free Software Foundation , OSI and consultation with Red Hat Legal.
> and all the licenses in the list so far:
> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses
> are approved by the FSF (in 2 cases, under certain conditions that are
> required to be satisfied for software under those licenses to be allowed in
> Fedora).
> 
> Approving a license considered non-free by the FSF would be a significant
> policy change that needs approval from the Council and that I am strongly
> opposed against (and I hope I am not the only one).


The policy does not actually state that all licenses has to be approved by the FSF. It just says that when we considering a license for Fedora we look at licenses approved by FSF, OSI and Red Hat legal. So in practice these 3 groups are likely to agree on a license in the vast majority of cases and thus all current licenses as you say are FSF approved, but the policy does not state that FSF approval is a hard requirement.

Even the introduction on:
https://fedoraproject.org/wiki/Fedora_Project_Wiki
says:
> They are developed in Fedora and produced under a free and open source license
> from inception, so other free software communities and projects are free to
> study, adopt, and modify them.

The authority on what constitutes a free software license is the FSF. The authority on what constitutes an open source license is the OSI. If Red Hat Legal is going to approve licenses without asking either of them or even against their advice, the claim that the software in Fedora is "under a free and open source license from inception" is false advertising.

See also https://fedoraproject.org/wiki/Foundations#Freedom .

Anyway, if anyone wants any further legal review or discussion about the finer details of the license here I suggest emailing Tom Callaway and not do it here on this bugzilla. It is the wrong venue and form and anyone who is actually a lawyer with a say here would never post any kind of evaluation or recommendation to this bugzilla. I appologize for letting myself get enganged in such discussion here despite knowing this.

(In reply to Christian Fredrik Kalager Schaller from comment #43) 
> The policy does not actually state that all licenses has to be approved by
> the FSF. It just says that when we considering a license for Fedora we look
> at licenses approved by FSF, OSI and Red Hat legal. So in practice these 3
> groups are likely to agree on a license in the vast majority of cases and
> thus all current licenses as you say are FSF approved, but the policy does
> not state that FSF approval is a hard requirement.

At least since ~2008 the policy was not one that required FSF approval (or more precisely FSF designation as a free software license), if only because that would be impractical. However, there has traditionally been an effort to faithfully apply the FSF's own interpretation of the Free Software Definition. In one case I can vaguely remember, Fedora rejected a license as non-free, in the absence of an opinion from the FSF, but the FSF thereafter concluded that the same license was free. (I think this was the Yahoo! Public! License! version 1.0.) This same policy has led to some cases in which an OSI-approved license was rejected by Fedora as non-free, or a license that the OSI never approved was accepted by Fedora as free. 

I don't think we ever faced a situation in which Fedora accepted a license as free, in the absence of an FSF opinion, and later the FSF concluded that the same license was non-free.

(In reply to Kevin Kofler from comment #16)
> According to a link:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694257#20
> on that wiki page, Debian thinks that the following clause is non-free and
> GPL-incompatible:
> > You may not charge copyright license fees for anyone to use, copy or distribute
> > the FDK AAC Codec software or your modifications thereto.

The GPL also prohibits charging copyright license fees for use, copying and distribution. So I don't think this clause contradicts the DFSG (or the FSD or OSD).

This may not be a *perfect* solution, but it would allow at least some AAC support OOTB.  Having considered the options here, I completely agree with Wim's proposal.  Can we get this back on track?

I think the current situation, where we have only a working AAC codec with a complete decoder and whose freeness is undisputed (the FFmpeg one) in RPM Fusion, is just fine, and actually better than additionally having a crippled AAC codec with a questionable license (which AFAIK has still not been sent to the FSF for comments) in Fedora that will only make users unhappy (and make it harder for them to find the working codec).

Well, even if I reject this, you could always find another reviewer, so let's have FESCo decide: https://pagure.io/fesco/issue/1808 . Packaging-wise, this package is fine and I'll approve it if FESCo says go ahead. In that case, I'd ask Wim to include appropriate and prominent notices in package summary, description and README.Fedora detailing what is not working and why.

I have submitted this license for review to the FSF. I think it is extremely unlikely that their opinion will differ from that of Red Hat Legal, but I have no problem being thorough on this.

(In reply to Dominik 'Rathann' Mierzejewski from comment #51)
> Well, even if I reject this, you could always find another reviewer, so
> let's have FESCo decide: https://pagure.io/fesco/issue/1808 .
> Packaging-wise, this package is fine and I'll approve it if FESCo says go
> ahead.

FESCo approved this today.

Blocking FE-Legal, as it describes more was the current situation is.

Personally I would prefer this package to be free and in fedora, even partially. But it's clearly not the case. Not only, this package is GPL incompatible and I'm not going to re-state the detail on purpose here.

So far, Fesco only approved this build "if" it's free. Fesco did not describe a method to make both ends works as appropriate WRT the packaging side, so the situation is still moot.

The current proposal is in-appropriate. It only describes one end of the task and leave the other part of the work to someone else that yet isn't nominated.

Worst, it will make the package to supersede the current version we package without bringing more value to fedora+rpmfusion users.
Not replacing any "base distro" package is one core value of our project, so we cannot accept a situation where, even if nothing as changed in our side, we would be turned into a situation where we would not follow this non-replacement guideline anymore.

The other issue is "how the packaging would be done", as this package is a fork of the original fdk-aac project. Because of the fork, both projects can live a different way and because we want to have full hands on the way we update the fdk-aac package based on the original project, we don't want to be in a situation where we would wait for a downstream  fork for update in order to have a "coherent situation" WRT complementary packages and ABI, etc.

As a coordinator of a third party project, I retain the rights not to provide, not to replace and not to complement any fdk-aac component that would be introduced in fedora by a packager without any coordination with our project.
With that said, I would like to explicitly leave a room for anyone mandated to "do the complementary job" to use the rpmfusion packagers infra for such purpose. (provided that few restrictions are left on the infra side).


This hold for the general kind of such issue and in a more general manner I would like to think on a written guideline to prevent such "half backed idea" to hit the fedora repos in the future. That, in order to strength the unwritten guideline of not re-using the package namespace if a fedora package is an incomplete version of a package that is already found on our well known repository.


While at it, I still have an alternatives method in mind that would prevent this fdk-aac package to hit our "non-replacement policy".
It would be to have a "side repo" similar to the openh264 case (or even to share the same repo). That way, it would be possible to enable such repository on user request, if our repository isn't enabled.

As the consequence, none would have to deal with bugs introduced by the other party and to deal with the complementary mess.

FE-Legal has already approved this package. Do you have a specific question for them?

There have been no new comments for 10 days and since FESCo (and I assume Wim as well) is fine with dealing with the inevitable support issues, this package is APPROVED.

I also assume Wim will co-maintain the corresponding RPMFusion package or at least coordinate with its maintainer.

One small nit: please put each BuildRequires: in a separate line and sort them alphabetically. You can do that upon importing the package.

A Fedora Community Blog post explaining what does and and what doesn't work with this codec would also be a good idea.

We still don't know the outcome of comment #52 (license review by the FSF).

(In reply to Dominik 'Rathann' Mierzejewski from comment #56)

> I also assume Wim will co-maintain the corresponding RPMFusion package or at
> least coordinate with its maintainer.
> 

I guess that will be Han's now as I'm no longer going to it.

If fdk-aac was approved, then welcome (I will give positive karma here). The world is changing, and we must adapt. The user must choose; then we need give the user the options. If some third-party repository does not want to maintain the original fdk-aac, It is problem of the repository; other will do...  This is how the world works.

(In reply to Kevin Kofler from comment #57)
> We still don't know the outcome of comment #52 (license review by the FSF).

That's irrelevant. RH legal already cleared it.

(In reply to leigh scott from comment #58)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #56)
> 
> > I also assume Wim will co-maintain the corresponding RPMFusion package or at
> > least coordinate with its maintainer.
> 
> I guess that will be Han's now as I'm no longer going to it.

Who's "Han"?

(In reply to David Vásquez from comment #59)
> If fdk-aac was approved, then welcome (I will give positive karma here). The
> world is changing, and we must adapt. The user must choose; then we need
> give the user the options. If some third-party repository does not want to
> maintain the original fdk-aac, It is problem of the repository; other will
> do...  This is how the world works.

The problem is that the third-party repository was previously shipping a different codec, the built-in one from FFmpeg, as the default, with nicer licensing and better FFmpeg integration. Now they'll have to deal with fdk-aac just because Fedora decided to ship a crippled version of it. And they'll have to do an fdk-aac-freeworld override without a real need for it.

And the other problem is that the decoder Fedora is going to ship silently produces wrong sound for some input files! That fits my definition of a broken decoder exactly.

(In reply to Dominik 'Rathann' Mierzejewski from comment #60)
> (In reply to Kevin Kofler from comment #57)
> > We still don't know the outcome of comment #52 (license review by the FSF).
> 
> That's irrelevant. RH legal already cleared it.

So you would be happy to ship something the FSF considers non-free?

(In reply to Kevin Kofler from comment #61)
> (In reply to David Vásquez from comment #59)
> > If fdk-aac was approved, then welcome (I will give positive karma here). The
> > world is changing, and we must adapt. The user must choose; then we need
> > give the user the options. If some third-party repository does not want to
> > maintain the original fdk-aac, It is problem of the repository; other will
> > do...  This is how the world works.
> 
> The problem is that the third-party repository was previously shipping a
> different codec, the built-in one from FFmpeg, as the default, with nicer
> licensing and better FFmpeg integration. Now they'll have to deal with
> fdk-aac just because Fedora decided to ship a crippled version of it. And
> they'll have to do an fdk-aac-freeworld override without a real need for it.
> 
> And the other problem is that the decoder Fedora is going to ship silently
> produces wrong sound for some input files! That fits my definition of a
> broken decoder exactly.
> 
> (In reply to Dominik 'Rathann' Mierzejewski from comment #60)
> > (In reply to Kevin Kofler from comment #57)
> > > We still don't know the outcome of comment #52 (license review by the FSF).
> > 
> > That's irrelevant. RH legal already cleared it.
> 
> So you would be happy to ship something the FSF considers non-free?

Hey! but the third-party repository isn't enable the support for fdk-aac by default in ffmpeg... https://github.com/rpmfusion/ffmpeg/blob/master/ffmpeg.spec#L91 . Then I can't see a real problem here. Other, only the bundled ffmpeg in Handbrake use it...  Maintain a fdk-aac-freeworld isn't  the death.

The problem is that GStreamer will end up using fdk-aac (through some plugin that Fedora is going to ship) instead of FFmpeg (through gstreamer1-libav).

(In reply to Kevin Kofler from comment #63)
> The problem is that GStreamer will end up using fdk-aac (through some plugin
> that Fedora is going to ship) instead of FFmpeg (through gstreamer1-libav).

We should not worry about it; if we recently had many changes in gstreamer "lame" ... twolame ... a52dec; maybe the future is gstreamer1-plugins-bad-free; it can't replace gstreamer1-libav (it only uses ffmpeg); who use gstreamer1-libav? Videos (totem), mpv... generally video players.

(In reply to Kevin Kofler from comment #61)
[...]
> The problem is that the third-party repository was previously shipping a
> different codec, the built-in one from FFmpeg, as the default, with nicer
> licensing and better FFmpeg integration. Now they'll have to deal with
> fdk-aac just because Fedora decided to ship a crippled version of it. And
> they'll have to do an fdk-aac-freeworld override without a real need for it.
> 
> And the other problem is that the decoder Fedora is going to ship silently
> produces wrong sound for some input files! That fits my definition of a
> broken decoder exactly.

I already said that and both Wim and FESCo said they're fine with that. There's no need to repeat things ad nauseam.

> (In reply to Dominik 'Rathann' Mierzejewski from comment #60)
> > (In reply to Kevin Kofler from comment #57)
> > > We still don't know the outcome of comment #52 (license review by the FSF).
> > 
> > That's irrelevant. RH legal already cleared it.
> 
> So you would be happy to ship something the FSF considers non-free?

I wouldn't, but FSF hasn't spoken on this matter yet, as far as I know. Can you provide a link to a public statement by FSF saying otherwise? I don't see the FDK AAC license on https://www.gnu.org/licenses/license-list.html and I trust spot's opinion that it's unlikely they will consider it non-free.

My point is that we should wait for what they actually say instead of assuming things.

Both Legal and FESCo have approved this; can we please move this forward?

(In reply to Yaakov Selkowitz from comment #67)
> Both Legal and FESCo have approved this; can we please move this forward?

The submittor just needs to use fedpkg request-repo (see fedpkg request-repo --help for for details of setup), or fedrepo-req to request the package, then as soon as it's created they can import and build.

> Both Legal and FESCo have approved this; can we please move this forward?

Again, we still do not have the answer from the FSF promised in comment #52.

(In reply to Kevin Kofler from comment #69)
> > Both Legal and FESCo have approved this; can we please move this forward?
> 
> Again, we still do not have the answer from the FSF promised in comment #52.

I'm perfectly aware of that, but that is not required for a Fedora review. 

I guess the question is if Tom would like to keep a legal hold on this until we hear back from the FSF or if we should move forward.

(In reply to Kevin Fenzi from comment #70)
> I'm perfectly aware of that, but that is not required for a Fedora review. 
> 
> I guess the question is if Tom would like to keep a legal hold on this until
> we hear back from the FSF or if we should move forward.

Tom dropped the original FE-Legal hold way back in comment #2.

It was re-added in comment #54, but I see no actual legal questions there: only technical objections.

Just for been clear. The original problem with fdk-aac was never about patent (at least on the 3rd party level). It's all about copyright.

You are not changing anything to the copyright if the patent is expunged from the library. So, the library still has to be considered as non-floss 
The uncertainty about the license condition would still apply.

Now about RPM Fusion. We have a non-replacement policy for fedora packages in our default enabled repositories. So if you still decide to introduce this broken package (both legally and technically), then we will move our fdk-aac to a side repository that will need to be explicitly enabled.

As I haven't see anyone to volunteer to maintain the fdk-aac-nonfree complementary package. It means that you will provide that package by default to users. And I'm afraid that without the complementary package, many users will have a broken experience of he-aac with fedora.

The point is. If the goal was to restore the support relying on the external repository policy. Why just not only to rely on it in the first step and drop the fedora fdk-aac package ?

> It was re-added in comment #54, but I see no actual legal questions there: only > technical objections.

Comment #52 is a legal question. It is definitely not technical.

(In reply to Nicolas Chauvet (kwizart) from comment #72)
> You are not changing anything to the copyright if the patent is expunged
> from the library. So, the library still has to be considered as non-floss 
> The uncertainty about the license condition would still apply.

What uncertainty?  RH Legal has already cleared the license.

> Now about RPM Fusion. We have a non-replacement policy for fedora packages
> in our default enabled repositories. So if you still decide to introduce
> this broken package (both legally and technically), then we will move our
> fdk-aac to a side repository that will need to be explicitly enabled.

No, the intended solution would be to add an ld.so.conf.d-managed fdk-aac-freeworld similar to that of freetype-freeworld and qt5-qtwebengine-freeworld.

> The point is. If the goal was to restore the support relying on the external
> repository policy. Why just not only to rely on it in the first step and
> drop the fedora fdk-aac package ?

The goal is to get as much as we possibly can into Fedora itself.

To be clear, since this is NEEDINFO on me:

* Red Hat considers this license to be a Free Software License. (and I agree)
* Since there was community disagreement on this point, I asked the Free Software Foundation to review the license and determine if it is Free or not in January 2018.
* There has been no update on this (of any substance) since then.
* I have reached out to the FSF a few times to check on status, and was told that they have a bit of a backlog.
* At LibrePlanet 2018, I asked again, and they are checking on it for me.

I do not personally believe there is any license or legal reason to hold on merging this into Fedora, however, if a community member disagrees and wishes to wait on the FSF, they may put the FE-Legal block on the package until that answer comes back.

If the FSF provides clarity, I will add it to this ticket. Obviously, if they find it to be non-free (and this package is added to Fedora), it will be subsequently removed.

let's move on, please request the repo using -> 

$ fedpkg --module-name fdk-aac request-repo 1501522

(In reply to Itamar Reis Peixoto from comment #76)
> let's move on, please request the repo using -> 
> 
> $ fedpkg --module-name fdk-aac request-repo 1501522
Would you volunteer to maintain the fdk-aac-nonfree counterpart in RPM Fusion ?

(In reply to Nicolas Chauvet (kwizart) from comment #77)
> (In reply to Itamar Reis Peixoto from comment #76)
> > let's move on, please request the repo using -> 
> > 
> > $ fedpkg --module-name fdk-aac request-repo 1501522
> Would you volunteer to maintain the fdk-aac-nonfree counterpart in RPM
> Fusion ?
I would even re-phrase to: You are designed volunter to maintain the fdk-aac-nonfree along the current fedora fdk-aac maintainer. Now do the work!

(In reply to Itamar Reis Peixoto from comment #76)
> let's move on, please request the repo using -> 
> 
> $ fedpkg --module-name fdk-aac request-repo 1501522

Please don't. I put back the FE-Legal block waiting for an answer from the FSF.

(In reply to Kevin Kofler from comment #79)
> (In reply to Itamar Reis Peixoto from comment #76)
> > let's move on, please request the repo using -> 
> > 
> > $ fedpkg --module-name fdk-aac request-repo 1501522
> 
> Please don't. I put back the FE-Legal block waiting for an answer from the
> FSF.

They don't have power over this ticket / Bugzilla.

We've got explanation from spot so I think you shouldn't block it again.

(In reply to Nicolas Chauvet (kwizart) from comment #78)
> (In reply to Nicolas Chauvet (kwizart) from comment #77)
> > (In reply to Itamar Reis Peixoto from comment #76)
> > > let's move on, please request the repo using -> 
> > > 
> > > $ fedpkg --module-name fdk-aac request-repo 1501522
> > Would you volunteer to maintain the fdk-aac-nonfree counterpart in RPM
> > Fusion ?
> I would even re-phrase to: You are designed volunter to maintain the
> fdk-aac-nonfree along the current fedora fdk-aac maintainer. Now do the work!

I wouldn't say it like that. We can't force anyone working on anything. Rather the other way around - a current fdk-aac maintained in RF should handle it.

Put it simply it's RF who is the second class citizen here, not the other way around. So it's a RF maintainer's duty to cope with the Fedora changes.

$ fedpkg --module-name fdk-aac request-repo 1501522
Could not execute request_repo: The Bugzilla bug's review was approved over 60 days ago

What now?

> What now?

The reviewer can probably un-set and re-set the review + flag

(In reply to Peter Lemenkov from comment #81)
...
> Put it simply it's RF who is the second class citizen here, not the other
> way around. So it's a RF maintainer's duty to cope with the Fedora changes.
I don't understand the second class citizen concept. I would more say that when a group of people helps, they should be taken with consideration and respect.
Right now it's easy to install the fdk-aac codec fully backend upstream. Just enable the rpmfusion-nonfree repo and use dnf install fdk-aac

What you describe simply does not exist. You are right to say that's I cannot enforce anyone from the community to work on something he doesn't like. But that argument apply to the fdk-aac reviewed plan in the first step. Because the proposal is based on "someone-else to do the complementary work", not him. And that person still do is not nominated yet. (would be welcomed)

Of course bug occurring either side will have to be properly handled.

My position is nothing else but: get someone to work on the complement package (even with an anonymous account). And don't expect anyone else responsibility.

(In reply to Peter Lemenkov from comment #80)
> (In reply to Kevin Kofler from comment #79)
> > (In reply to Itamar Reis Peixoto from comment #76)
> > > let's move on, please request the repo using -> 
> > > 
> > > $ fedpkg --module-name fdk-aac request-repo 1501522
> > 
> > Please don't. I put back the FE-Legal block waiting for an answer from the
> > FSF.
> 
> They don't have power over this ticket / Bugzilla.
> 
> We've got explanation from spot so I think you shouldn't block it again.

Spot wrote in comment #75:

> however, if a community member disagrees and wishes to wait on the FSF, they
> may put the FE-Legal block on the package until that answer comes back.

and that is exactly what I am doing.

What I would like to see is
1. an answer from the FSF, and then, depending on the answer:
2. a. if the FSF considers the license non-free, this review request dropped, OR
2. b. if the FSF considers the license free, an fdk-aac-freeworld (NOT -nonfree at that point) in RPM Fusion, and some plan to not break things for existing RPM Fusion users (i.e., a coordinated import).

We can't block indefinitely on the FSF. Since they can't provide us with a timeline in which we can expect an answer, it's time to proceed.

It's also not appropriate to ask Fedora maintainers to additionally maintain software in third-party repositories.

Please proceed with adding the package.

The thing is, this kind of transitory approval:

(quoting Tom "spot" Callaway from comment #75)
> If the FSF provides clarity, I will add it to this ticket. Obviously, if
> they find it to be non-free (and this package is added to Fedora), it will
> be subsequently removed.

is going to cause a lot of pain for RPM Fusion, who may end up having to move this package back and forth between their free and nonfree sections, and all the work on a -freeworld package can end up being wasted.

I do not see why we need to rush this and cannot wait for a conclusive answer on the licensing status. (If RHEL 8 is the reason, it is NOT appropriate to rush incomplete things into Fedora just to get them automatically merged into RHEL.)

It has nothing to do with RHEL... the goal is to get AAC support into Fedora so that GStreamer can play MP4 videos. The other half of the effort will be enhancing OpenH264 to support MP4.

Spot has already said that it's unlikely this package will fail to receive license approval from the FSF, so I would not worry so much about that....

(In reply to Wim Taymans from comment #82)
> $ fedpkg --module-name fdk-aac request-repo 1501522
> Could not execute request_repo: The Bugzilla bug's review was approved over
> 60 days ago

I reset the flag for you.

(In reply to Kevin Kofler from comment #88)
> The thing is, this kind of transitory approval:
> 
> (quoting Tom "spot" Callaway from comment #75)
> > If the FSF provides clarity, I will add it to this ticket. Obviously, if
> > they find it to be non-free (and this package is added to Fedora), it will
> > be subsequently removed.
> 
> is going to cause a lot of pain for RPM Fusion, who may end up having to
> move this package back and forth between their free and nonfree sections,
> and all the work on a -freeworld package can end up being wasted.
> 
> I do not see why we need to rush this and cannot wait for a conclusive
> answer on the licensing status. (If RHEL 8 is the reason, it is NOT
> appropriate to rush incomplete things into Fedora just to get them
> automatically merged into RHEL.)

The thing is nobody experienced in license review is actually expecting the FSF to declare this non-free. I know Tom doesn't and I know RH legal doesn't. So we are asking the FSF for a review out of an abundance of caution, but it is silly to hold up merging this feature due to an extremely unlikely outcome.

Request for new repo is denied:

https://pagure.io/releng/fedora-scm-requests/issue/6760

Dominik, can you approve this bug?

Done, sorry for the delay.

(In reply to Dominik 'Rathann' Mierzejewski from comment #93)
> Done, sorry for the delay.

Wim, are you going to request the repo again?

(In reply to Yaakov Selkowitz from comment #94)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #93)
> > Done, sorry for the delay.
> 
> Wim, are you going to request the repo again?

Can you re-approve the bug again?

*sigh*

(In reply to Wim Taymans from comment #95)
... 
> Can you re-approve the bug again?
Once again. I would not approve this unless the package is named fdk-aac-free to denote the incompleteness of the library (possibly with a virtual provide fdk-aac).
If that can be done, both fedora fdk-aac-free and rpmfusion fdk-aac-free would use a normal packaging method. (and they would conflicts).

For users, it would only be a matter to replace the former with the latter.

But you need to provide a bug-free fdk-aac implementation. It's not at all acceptable that have unfixable items on the fedora side that would only be fixed by using the fully implemented version.

Please also reminds that rpmfusion has version 1.6 since fc28 and I don't see that would have updated the fedora counterpart in time. This is a problem for us.
To me, it means there is a need for a new legal review for each library update.

(In reply to Nicolas Chauvet (kwizart) from comment #97)
> (In reply to Wim Taymans from comment #95)
> ... 
> > Can you re-approve the bug again?
> Once again. I would not approve this unless the package is named
> fdk-aac-free to denote the incompleteness of the library (possibly with a
> virtual provide fdk-aac).
I see people make a big issue of this on this thread, but do you actually have a real world file that gives you problems? Or are you tilting at windmills here? 

> If that can be done, both fedora fdk-aac-free and rpmfusion fdk-aac-free
> would use a normal packaging method. (and they would conflicts).
> 
> For users, it would only be a matter to replace the former with the latter.
Ok, so you want the package to be called -free at the end, but no changes to the .so file names etc., right?


> But you need to provide a bug-free fdk-aac implementation. It's not at all
> acceptable that have unfixable items on the fedora side that would only be
> fixed by using the fully implemented version.
What do you mean with a 'bug free' implementation? 

 
> Please also reminds that rpmfusion has version 1.6 since fc28 and I don't
> see that would have updated the fedora counterpart in time. This is a
> problem for us.
> To me, it means there is a need for a new legal review for each library
> update.

The only reason the package didn't get updated is due to the quagmire of this bugreport.

I will let the task to sort out what works and does not with this particular implementation on the gstreamer side, as only gstreamer will consume this library within Fedora as I expect.

For the packaging side, I confirm that having a fdk-aac-free package with the current upstream SONAME unmodified in fedora is acceptable. Even having a virtual provides for fdk-aac (but no obsoletes).
That's a compromise to avoid breaking our non-replacement policy (that others third part repositories don't follow). Along with not having existing end-users package replaced by a less featured version.

Please keep in mind that as soon as RPM Fusion is concerned, we may NOT test if the Fedora library is at the same version as the RPM Fusion one, we may update the package according to the Fedora updates policy, so any future ABI changes will have to be taken into account on the Fedora side in the appropriate timing.

New links

https://people.freedesktop.org/~wtay/SPECS/fdk-aac-free.spec
https://people.freedesktop.org/~wtay/SRPMS/fdk-aac-free-0.1.5-4.fc28.src.rpm

Minors comments (not need to re-upload)
- Group can be removed
- post/postun can be replaced with %ldconfig_scriptlets
See https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets

@Rathann, can you re-approve? just in case there is a check for the last changes.

(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/fdk-aac-free

Is there something else that needs to happen for this to become available in Rawhide? 

Package is currently ineligible for scheduling due to following reasons:
* Package is not tracked
* Package dependencies were not resolved yet

(In reply to Wim Taymans from comment #103)
> Is there something else that needs to happen for this to become available in
> Rawhide? 
I don't see anything wrong at least from the koji side:
$ koji list-tagged f30 |grep fdk-aac
fdk-aac-free-0.1.5-5.fc30                 f30                   wtaymans
fdk-aac-free-0.1.6-1.fc30                 f30                   wtaymans

$ koji wait-repo f30-build --build=fdk-aac-free-0.1.6-1.fc30
Successfully waited 0:02 for fdk-aac-free-0.1.6-1.fc30 to appear in the f30-build repo
 
> Package is currently ineligible for scheduling due to following reasons:
> * Package is not tracked
> * Package dependencies were not resolved yet
Where theses messages come from ?

I saw this here:

https://apps.fedoraproject.org/koschei/package/fdk-aac-free

This just means that the package hasn't been added to koschei yet. (which is an optional service.) Everything else looks fine.

Fixed that for you. For future reference: click on the "gear" icon and tick the "Tracked by Koschei" box.

The FSF issued their determination on this license: it is free, but GPL-incompatible.

https://www.gnu.org/licenses/license-list.html#fdk

I see now that Kevin warned us about this in comment #16, and we failed to pay attention. :/

Since it's GPL-incompatible, it would be extremely problematic to have it in a GStreamer plugin, which IMO makes it uninteresting for Fedora Workstation, as the goal of this package was to get AAC working out-of-the-box (which would be impossible to do with e.g. Totem or WebKit without a GStreamer plugin). I'd be very disappointed if we wind up with a "solution" for AAC that doesn't work for GStreamer, so I'll realign my opinion with Kevin and Nicolas and suggest that we just don't do this.

I doubt the problem they have is what Kevin pointed to in Comment #16. As Richard Fontana pointed out in #48 that restriction is true for GPL too. It is probably more a question of the explicit non-patent grant that the FSF objects too. Anyway, I plan on following up on this once back from my current trip.

(In reply to Michael Catanzaro from comment #109)
> I see now that Kevin warned us about this in comment #16, and we failed to
> pay attention. :/
> 
> Since it's GPL-incompatible, it would be extremely problematic to have it in
> a GStreamer plugin, which IMO makes it uninteresting for Fedora Workstation,
> as the goal of this package was to get AAC working out-of-the-box (which
> would be impossible to do with e.g. Totem or WebKit without a GStreamer
> plugin). I'd be very disappointed if we wind up with a "solution" for AAC
> that doesn't work for GStreamer, so I'll realign my opinion with Kevin and
> Nicolas and suggest that we just don't do this.

Totem, Rhythmbox and sound-juicer at least have had exceptions for the "codec
is GPL incompatible" case since 2006.

(With my "Fedora Legal" hat on...)

The Fedora Project is aware that the Free Software Foundation has stated that the Fraunhofer FDK AAC license is GPL incompatible, specifically, because of Clause 3.

We believe that the fdk-aac software codec implementation that we wish to include in Fedora is no longer encumbered by AAC patents. This fact means that Clause 3 in the FDK AAC license is a "no op", or to put it plainly, if no patents are in play, there are no patent licenses to disclaim. For this (and only this) specific implementation of fdk-aac, we believe that the FDK AAC license is GPL compatible.

I see nothing new under the sun, but lets move on.

- Since the clause 3 is a "no op" in the fdk-aac-free fork, Please expunge such statement from the whole fdk-aac-free codesource.
- Please share a spec/src.rpm/build of the fdk-acc-free of the current version (2.0.0 out in 2018-11) with the removed clause 3
- For the info, is this library can be considered as a "system library" as defined by the GPL (1) ? which would allows it to link with any GPL software.


(1) same as OpenSSL, https://fedoraproject.org/wiki/Licensing:FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F

(I will ask advises on several interested upstream parties on the last item).

(In reply to Nicolas Chauvet (kwizart) from comment #113)
> I see nothing new under the sun, but lets move on.
> 
> - Since the clause 3 is a "no op" in the fdk-aac-free fork, Please expunge
> such statement from the whole fdk-aac-free codesource.

Not sure what you mean here, we do not have the right to unilaterally edit the actual text of someone elses license even if we feel that a given clause is not relevant to the current situation.

(In reply to Christian Fredrik Kalager Schaller from comment #115)
> (In reply to Nicolas Chauvet (kwizart) from comment #113)
> > I see nothing new under the sun, but lets move on.
> > 
> > - Since the clause 3 is a "no op" in the fdk-aac-free fork, Please expunge
> > such statement from the whole fdk-aac-free codesource.
> 
> Not sure what you mean here, we do not have the right to unilaterally edit
> the actual text of someone elses license even if we feel that a given clause
> is not relevant to the current situation.

Permission would have to be requested from Fraunhofer to get the clause removed.

Tom, is this something that *could* be done for this fork?

I think this question is a waste of Tom's time.

We have review approval and legal approval for the current license. Let's proceed so we can get AAC support into Fedora!

I don't think its a waste of time the way the question is framed, and I don't want to put words in Tom's mouth here, but my answer would be 'yes of course people should feel free to try to work with Fraunhofer to improve their license text if they so wishes, but to be clear we are not going to block on that'. 

As a sidenote I have actually asked Fraunhofer about removing the clause since its obsolete, but so far no response beyond 'will think about it'. I pinged them again today to try to see if anything has changed, but if I don't hear back on that ping or get a negative response I don't personally plan on pursuing the license rewording any further as it doesn't really matter beyond laymen license clarity, but anyone else who feels inclined should feel free IMHO.

As Christian noted, we have already reached out to Fraunhofer about amending their license in this specific situation, but there has been no progress on this front. Should that situation change, we can certainly apply any changes at a later point.

However, I am in agreement with Christian that it is not necessary to make a license change. It is common for open source licenses to contain clauses which are not triggered, depending on the circumstances. We do not need to block on a license change in order to use the fdk-aac-free codebase in a GPL-compatible manner.

Well, ignoring the technical problems with fdk-aac-free, I don't see anything wrong with getting it in now. Since the ball is rolling to remove an obsolete clause, and it's not triggered by any reasonable circumstance right now, let's do it!

UnitedRPMs is already using fdk-aac-free (updated commit stripped3) in ffmpeg and gstreamer1-plugins-bad-free; and it works fine :)
We continue the discussion for years, or we put our hands to it.

https://github.com/UnitedRPMs/fdk-aac-free
https://github.com/UnitedRPMs/ffmpeg/commit/7fed83b14bc219157bbfbbf7f377c05e10d483b5
https://github.com/UnitedRPMs/gstreamer1-plugins-bad-free/commit/d0e530bc5b0acccbdf0d66000b9c27af80c4477f
https://trac.ffmpeg.org/wiki/Encode/AAC

Results...

origin -  https://0x0.st/z1XN.flac
encoded with fdk-aac-free - https://0x0.st/z1XT.m4a

BTW the source repo is already created nine months ago: https://src.fedoraproject.org/rpms/fdk-aac-free

The package already exists in Fedora and is installable with 'sudo dnf install fdk-aac-free'.

I'm confused:

 * How is it that this bug is still open so long after the package was added to Fedora? Did some process get skipped?
 * Surely it no longer needs to be available in UnitedRPMs.

(In reply to David Vásquez from comment #121)
> UnitedRPMs is already using fdk-aac-free (updated commit stripped3) in
> ffmpeg and gstreamer1-plugins-bad-free; and it works fine :)

Unfortunately I believe the stripped package is very broken, see bug #1711040.

(In reply to Gwyn Ciesla from comment #102)
> (fedscm-admin):  The Pagure repository was created at
> https://src.fedoraproject.org/rpms/fdk-aac-free

The package was created back up here, in September last year.

It looks like we made it through step 11 of https://fedoraproject.org/wiki/New_package_process_for_existing_contributors and then the ball got dropped at step 12: close the Bugzilla ticket.

Closing. (But note that I believe the package is broken as reported in bug #1711040.)

Remaining steps are:

"Step 13: If this package will be built for any version of Fedora that is already released please submit it for inclusion in the 'fedora-updates' repository for those versions of Fedora. See the update submission guide for more details." Inapplicable as the package is already available in Fedora 30.

"Step 14: Add the package to the comps file(s) if appropriate." Wim and Christian should assess if this is required, but it's probably not advisable before the aforementioned bug is fixed.

"Step 15: Consider enabling Upstream Release Monitoring for the package." This is essential to prevent our fork from bitrotting.

> "Step 15: Consider enabling Upstream Release Monitoring for the package." This is essential to prevent our fork from bitrotting.

This is already the case as upstream fdk-aac official upstream is at 2.0.0
Anyway, I'm done with this bug.

Statement:
RPM Fusion is the only 3rd part repository that provides a full featured and working HE-ACC decoder using FLOSS FFmpeg GPLv3+ Software.
If you are a FLOSS lover, you can get it from there. (with comps support).

(In reply to David Vásquez from comment #121)
> UnitedRPMs is already using fdk-aac-free (updated commit stripped3) in
> ffmpeg and gstreamer1-plugins-bad-free; and it works fine :)

Why would a third-party repository shipping FFmpeg (which comes with a built-in fully-featured AAC decoder and even a built-in AAC encoder) want to ship and/or use this crippled and broken AAC codec? This just makes no sense whatsoever.

(In reply to Nicolas Chauvet (kwizart) from comment #124)
> RPM Fusion is the only 3rd part repository that provides a full featured and
> working HE-ACC decoder using FLOSS FFmpeg GPLv3+ Software.

Thank you for that! RPM Fusion is the only repository doing the right thing.

(In reply to Michael Catanzaro from comment #122)
> BTW the source repo is already created nine months ago:
> https://src.fedoraproject.org/rpms/fdk-aac-free
> 
> The package already exists in Fedora and is installable with 'sudo dnf
> install fdk-aac-free'.
> 
> I'm confused:
> 
>  * How is it that this bug is still open so long after the package was added
> to Fedora? Did some process get skipped?
>  * Surely it no longer needs to be available in UnitedRPMs.
> 
> (In reply to David Vásquez from comment #121)
> > UnitedRPMs is already using fdk-aac-free (updated commit stripped3) in
> > ffmpeg and gstreamer1-plugins-bad-free; and it works fine :)
> 
> Unfortunately I believe the stripped package is very broken, see bug
> #1711040.

Sure; UnitedRPMs use commits... Current commits; minor problems (I can't see problem here)... and Wim Taymans is working hard. I put a map; who use fdk-aac in thirdparties repositories? ffmpeg and handbrake isn't compiled with fdk-aac, in Fedora no yet enabled in gstreamer1-plugins-bad-free...  You activate it by yourself. But exist mitigation if people needs the original fdk-aac https://github.com/UnitedRPMs/fdk-aac-freeworld (see date), It needs minors changes in devel package no yet implemented but it has solution.
I am not a expert using fdk-aac but, reading the guide in ffmpeg; it works...

(In reply to Kevin Kofler from comment #125)
> (In reply to David Vásquez from comment #121)
> > UnitedRPMs is already using fdk-aac-free (updated commit stripped3) in
> > ffmpeg and gstreamer1-plugins-bad-free; and it works fine :)
> 
> Why would a third-party repository shipping FFmpeg (which comes with a
> built-in fully-featured AAC decoder and even a built-in AAC encoder) want to
> ship and/or use this crippled and broken AAC codec? This just makes no sense
> whatsoever.
> 
> (In reply to Nicolas Chauvet (kwizart) from comment #124)
> > RPM Fusion is the only 3rd part repository that provides a full featured and
> > working HE-ACC decoder using FLOSS FFmpeg GPLv3+ Software.
> 
> Thank you for that! RPM Fusion is the only repository doing the right thing.

Hi; Because our purpose is provides a complete ffmpeg, with full support. Example similar to libaom and libdav1d; we can find it enabled here..

 [makerpm@localhost ~]$ ffmpeg
ffmpeg version 7fed83b Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9 (GCC)
  configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --docdir=/usr/share/doc/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' --extra-ldflags='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' --enable-bzlib --enable-libdrm --disable-crystalhd --enable-fontconfig --enable-frei0r --enable-gcrypt --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libcdio --enable-indev=jack --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libmp3lame --enable-libkvazaar --enable-nvenc --extra-cflags=-I/usr/include/nvenc --enable-openal --enable-opencl --enable-libopenh264 --enable-libmysofa --enable-libshine --enable-libzvbi --enable-libvidstab --enable-libvmaf --enable-version3 --enable-libaom --enable-opengl --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-avfilter --enable-avresample --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --enable-decoder=libdav1d --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect --enable-libfdk-aac --enable-nonfree

The FFmpeg developers consider it illegal to distribute a build configured with --enable-gpl --enable-nonfree. So you are blatantly ignoring the upstream licenses.

(In reply to Kevin Kofler from comment #128)
> The FFmpeg developers consider it illegal to distribute a build configured
> with --enable-gpl --enable-nonfree. So you are blatantly ignoring the
> upstream licenses.

It was compilated with fdk-aac-free (free fork .so/abi compatible). No offense. Can we stop tantrums?; this is maintained in Fedora; and Fedora Legal approved it. There's no turning back. FFmpeg developers should make the change/exception if you use fdk-aac-free.

mmm I remember similar discussion in RF; Many years ago; I was killed in Rf, funny. Now with the fdk-aac-free; It is a late solution, but functional for users who need it. Would be interesting to see the same discussion 10-12 years later ;)
It's funny to see fanaticism in 2019. Nothing personal. Hugs.

As far as shipping this fork in Fedora goes, I still agree with kwizart and consider it a huge mistake to ship a broken-by-design, non-functional (see bug 1711040) codec in Fedora instead of just letting RPM Fusion take care of shipping a working codec.

But the package being allowed in Fedora does not imply it is legal to link an FFmpeg also linked with GPL libraries with it. This is a question of GPL-compatibility, where there is still a difference of views.

Red Hat legal says this is GPL-compatible. That should be more than good enough for Fedora.

(In reply to Kevin Kofler from comment #130)
> As far as shipping this fork in Fedora goes, I still agree with kwizart and
> consider it a huge mistake to ship a broken-by-design, non-functional (see
> bug 1711040) codec in Fedora instead of just letting RPM Fusion take care of
> shipping a working codec.

Obviously I agree that the bug I reported myself is a big problem. But we want AAC support in Fedora proper without need to enable third-party repos. The goal is to be able to play MP4s out-of-the-box, which will never be possible if AAC support is relegated to RPMFusion. Continuing to complain about this is just wasting everyone's time.

> But we want AAC support in Fedora proper without need to enable third-party repos. The goal is to be able to play MP4s out-of-the-box.

Absolutely agree, it's normal for standard desktop in 2019 and one of the reasons why Linux still sucks on desktop in general.

> mmm I remember similar discussion in RF; Many years ago; I was killed in Rf, funny.
> RPM Fusion is the only repository doing the right thing.

Oh yeah, kwizard & Co are monsters of bureaucracy, any discussion with them isn't productive.

(In reply to Pavlo Rudyi from comment #132)
> > But we want AAC support in Fedora proper without need to enable third-party repos. The goal is to be able to play MP4s out-of-the-box.
> 
> Absolutely agree, it's normal for standard desktop in 2019

While the above is a valid point, 

> and one of the reasons why Linux still sucks on desktop in general.

I wouldn't agree with this. Many people have been using Linux on desktop
for years now.

> > mmm I remember similar discussion in RF; Many years ago; I was killed in Rf, funny.
> > RPM Fusion is the only repository doing the right thing.
> 
> Oh yeah, kwizard & Co are monsters of bureaucracy, any discussion with them
> isn't productive.

And, definitely, this kind of offensive comment doesn't belong to bugzilla. Please
keep your ad hominem attacks to yourself if you don't have anything constructive
to say. Also, making a typo in someone's nickname is just rude.

While you may consider legal issues "bureaucracy", it's vital to get things
right in this regard or you may suffer very real consequences.

Hi, sorry the delay; if you want offensive (In reply to Dominik 'Rathann' Mierzejewski from comment #133)
> (In reply to Pavlo Rudyi from comment #132)
> > > But we want AAC support in Fedora proper without need to enable third-party repos. The goal is to be able to play MP4s out-of-the-box.
> > 
> > Absolutely agree, it's normal for standard desktop in 2019
> 
> While the above is a valid point, 
> 
> > and one of the reasons why Linux still sucks on desktop in general.
> 
> I wouldn't agree with this. Many people have been using Linux on desktop
> for years now.
> 
> > > mmm I remember similar discussion in RF; Many years ago; I was killed in Rf, funny.
> > > RPM Fusion is the only repository doing the right thing.
> > 
> > Oh yeah, kwizard & Co are monsters of bureaucracy, any discussion with them
> > isn't productive.
> 
> And, definitely, this kind of offensive comment doesn't belong to bugzilla.
> Please
> keep your ad hominem attacks to yourself if you don't have anything
> constructive
> to say. Also, making a typo in someone's nickname is just rude.
> 
> While you may consider legal issues "bureaucracy", it's vital to get things
> right in this regard or you may suffer very real consequences.

Hi all, I did not resist. I avoid conflicts but about "get things right..." If you want offensive comments, hate, and immatures only see here and these bugzilla report ( https://bugzilla.rpmfusion.org/show_bug.cgi?id=5298 ); thanks to this entry (Review Request: fdk-aac-free); UnitedRPMs earned frustrate people from Rpmfusion. Please avoid be part. Flame wars isn't constructives. Do not give milk with your finger to the community.