Bug 1501522 - Review Request: fdk-aac - Third-Party Modified Version of the Fraunhofer FDK AAC Codec Library for Android
Review Request: fdk-aac - Third-Party Modified Version of the Fraunhofer FDK ...
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dominik 'Rathann' Mierzejewski
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-Legal
  Show dependency treegraph
 
Reported: 2017-10-12 13:59 EDT by Wim Taymans
Modified: 2018-06-26 20:15 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dominik: fedora‑review+


Attachments (Terms of Use)
Reference HE-AAC file decoded with fdk-aac-stripped (1.41 MB, audio/x-wav)
2017-10-15 13:34 EDT, Dominik 'Rathann' Mierzejewski
no flags Details
Reference HE-AAC file decoded with FFmpeg's aac decoder (5.66 MB, audio/x-wav)
2017-10-15 13:34 EDT, Dominik 'Rathann' Mierzejewski
no flags Details

  None (edit)
Description Wim Taymans 2017-10-12 13:59:46 EDT
This is a request to add the following modified version of fdk-aac to Fedora:


https://people.freedesktop.org/~wtay/SPECS/fdk-aac.spec
https://people.freedesktop.org/~wtay/SRPMS/fdk-aac-0.1.5-3.fc26.src.rpm
Comment 1 Peter Lemenkov 2017-10-12 14:53:06 EDT
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.
Comment 2 Tom "spot" Callaway 2017-10-12 15:02:05 EDT
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.
Comment 3 Kevin Kofler 2017-10-12 16:41:50 EDT
> 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.
Comment 4 Dominik 'Rathann' Mierzejewski 2017-10-12 16:54:31 EDT
Great news, taking review.

I sent some comments regarding the forked code in a separate e-mail.
Comment 5 Igor Gnatenko 2017-10-12 17:57:34 EDT
* Missing BuildRequires for gcc, gcc-c++, autoconf and automake
* find %{buildroot} -name '*.la' -exec rm -f {} ';' -> find %{buildroot} -name '*.la' -print -delete
Comment 6 Dominik 'Rathann' Mierzejewski 2017-10-12 18:14:05 EDT
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
Comment 7 leigh scott 2017-10-12 18:57:59 EDT
fedora fdk-aac seems like a shit idea, why strip it?
If you can't ship it complete why bother at all!
Comment 8 Kevin Kofler 2017-10-12 19:46:12 EDT
Looks like we need an fdk-aac-freeworld.
Comment 9 David Vásquez 2017-10-13 02:13:20 EDT
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...
Comment 10 leigh scott 2017-10-13 02:22:52 EDT
(In reply to Kevin Kofler from comment #8)
> Looks like we need an fdk-aac-freeworld.

Or just epoch the stripped package.
Comment 11 leigh scott 2017-10-13 02:27:29 EDT
(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.
Comment 12 Dominik 'Rathann' Mierzejewski 2017-10-13 03:27:37 EDT
(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.
Comment 13 David Vásquez 2017-10-13 03:53:00 EDT
(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...
Comment 14 Kevin Kofler 2017-10-13 04:28:45 EDT
> 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.)
Comment 15 Dominik 'Rathann' Mierzejewski 2017-10-13 05:17:51 EDT
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.
Comment 16 Kevin Kofler 2017-10-13 05:24:07 EDT
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.
Comment 17 Dominik 'Rathann' Mierzejewski 2017-10-13 07:18:54 EDT
FWIW abipkgdiff claims fdk-aac and fdk-aac-stripped are binary-compatible.
Comment 18 Wim Taymans 2017-10-13 09:54:26 EDT
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.
Comment 19 David Vásquez 2017-10-13 15:44:16 EDT
(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.
Comment 20 Olivier Crête 2017-10-13 17:42:16 EDT
Do you also reflect the stripping in the GStreamer caps to try to install the rpmfusion version on higher profiles ?
Comment 21 Kevin Kofler 2017-10-13 20:10:28 EDT
> 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.
Comment 22 Dominik 'Rathann' Mierzejewski 2017-10-15 13:32:33 EDT
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).
Comment 23 Dominik 'Rathann' Mierzejewski 2017-10-15 13:34 EDT
Created attachment 1338930 [details]
Reference HE-AAC file decoded with fdk-aac-stripped
Comment 24 Dominik 'Rathann' Mierzejewski 2017-10-15 13:34 EDT
Created attachment 1338931 [details]
Reference HE-AAC file decoded with FFmpeg's aac decoder
Comment 25 Dominik 'Rathann' Mierzejewski 2017-10-15 13:54:10 EDT
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.
Comment 26 David Vásquez 2017-10-16 05:12:00 EDT
(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.
Comment 27 Olivier Crête 2017-10-16 10:24:41 EDT
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.
Comment 28 Christian Fredrik Kalager Schaller 2017-10-16 12:17:22 EDT
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.
Comment 29 Dominik 'Rathann' Mierzejewski 2017-10-17 05:01:20 EDT
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.
Comment 30 Christian Fredrik Kalager Schaller 2017-10-17 11:46:43 EDT
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.
Comment 31 Kevin Kofler 2017-10-17 12:49:59 EDT
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.
Comment 32 Olivier Crête 2017-10-17 13:21:47 EDT
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.
Comment 33 Wim Taymans 2017-10-18 09:31:20 EDT
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...
Comment 34 Wim Taymans 2017-11-02 07:31:16 EDT
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.
Comment 35 leigh scott 2017-11-02 07:42:25 EDT
(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/
Comment 36 Nicolas Chauvet (kwizart) 2017-11-02 10:33:53 EDT
(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).
Comment 37 Kevin Kofler 2017-11-02 10:34:53 EDT
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.
Comment 38 Kevin Kofler 2017-11-02 10:36:47 EDT
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.
Comment 39 Christian Fredrik Kalager Schaller 2017-11-02 11:30:02 EDT
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.
Comment 40 Kevin Kofler 2017-11-02 12:22:45 EDT
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).
Comment 41 Kevin Kofler 2017-11-02 12:24:51 EDT
See also https://fedoraproject.org/wiki/Licensing:FAQ#Freedom
Comment 42 Kevin Kofler 2017-11-02 12:38:44 EDT
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.
Comment 43 Christian Fredrik Kalager Schaller 2017-11-02 12:46:23 EDT
(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.
Comment 44 Kevin Kofler 2017-11-02 13:10:59 EDT
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.
Comment 45 Kevin Kofler 2017-11-02 13:11:39 EDT
See also https://fedoraproject.org/wiki/Foundations#Freedom .
Comment 46 Christian Fredrik Kalager Schaller 2017-11-02 13:14:34 EDT
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.
Comment 47 Richard Fontana 2017-11-07 13:42:51 EST
(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.
Comment 48 Richard Fontana 2017-11-07 13:49:31 EST
(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).
Comment 49 Yaakov Selkowitz 2017-12-19 00:27:01 EST
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?
Comment 50 Kevin Kofler 2017-12-19 05:17:28 EST
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).
Comment 51 Dominik 'Rathann' Mierzejewski 2017-12-19 08:28:36 EST
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.
Comment 52 Tom "spot" Callaway 2018-01-04 12:59:29 EST
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.
Comment 53 Yaakov Selkowitz 2018-01-12 14:29:34 EST
(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.
Comment 54 Nicolas Chauvet (kwizart) 2018-01-12 16:37:26 EST
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.
Comment 55 Michael Catanzaro 2018-01-12 17:36:59 EST
FE-Legal has already approved this package. Do you have a specific question for them?
Comment 56 Dominik 'Rathann' Mierzejewski 2018-01-23 10:59:15 EST
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.
Comment 57 Kevin Kofler 2018-01-23 12:13:26 EST
We still don't know the outcome of comment #52 (license review by the FSF).
Comment 58 leigh scott 2018-01-23 13:15:05 EST
(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.
Comment 59 David Vásquez 2018-01-23 14:56:33 EST
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.
Comment 60 Dominik 'Rathann' Mierzejewski 2018-01-23 17:40:44 EST
(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"?
Comment 61 Kevin Kofler 2018-01-23 21:23:30 EST
(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?
Comment 62 David Vásquez 2018-01-23 21:45:33 EST
(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.
Comment 63 Kevin Kofler 2018-01-23 22:25:49 EST
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).
Comment 64 David Vásquez 2018-01-23 23:48:41 EST
(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.
Comment 65 Dominik 'Rathann' Mierzejewski 2018-01-24 06:14:48 EST
(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.
Comment 66 Kevin Kofler 2018-01-24 06:23:45 EST
My point is that we should wait for what they actually say instead of assuming things.
Comment 67 Yaakov Selkowitz 2018-02-27 20:29:41 EST
Both Legal and FESCo have approved this; can we please move this forward?
Comment 68 Kevin Fenzi 2018-02-28 13:34:35 EST
(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.
Comment 69 Kevin Kofler 2018-02-28 16:13:44 EST
> 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.
Comment 70 Kevin Fenzi 2018-03-01 16:46:36 EST
(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.
Comment 71 Michael Catanzaro 2018-03-01 19:43:03 EST
(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.
Comment 72 Nicolas Chauvet (kwizart) 2018-03-02 03:38:04 EST
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 ?
Comment 73 Kevin Kofler 2018-03-02 06:31:12 EST
> 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.
Comment 74 Yaakov Selkowitz 2018-03-19 16:43:57 EDT
(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.
Comment 75 Tom "spot" Callaway 2018-04-02 12:30:05 EDT
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.
Comment 76 Itamar Reis Peixoto 2018-04-02 17:48:06 EDT
let's move on, please request the repo using -> 

$ fedpkg --module-name fdk-aac request-repo 1501522
Comment 77 Nicolas Chauvet (kwizart) 2018-04-03 01:49:20 EDT
(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 ?
Comment 78 Nicolas Chauvet (kwizart) 2018-04-03 01:51:03 EDT
(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!
Comment 79 Kevin Kofler 2018-04-03 06:06:03 EDT
(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.
Comment 80 Peter Lemenkov 2018-04-03 06:27:22 EDT
(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.
Comment 81 Peter Lemenkov 2018-04-03 06:29:42 EDT
(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.
Comment 82 Wim Taymans 2018-04-03 09:05:54 EDT
$ 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?
Comment 83 Peter Robinson 2018-04-03 09:11:54 EDT
> What now?

The reviewer can probably un-set and re-set the review + flag
Comment 84 Nicolas Chauvet (kwizart) 2018-04-03 09:34:04 EDT
(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.
Comment 85 Kevin Kofler 2018-04-03 11:34:05 EDT
(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.
Comment 86 Kevin Kofler 2018-04-03 11:41:07 EDT
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).
Comment 87 Michael Catanzaro 2018-04-03 13:55:27 EDT
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.
Comment 88 Kevin Kofler 2018-04-03 14:06:33 EDT
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.)
Comment 89 Michael Catanzaro 2018-04-03 14:29:54 EDT
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....
Comment 90 Yaakov Selkowitz 2018-04-04 15:55:35 EDT
(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.
Comment 91 Christian Fredrik Kalager Schaller 2018-04-30 15:01:44 EDT
(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.
Comment 92 Wim Taymans 2018-05-26 13:48:37 EDT
Request for new repo is denied:

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

Dominik, can you approve this bug?
Comment 93 Dominik 'Rathann' Mierzejewski 2018-05-29 07:34:22 EDT
Done, sorry for the delay.
Comment 94 Yaakov Selkowitz 2018-06-13 22:58:53 EDT
(In reply to Dominik 'Rathann' Mierzejewski from comment #93)
> Done, sorry for the delay.

Wim, are you going to request the repo again?

Note You need to log in before you can comment on or make changes to this bug.