Bug 791259 – media-video/pipewire-0.3.28[aptx], media-sound/bluez-alsa[aptx]: potential license violation with media-libs/libopenaptx (was: ERROR: Invalid version of dependency, need 'libopenaptx' ['< 0.2.1'] found '0.2.1'.)

• Status: CONFIRMED
• Product: Gentoo Linux

[Description HougeLangley 2021-05-21 04:28:29 UTC]

>>> Jobs: 1 of 1 complete                           Load avg: 18.5, 10.5, 5.2
 * Package:    media-video/pipewire-0.3.28
 * Repository: gentoo
 * Maintainer: [e-mail] [e-mail],[e-mail]
 * Upstream:   https://gitlab.freedesktop.org/pipewire/pipewire/-/issues
 * USE:        aac abi_x86_64 amd64 aptx bluetooth elibc_glibc extra gstreamer kernel_linux systemd userland_GNU v4l
 * FEATURES:   ccache network-sandbox preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking pipewire-0.3.28.tar.gz to /var/tmp/portage/media-video/pipewire-0.3.28/work
>>> Source unpacked in /var/tmp/portage/media-video/pipewire-0.3.28/work
>>> Preparing source in /var/tmp/portage/media-video/pipewire-0.3.28/work/pipewire-0.3.28 ...
 * Applying pipewire-0.3.25-enable-failed-mlock-warning.patch ...
 [ ok ]
 * Generating 40-pipewire.conf
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/media-video/pipewire-0.3.28/work/pipewire-0.3.28 ...
 * abi_x86_64.amd64: running multilib-minimal_abi_src_configure
meson setup --buildtype plain --libdir lib64 --localstatedir /var/lib --prefix /usr --sysconfdir /etc --wrap-mode nodownload --build.pkg-config-path /usr/share/pkgconfig --pkg-config-path /usr/share/pkgconfig --native-file /var/tmp/portage/media-video/pipewire-0.3.28/temp/meson.x86_64-pc-linux-gnu.amd64.ini -Ddocdir=/usr/share/doc/pipewire-0.3.28 -Ddocs=disabled -Dexamples=enabled -Dmedia-session=enabled -Dman=enabled -Dtests=disabled -Dinstalled_tests=disabled -Dgstreamer=enabled -Dgstreamer-device-provider=enabled -Dsystemd=enabled -Dsystemd-system-service=disabled -Dsystemd-user-service=enabled -Dpipewire-alsa=disabled -Dspa-plugins=enabled -Dalsa=enabled -Daudiomixer=enabled -Daudioconvert=enabled -Dbluez5=enabled -Dbluez5-backend-hsp-native=enabled -Dbluez5-backend-hfp-native=enabled -Dbluez5-backend-ofono=enabled -Dbluez5-backend-hsphfpd=enabled -Dbluez5-codec-aac=enabled -Dbluez5-codec-aptx=enabled -Dbluez5-codec-ldac=disabled -Dcontrol=enabled -Daudiotestsrc=enabled -Dffmpeg=disabled -Dpipewire-jack=enabled -Djack=disabled -Djack-devel=disabled -Dsupport=enabled -Devl=disabled -Dtest=disabled -Dv4l2=enabled -Dlibcamera=disabled -Dvideoconvert=enabled -Dvideotestsrc=enabled -Dvolume=enabled -Dvulkan=disabled -Dpw-cat=enabled -Dudev=enabled -Dudevrulesdir=/lib/udev/rules.d -Dsdl2=disabled -Dsndfile=enabled /var/tmp/portage/media-video/pipewire-0.3.28/work/pipewire-0.3.28 /var/tmp/portage/media-video/pipewire-0.3.28/work/pipewire-0.3.28-abi_x86_64.amd64
DEPRECATION: c_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: c_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: fortran_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: fortran_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objc_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objc_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objcpp_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objcpp_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
The Meson build system
Version: 0.57.2
Source dir: /var/tmp/portage/media-video/pipewire-0.3.28/work/pipewire-0.3.28
Build dir: /var/tmp/portage/media-video/pipewire-0.3.28/work/pipewire-0.3.28-abi_x86_64.amd64
Build type: native build
Project name: pipewire
Project version: 0.3.28
C compiler for the host machine: x86_64-pc-linux-gnu-gcc (gcc 11.1.0 "x86_64-pc-linux-gnu-gcc (Gentoo 11.1.0 p1) 11.1.0")
C linker for the host machine: x86_64-pc-linux-gnu-gcc ld.bfd 2.36.1
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -fvisibility=hidden: YES 
Compiler for C supports arguments -Werror=suggest-attribute=format: YES 
Compiler for C supports arguments -Wsign-compare: YES 
Compiler for C supports arguments -Wpointer-arith: YES 
Compiler for C supports arguments -Wpointer-sign: YES 
Compiler for C supports arguments -Wformat: YES 
Compiler for C supports arguments -Wformat-security: YES 
Compiler for C supports arguments -Wimplicit-fallthrough: YES 
Compiler for C supports arguments -Wmissing-braces: YES 
Compiler for C supports arguments -Wtype-limits: YES 
Compiler for C supports arguments -Wvariadic-macros: YES 
Compiler for C supports arguments -Wno-missing-field-initializers: YES 
Compiler for C supports arguments -Wno-unused-parameter: YES 
Compiler for C supports arguments -Wno-pedantic: YES 
Compiler for C supports arguments -Wold-style-declaration: YES 
Compiler for C supports arguments -Wunused-result: YES 
Compiler for C supports arguments -DFASTPATH: YES 
C++ compiler for the host machine: x86_64-pc-linux-gnu-g++ (gcc 11.1.0 "x86_64-pc-linux-gnu-g++ (Gentoo 11.1.0 p1) 11.1.0")
C++ linker for the host machine: x86_64-pc-linux-gnu-g++ ld.bfd 2.36.1
Compiler for C++ supports arguments -fvisibility=hidden: YES 
Compiler for C++ supports arguments -Werror=suggest-attribute=format: YES 
Compiler for C++ supports arguments -Wsign-compare: YES 
Compiler for C++ supports arguments -Wpointer-arith: YES 
Compiler for C++ supports arguments -Wpointer-sign: NO 
Compiler for C++ supports arguments -Wformat: YES 
Compiler for C++ supports arguments -Wformat-security: YES 
Compiler for C++ supports arguments -Wimplicit-fallthrough: YES 
Compiler for C++ supports arguments -Wmissing-braces: YES 
Compiler for C++ supports arguments -Wtype-limits: YES 
Compiler for C++ supports arguments -Wvariadic-macros: YES 
Compiler for C++ supports arguments -Wno-missing-field-initializers: YES 
Compiler for C++ supports arguments -Wno-unused-parameter: YES 
Compiler for C++ supports arguments -Wno-pedantic: YES 
Compiler for C++ supports arguments -Wold-style-declaration: NO 
Compiler for C++ supports arguments -Wunused-result: YES 
Compiler for C supports arguments -msse: YES 
Compiler for C supports arguments -msse2: YES 
Compiler for C supports arguments -mssse3: YES 
Compiler for C supports arguments -msse4.1: YES 
Compiler for C supports arguments -mfma: YES 
Compiler for C supports arguments -mavx: YES 
Compiler for C supports arguments -mavx2: YES 
Compiler for C supports arguments -mfpu=neon: NO 
Library atomic found: YES
Checking if "8-byte __atomic_store_n without libatomic" links: YES 
Has header "dlfcn.h" : YES 
Has header "inttypes.h" : YES 
Has header "memory.h" : YES 
Has header "poll.h" : YES 
Has header "stddef.h" : YES 
Has header "stdint.h" : YES 
Has header "stdio_ext.h" : YES 
Has header "strings.h" : YES 
Has header "string.h" : YES 
Has header "sys/mount.h" : YES 
Has header "sys/param.h" : YES 
Has header "sys/poll.h" : YES 
Has header "sys/prctl.h" : YES 
Has header "sys/random.h" : YES 
Has header "sys/socket.h" : YES 
Has header "sys/stat.h" : YES 
Has header "sys/times.h" : YES 
Has header "sys/time.h" : YES 
Has header "sys/types.h" : YES 
Has header "sys/utsname.h" : YES 
Has header "sys/vfs.h" : YES 
Has header "sys/wait.h" : YES 
Has header "pwd.h" : YES 
Has header "ucontext.h" : YES 
Has header "unistd.h" : YES 
Has header "valgrind/valgrind.h" : NO 
Checking for function "poll" : YES 
Checking for function "pselect" : YES 
Checking for function "posix_memalign" : YES 
Checking for function "getpagesize" : YES 
Checking for function "clock_gettime" : YES 
Checking for type "ptrdiff_t" : YES 
Header <string.h> has symbol "strndupa" : YES 
Checking for function "mkstemp" : YES 
Checking for function "memfd_create" : YES 
Checking for function "getrandom" : YES 
Found pkg-config: /usr/bin/x86_64-pc-linux-gnu-pkg-config (1.7.4)
Run-time dependency systemd found: YES 248
Run-time dependency libsystemd found: YES 248
Configuring Makefile using configuration
Library m found: YES
Library rt found: YES
Library dl found: YES
Run-time dependency threads found: YES
Run-time dependency dbus-1 found: YES 1.12.20
Dependency sdl2 skipped: feature sdl2 disabled
Run-time dependency ncursesw found: YES 6.2.20210123
Run-time dependency sndfile found: YES 1.0.31
Run-time dependency libpulse found: YES 13.0
Run-time dependency avahi-client found: YES 0.8
Run-time dependency gio-2.0 found: YES 2.68.2
Run-time dependency gio-unix-2.0 found: YES 2.68.2
Run-time dependency glib-2.0 found: YES 2.68.2
Run-time dependency gmodule-2.0 found: YES 2.68.2
Run-time dependency gobject-2.0 found: YES 2.68.2
Run-time dependency gstreamer-1.0 found: YES 1.16.3
Run-time dependency gstreamer-allocators-1.0 found: YES 1.16.3
Run-time dependency gstreamer-audio-1.0 found: YES 1.16.3
Run-time dependency gstreamer-plugins-base-1.0 found: YES 1.16.3
Run-time dependency gstreamer-video-1.0 found: YES 1.16.3
Library intl found: NO
Dependency alsa skipped: feature pipewire-alsa disabled
Run-time dependency alsa found: YES 1.2.4
Run-time dependency bluez found: YES 5.58
Run-time dependency sbc found: YES 1.5
Dependency ldacBT-enc skipped: feature bluez5-codec-ldac disabled
Dependency ldacBT-abr skipped: feature bluez5-codec-ldac disabled
Dependency libopenaptx found: NO found 0.2.1 but need: '< 0.2.1'
Found CMake: /usr/bin/cmake (3.20.2)
Run-time dependency libopenaptx found: NO (tried cmake)

../pipewire-0.3.28/spa/meson.build:25:2: ERROR: Invalid version of dependency, need 'libopenaptx' ['< 0.2.1'] found '0.2.1'.

A full log can be found at /var/tmp/portage/media-video/pipewire-0.3.28/work/pipewire-0.3.28-abi_x86_64.amd64/meson-logs/meson-log.txt
 * ERROR: media-video/pipewire-0.3.28::gentoo failed (configure phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line  125:  Called src_configure
 *   environment, line 2795:  Called multilib-minimal_src_configure
 *   environment, line 1766:  Called multilib_foreach_abi 'multilib-minimal_abi_src_configure'
 *   environment, line 2019:  Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 *   environment, line 1696:  Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 *   environment, line 1694:  Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure'
 *   environment, line  584:  Called multilib-minimal_abi_src_configure
 *   environment, line 1760:  Called multilib_src_configure
 *   environment, line 2236:  Called meson_src_configure
 *   environment, line 1628:  Called die
 * The specific snippet of code:
 *       "${mesonargs[@]}" ) || die
 * 
 * If you need support, post the output of `emerge --info '=media-video/pipewire-0.3.28::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=media-video/pipewire-0.3.28::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/media-video/pipewire-0.3.28/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/media-video/pipewire-0.3.28/temp/environment'.
 * Working directory: '/var/tmp/portage/media-video/pipewire-0.3.28/work/pipewire-0.3.28-abi_x86_64.amd64'
 * S: '/var/tmp/portage/media-video/pipewire-0.3.28/work/pipewire-0.3.28'

[Comment 1 HougeLangley 2021-05-21 04:37:43 UTC]

../pipewire-0.3.28/spa/meson.build:25:2: ERROR: Invalid version of dependency, need 'libopenaptx' ['< 0.2.1'] found '0.2.1'.

This is the proble. Have to mask, install 0.2.0 version libopenaptx, the pipwire will success upgrade. then unmask libopenaptx to restore 0.2.1 version libopenaptx

[Comment 2 12101111 2021-05-21 05:45:53 UTC]

libopenaptx 0.2.1 don't have any code change but update its license.

This is part of its README:

```
This is Open Source implementation of Audio Processing Technology codec (aptX)
originally derived from ffmpeg 4.0 project and licensed under GPLv3+. This codec
is mainly used in Bluetooth A2DP profile. If you need other license of this
project then please contact author for possible options. Participants of
Freedesktop and Collabora projects and any other affiliated persons with them
are not allowed to contact author.

This library and any other project which uses this library must not be used in
other organizations, projects, applications, libraries (and in any other
software form) incompatible with libopenaptx licence or where current license of
this project is violated or where previous version of this library/license was
violated. Freedesktop and Collabora are examples of such projects which are not
allowed to use this library in any form due to license violations.

As Freedesktop and Collabora projects are continuously abusing and violating
license of this project and claiming that they can do it as it is supported
by their own Code of Conduct (including censorship practising, removal of all
user reports mentioning these activities, banning these users and not explaining
anything), this library and any other project which uses this library must not
be used or distributed in any Freedesktop or Collabora project, application or
library, either in source code, loaded or linked at compile time or at runtime
either directly or transitionally throw additional wrapper library or in any
other similar form.

As these projects are misusing their Code of Conduct to eliminate people with
different nationality, skin, religion and gender, their participants are not
allowed to contribute into this library in any form and are disallowed to send
any question, note, issue, change request or other similar thing to this project
until those projects stop violating license of other projects which they use,
unban all banned users and explain their immoral activities.

Other projects which are adding additional hidden or implicit restrictions to
their licenses throw their own Code of Conduct explanation and therefore make
them incompatible with license of this library are not allowed to use this
library or any other application based on this library in their project in any
form, including redistribution.
```

Does the original license of libopenaptx, GPL-3.0 allow such exclusion?

[Comment 3 Emily Rowlands 2021-05-21 08:52:26 UTC]

(In reply to 12101111 from comment #2)
> libopenaptx 0.2.1 don't have any code change but update its license.
> 
> This is part of its README:
> 
> ```
> This is Open Source implementation of Audio Processing Technology codec
> (aptX)
> originally derived from ffmpeg 4.0 project and licensed under GPLv3+. This
> codec
> is mainly used in Bluetooth A2DP profile. If you need other license of this
> project then please contact author for possible options. Participants of
> Freedesktop and Collabora projects and any other affiliated persons with them
> are not allowed to contact author.
> 
> This library and any other project which uses this library must not be used
> in
> other organizations, projects, applications, libraries (and in any other
> software form) incompatible with libopenaptx licence or where current
> license of
> this project is violated or where previous version of this library/license
> was
> violated. Freedesktop and Collabora are examples of such projects which are
> not
> allowed to use this library in any form due to license violations.
> 
> As Freedesktop and Collabora projects are continuously abusing and violating
> license of this project and claiming that they can do it as it is supported
> by their own Code of Conduct (including censorship practising, removal of all
> user reports mentioning these activities, banning these users and not
> explaining
> anything), this library and any other project which uses this library must
> not
> be used or distributed in any Freedesktop or Collabora project, application
> or
> library, either in source code, loaded or linked at compile time or at
> runtime
> either directly or transitionally throw additional wrapper library or in any
> other similar form.
> 
> As these projects are misusing their Code of Conduct to eliminate people with
> different nationality, skin, religion and gender, their participants are not
> allowed to contribute into this library in any form and are disallowed to
> send
> any question, note, issue, change request or other similar thing to this
> project
> until those projects stop violating license of other projects which they use,
> unban all banned users and explain their immoral activities.
> 
> Other projects which are adding additional hidden or implicit restrictions to
> their licenses throw their own Code of Conduct explanation and therefore make
> them incompatible with license of this library are not allowed to use this
> library or any other application based on this library in their project in
> any
> form, including redistribution.
> ```
> 
> Does the original license of libopenaptx, GPL-3.0 allow such exclusion?

This was discussed in bug #785634

[Comment 4 Larry the Git Cow 2021-05-21 23:05:20 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3e5e2c5e7337086a3aba193bfe11dabb687760f6

commit 3e5e2c5e7337086a3aba193bfe11dabb687760f6
Author:     Thomas Deutschmann <[e-mail]>
AuthorDate: 2021-05-21 23:04:22 +0000
Commit:     Thomas Deutschmann <[e-mail]>
CommitDate: 2021-05-21 23:05:16 +0000

    media-video/pipewire: allow >openaptx-0.2
    
    Closes: https://bugs.gentoo.org/791259
    Package-Manager: Portage-3.0.18, Repoman-3.0.3
    Signed-off-by: Thomas Deutschmann <[e-mail]>

 ...pipewire-0.3.28-revert-openaptx-restriction.patch | 20 ++++++++++++++++++++
 media-video/pipewire/pipewire-0.3.28.ebuild          |  1 +
 media-video/pipewire/pipewire-9999.ebuild            |  1 +
 3 files changed, 22 insertions(+)

[Comment 5 Michał Górny 2021-07-06 06:14:37 UTC]

Funny clauses or not, since libopenaptx is now GPL-3+, pipewire must also be GPL-3[+] to be allowed to link to it.  Redistributing pipewire[aptx] as the current LICENSE is a violation of linking clause in GPL (whether it is really enforceable or not is a different matter entirely).

At the very least, you should force GPL-3+ in pipewire if you'are going to link with newer versions of libopenaptx.  Though tbh I don't see the purpose in proactively using 0.2.1 or even packaging it, given it has no meaningful changes in installed files besides the license change.

And ofc before packaging such a major license change, it would have been nice to verify that you're not causing license violations in revdeps.

[Comment 6 Larry the Git Cow 2021-07-06 06:17:32 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5bc980e236449b77d7c5742e40551b17f9c739aa

commit 5bc980e236449b77d7c5742e40551b17f9c739aa
Author:     Michał Górny <[e-mail]>
AuthorDate: 2021-07-06 06:16:42 +0000
Commit:     Michał Górny <[e-mail]>
CommitDate: 2021-07-06 06:17:21 +0000

    package.mask: Mask media-libs/libopenaptx-0.2.1 for license trouble
    
    Bug: https://bugs.gentoo.org/791259
    Signed-off-by: Michał Górny <[e-mail]>

 profiles/package.mask | 6 ++++++
 1 file changed, 6 insertions(+)

[Comment 7 Michał Górny 2021-07-06 06:19:17 UTC]

Let's use the same bug for bluez-alsa too, to avoid scattering info.  Since bluez-alsa is MIT, it also can't remain MIT when linking to GPL-3+ libopenaptx.

[Comment 8 Ulrich Müller 2021-07-06 06:45:47 UTC]

(In reply to Michał Górny from comment #7)
> Let's use the same bug for bluez-alsa too, to avoid scattering info.  Since
> bluez-alsa is MIT, it also can't remain MIT when linking to GPL-3+
> libopenaptx.

MIT is GPL compatible, so no problem there.

The libopenaptx license is discussed in bug 785634, and I'd much prefer to keep the discussion there, rather than splitting it between several bugs. IMHO upstream has sufficiently clarified that it is under the GPL, and that the text in the README file doesn't constitute any additional restrictions.

(In reply to Larry the Git Cow from comment #6)
>     package.mask: Mask media-libs/libopenaptx-0.2.1 for license trouble

I don't understand why you mask a GPL-3+ licensed package for "license trouble"? If anything, it should be a package.use.mask for pipewire[aptx].

[Comment 9 Ulrich Müller 2021-07-06 06:50:12 UTC]

(In reply to Ulrich Müller from comment #8)
> I don't understand why you mask a GPL-3+ licensed package for "license
> trouble"? If anything, it should be a package.use.mask for pipewire[aptx].

Or rather, RESTRICT="aptx? ( bindist )" in the pipewire ebuild, since arguably dynamic linking itself is not a copyright violation, only distributing the resulting binary is.

Disclaimer: IANAL, TINLA.

[Comment 10 Michał Górny 2021-07-06 06:51:09 UTC]

(In reply to Ulrich Müller from comment #8)
> (In reply to Michał Górny from comment #7)
> > Let's use the same bug for bluez-alsa too, to avoid scattering info.  Since
> > bluez-alsa is MIT, it also can't remain MIT when linking to GPL-3+
> > libopenaptx.
> 
> MIT is GPL compatible, so no problem there.
> 
> The libopenaptx license is discussed in bug 785634, and I'd much prefer to
> keep the discussion there, rather than splitting it between several bugs.
> IMHO upstream has sufficiently clarified that it is under the GPL, and that
> the text in the README file doesn't constitute any additional restrictions.

But you can't link to a GPL library and release the result as MIT, right?

> (In reply to Larry the Git Cow from comment #6)
> >     package.mask: Mask media-libs/libopenaptx-0.2.1 for license trouble
> 
> I don't understand why you mask a GPL-3+ licensed package for "license
> trouble"? If anything, it should be a package.use.mask for pipewire[aptx].

I've masked it because it has been committed without ensuring that the revdeps are compatible.

[Comment 11 Matt Turner 2021-07-06 07:05:19 UTC]

(In reply to Ulrich Müller from comment #8)
> I don't understand why you mask a GPL-3+ licensed package for "license
> trouble"? If anything, it should be a package.use.mask for pipewire[aptx].

Because it's only the v0.2.1 that has the GPL-3+ license, so a package.use.mask would prevent pipewire from working with v0.2.0.

There are basically zero changes between 0.2.0 and 0.2.1, and the license was changed in the commit that changes the version to v0.2.1 [1] with no other changes so there's really no need to worry about what we're missing out on in v0.2.1.

[1] https://github.com/pali/libopenaptx/commit/811bc18586d634042618d633727ac0281d4170b8

[Comment 12 Ulrich Müller 2021-07-06 07:14:49 UTC]

(In reply to Michał Górny from comment #10)
> But you can't link to a GPL library and release the result as MIT, right?

That applies to the binary, not to the source code. We don't include the license of dependencies in LICENSE, because the user must accept the license of the dependency when they install it. In any case the binary can be freely distributed (under the terms of both licenses combined).

[Comment 13 Michał Górny 2021-07-06 08:40:25 UTC]

I am sorry, I have overreacted on this bug and I have used the wrongly terminology that has lead to some confusion.  To clear things up:

1. When linking dynamically to GPL-3+ libraries (according to FSF's standpoint), the license used to redistribute resulting *binaries* must include GPL-3.

2. Independently of whatever happens in Gentoo, it would be probably good to warn bluez-alsa upstream of the problem, in case they ever ended up redistributing binary packages.

3. Apparently how we should handle it in Gentoo is arguable.  In my opinion, we should include GPL-3+ in revdeps' LICENSE since it's going to affect binary packages built on Gentoo, except that...

4. I think we can agree that the easiest solution right now is not to package the new version at all for the time being.  It has no meaningful changes, except for the license change.

Hopefully, upstream will find a good solution before a new release with meaningful changes happens (if ever).

[Comment 14 Thomas Deutschmann (RETIRED) 2021-07-06 12:41:25 UTC]

(In reply to Michał Górny from comment #13)
> 4. I think we can agree that the easiest solution right now is not to
> package the new version at all for the time being.  It has no meaningful
> changes, except for the license change.

No! Definitely not!

1) Please tell us under which authority (in Gentoo) you pushed that mask because I am going to challenge this permission. You cannot decide on your own to push something like that after so many days. Especially when a discussion is ongoing/was resolved.

2) And you still did not provide any reason why any of this is affecting Gentoo at all. The GPL change is not touching anything mentioned in https://devmanual.gentoo.org/general-concepts/licenses/ so it doesn't affect us.

If for some reason you suddenly want to be over-cautious in this case, you should provide reasons. But do not decide something like that on your own. And after so many days, it cannot be time critical to force anyone with 0.2.1 installed to downgrade (and it doesn't matter if it is a small package or not).

[Comment 15 Michał Górny 2021-07-06 12:52:28 UTC]

(In reply to Thomas Deutschmann from comment #14)
> (In reply to Michał Górny from comment #13)
> > 4. I think we can agree that the easiest solution right now is not to
> > package the new version at all for the time being.  It has no meaningful
> > changes, except for the license change.
> 
> No! Definitely not!

And why is that?  As has been proven already, the version doesn't introduce an changes besides the doubtful license change, and the primary maintainer of this package is against bumping it.  On what authority do you override the maintainer's decision?

> 1) Please tell us under which authority (in Gentoo) you pushed that mask
> because I am going to challenge this permission. You cannot decide on your
> own to push something like that after so many days. Especially when a
> discussion is ongoing/was resolved.

I would really prefer if we focused on the issue at hand rather than trying to push a bad decision forward based on some authority-based scheming.

> 2) And you still did not provide any reason why any of this is affecting
> Gentoo at all. The GPL change is not touching anything mentioned in
> https://devmanual.gentoo.org/general-concepts/licenses/ so it doesn't affect
> us.

"Detecting upstream license problems", point 3.

> If for some reason you suddenly want to be over-cautious in this case, you
> should provide reasons. But do not decide something like that on your own.

The whole point of masks is to be cautious.  If the matter was considered final, we'd just have removed it immediately.

> And after so many days, it cannot be time critical to force anyone with
> 0.2.1 installed to downgrade (and it doesn't matter if it is a small package
> or not).

So, what exactly do Gentoo users lose by downgrading to the version with exactly the same code?  Except for potential license-related risks.

[Comment 16 Thomas Deutschmann (RETIRED) 2021-07-06 13:25:40 UTC]

(In reply to Michał Górny from comment #15)
> (In reply to Thomas Deutschmann from comment #14)
> > (In reply to Michał Górny from comment #13)
> > > 4. I think we can agree that the easiest solution right now is not to
> > > package the new version at all for the time being.  It has no meaningful
> > > changes, except for the license change.
> > 
> > No! Definitely not!
> 
> And why is that?  As has been proven already, the version doesn't introduce
> an changes besides the doubtful license change, and the primary maintainer
> of this package is against bumping it.  On what authority do you override
> the maintainer's decision?

What did I?

You realize that the package is also maintained by codec project and was added in first place as DEP for pipewire?


> > 1) Please tell us under which authority (in Gentoo) you pushed that mask
> > because I am going to challenge this permission. You cannot decide on your
> > own to push something like that after so many days. Especially when a
> > discussion is ongoing/was resolved.
> 
> I would really prefer if we focused on the issue at hand rather than trying
> to push a bad decision forward based on some authority-based scheming.

Sure, but don't distract. Please answer that question. As the developer who did that bump in May I want to know why this was basically reverted: Did you do that as member of codec project, QA member, Council member, Infra member...?


> So, what exactly do Gentoo users lose by downgrading to the version with
> exactly the same code?  Except for potential license-related risks.

You are really missing my point here. You are creating facts first. That's my problem. Gentoo is a community. We are hopefully working on the same project, _together_. The package was bumped *two* months ago. Do you really don't understand why someone thinks it is rude when someone other will just push a mask after >60 days without even consulting with the team?! You already acknowledged that you overreacted (no big deal, but in that case please fully fix what you did and don't try to find excuses ("Nah, 0.2.1 is not really changing anything so mask can stay")).

Thanks.

[Comment 17 Matt Turner 2021-07-06 17:23:46 UTC]

(In reply to Thomas Deutschmann from comment #16)
> > So, what exactly do Gentoo users lose by downgrading to the version with
> > exactly the same code?  Except for potential license-related risks.
> 
> You are really missing my point here. You are creating facts first. That's
> my problem. Gentoo is a community. We are hopefully working on the same
> project, _together_. The package was bumped *two* months ago. Do you really
> don't understand why someone thinks it is rude when someone other will just
> push a mask after >60 days without even consulting with the team?! You
> already acknowledged that you overreacted (no big deal, but in that case
> please fully fix what you did and don't try to find excuses ("Nah, 0.2.1 is
> not really changing anything so mask can stay")).

Holy shit, calm down, this is not a big deal...

There are no real changes between 0.2.0 and 0.2.1. I suspect the only reason this topic came up now (as opposed to some past date closer to when you added 0.2.1) is because of the GNOME stabilization that I filed yesterday. Soon after filing it, leio requested changing the stabilization target from 0.2.1 -> 0.2.0 and I agreed. I was only vaguely aware of some kind of hostile upstream before this. I suspect others were in the same boat.

This is not a hill worth dying on. Take it easy...

[Comment 18 Matthew Thode ( prometheanfire ) 2021-07-06 23:46:31 UTC]

as a user, is it possible to set a license for a use flag?  This situation reminds me of the kernel and nvidia thing...

[Comment 19 Michał Górny 2021-07-07 06:28:35 UTC]

(In reply to Matthew Thode ( prometheanfire ) from comment #18)
> as a user, is it possible to set a license for a use flag?  This situation
> reminds me of the kernel and nvidia thing...

You could make LICENSE of a package conditional to a USE flag... but the problem is, that the license actually depends on the version of the library.

[Comment 20 Niklāvs Koļesņikovs 2021-07-29 16:52:32 UTC]

After more drama, PipeWire project has decided (and 1h ago merged) a commit that replaces libopenaptx with libfreeaptx without any fallback.

https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/843

[Comment 21 Larry the Git Cow 2021-08-23 03:14:26 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=61790034799954c4799fa3fc68d45ccc47282d52

commit 61790034799954c4799fa3fc68d45ccc47282d52
Author:     Sam James <[e-mail]>
AuthorDate: 2021-08-23 03:14:00 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2021-08-23 03:14:03 +0000

    media-libs/libfreeaptx: initial import (fork of media-libs/libopenaptx)
    
    Bug: https://bugs.gentoo.org/791259
    Signed-off-by: Sam James <[e-mail]>

 media-libs/libfreeaptx/Manifest                    |  1 +
 .../files/libfreeaptx-0.1.1-fix-version.patch      | 20 +++++++++
 media-libs/libfreeaptx/libfreeaptx-0.1.1.ebuild    | 50 ++++++++++++++++++++++
 media-libs/libfreeaptx/libfreeaptx-9999.ebuild     | 49 +++++++++++++++++++++
 media-libs/libfreeaptx/metadata.xml                | 15 +++++++
 5 files changed, 135 insertions(+)

[Comment 22 Larry the Git Cow 2021-09-13 23:07:00 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=121747cd3cfd88744c0f6beae5cc86d4aee858f5

commit 121747cd3cfd88744c0f6beae5cc86d4aee858f5
Author:     Sam James <[e-mail]>
AuthorDate: 2021-09-13 23:02:01 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2021-09-13 23:06:50 +0000

    media-video/pipewire: add 0.3.35
    
    Switches to libfreeaptx as per upstream.
    
    Waiting for now re wireplumber default
    integration, but it's not strictly
    needed right now anyway.
    
    Bug: https://bugs.gentoo.org/791259
    Bug: https://bugs.gentoo.org/807616
    Closes: https://bugs.gentoo.org/812809
    Signed-off-by: Sam James <[e-mail]>

 media-video/pipewire/Manifest                      |   1 +
 .../pipewire-0.3.35-non-systemd-integration.patch  |  20 ++
 media-video/pipewire/pipewire-0.3.35.ebuild        | 276 +++++++++++++++++++++
 3 files changed, 297 insertions(+)

[Comment 23 Niklāvs Koļesņikovs 2021-11-16 21:20:15 UTC]

To summarize Gentoo's pipewire has been switched over to use libfreeaptx, so this bug is not a problem anymore as far as PipeWire is concerned.

Regarding bluez-alsa, unless I am mistaken, it's not forbidden from using libopenaptx, not to mention that everyone, including Pali, agrees that it's regular LGPLv3 (which is the license under which Gentoo users receive the libopenaptx source code from our servers), so it's not an issue for it either.

As such I suggest closing this as FIXED.

[Comment 24 Niklāvs Koļesņikovs 2021-11-16 21:21:28 UTC]

Sorry, it's regular GPLv3 not LGPL (I did double check that wasn't the L variant but forgot to change it).