IANAL as well, but I'm not sure about the legal status of aptX HD. Blocking FE-Legal (bug182235) would be a good idea.

As for the spec file -- have you considered making commandline tools a separate package? Although the only benefit I'm aware of that multilib packages could be installed in parallel (e.g. i686 + x86_64).
Looks good otherwise.

Good idea, I'll block the legal review bug.
Aleksei, good point, I'll package the 2 binaries in a separate subpackage called "openaptx". This is according to the guidelines, too.

I separated the CLI utilities into a subpackage.

Spec URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx.spec
SRPM URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx-0.2.0-2.fc33.src.rpm

Ack on the legal review. I'll get the patent status verified and then update this bug.

> %package        utils
> Summary:        %{name} encoder and decoder utilities
> Requires:       %{name}%{?_isa} = %{version}-%{release}

This is a weird pattern. Usually the main package includes the utilities and a -libs subpackage includes the libraries. This can be observed even in the RPM package: https://src.fedoraproject.org/rpms/rpm/blob/master/f/rpm.spec

Can you please restructure this accordingly?

(In reply to Neal Gompa from comment #5)
> This is a weird pattern. Usually the main package includes the utilities and
> a -libs subpackage includes the libraries. This can be observed even in the
> RPM package: https://src.fedoraproject.org/rpms/rpm/blob/master/f/rpm.spec

Seems common for codecs and other library packages:
opus (library), opus-tools (encoder/decoder)
libavif (library), libavif-tools (encoder/decoder)
libpng, libpng-tools
libwebp, libwebp-tools
...

The main content here is a library and binaries are just an additional content that is unlikely to be installed by a regular user.

Hmm, that's true since this package is actually named by the library name. Though `-utils` is weird compared to `-tools`.

Thanks for the suggestion. Renamed from -utils to -tools.

Spec URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx.spec
SRPM URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx-0.2.0-3.fc33.src.rpm

According to wikipedia, this is the patent
https://patents.google.com/patent/EP0398973B1/en,
long expired.

But please wait for ack from Legal before building this in Fedora.

fedora-review says:
- Package does not contain duplicates in %files.
  Note: warning: File listed twice: /usr/lib64/libopenaptx.so
Please fix.

+ package name is OK
+ license is acceptable for Fedora (LGPLv2.1+)
+ license is specified correctly (LGPGv2+)
+ builds and installs OK
+ Provides/Requires/BuildRequires look OK
+ distro build flags are used
+ looks OK in general

Rpmlint
-------
Checking: libopenaptx-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-devel-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-tools-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-debuginfo-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-debugsource-0.2.0-3.fc34.x86_64.rpm
          libopenaptx-0.2.0-3.fc34.src.rpm
libopenaptx.x86_64: W: spelling-error Summary(en_US) aptX -> apt X, apt, apex
libopenaptx.x86_64: W: spelling-error %description -l en_US aptX -> apt X, apt, apex
libopenaptx.x86_64: W: spelling-error %description -l en_US ffmpeg -> MPEG
libopenaptx.x86_64: W: no-documentation
libopenaptx-devel.x86_64: W: no-documentation
libopenaptx-tools.x86_64: W: no-documentation
libopenaptx-tools.x86_64: W: no-manual-page-for-binary openaptxdec
libopenaptx-tools.x86_64: W: no-manual-page-for-binary openaptxenc
libopenaptx.src: W: spelling-error Summary(en_US) aptX -> apt X, apt, apex
libopenaptx.src: W: spelling-error %description -l en_US aptX -> apt X, apt, apex
libopenaptx.src: W: spelling-error %description -l en_US ffmpeg -> MPEG
→ False positives.

libopenaptx-devel.x86_64: E: rpath-in-buildconfig /usr/lib64/pkgconfig/libopenaptx.pc lines ['9']
Yeah, the .pc files is borked:
> prefix=/usr/lib64
> exec_prefix=${prefix}
> libdir=${exec_prefix}//usr/include
→ this evaluates to libdir=/usr/lib64//usr/include
> Libs: -Wl,-rpath=${libdir} -L${libdir} -lopenaptx
→ this sets rpath, and it shouldn't.
> Cflags: -I${includedir}
→ this gets the include path wrong ;(

I think it'd be easiest to do something like
sed -r -i 's/^Libs:.*/Libs: -lopenaptx/; /Cflags:/d' /path/to/.pc

libopenaptx-tools.x86_64: W: summary-not-capitalized C libopenaptx encoder and decoder utilities
libopenaptx-tools.x86_64: E: description-line-too-long C The libopenaptx-tools package contains openaptxenc encoder and openaptxdec decoder
→ Maybe "AptX encoding and decoding tools"

6 packages and 0 specfiles checked; 2 errors, 12 warnings.

Package is APPROVED, conditional on Legal review.
Please fix issues listed above before upload.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #9)
> Yeah, the .pc files is borked:
> > prefix=/usr/lib64
> > exec_prefix=${prefix}
> > libdir=${exec_prefix}//usr/include
> → this evaluates to libdir=/usr/lib64//usr/include
> > Libs: -Wl,-rpath=${libdir} -L${libdir} -lopenaptx
> → this sets rpath, and it shouldn't.
> > Cflags: -I${includedir}
> → this gets the include path wrong ;(
> 
> I think it'd be easiest to do something like
> sed -r -i 's/^Libs:.*/Libs: -lopenaptx/; /Cflags:/d' /path/to/.pc

`%make_install PREFIX="%{_prefix}" LIBDIR="%{_lib}"` would generate correct paths in pkgconfig file. Makefile for this project expects all *DIR variables to be relative to the PREFIX.

(In reply to Ben Cotton from comment #4)
> Ack on the legal review. I'll get the patent status verified and then update
> this bug.

Hi @Ben, any advancements on the legal review? Looks like this still is still blocking the FE-Legal ticket.

It's been forwarded to the appropriate people. We're waiting for the resolution.

(In reply to Gergely Gombos from comment #11)
> Hi @Ben, any advancements on the legal review? Looks like this still is
> still blocking the FE-Legal ticket.

Not yet. I'll flag this with Red Hat Legal again.

Because the patent status is unclear, and we don't have a comprehensive list of the all patents involved in this technology, the aptX codec cannot be included in Fedora at this time. I am closing this ticket and wish I had a better answer.

Thanks @bcotton, this will go to rpmfusion then. 
I asked in IRC and @wtaymans confirmed that Pipewire could later use dlopen for codecs, so it could find the library even if it hadn't been built together with it.

I assume the needinfo was by mistake.

At the moment, adding libopenaptx to rpmfusion doesn't look like a viable alternative, because pipewire has to be built along with libopenaptx (like it's built with libldac) to enable support.
Suggestions are welcome, though.