Summary: | 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'.) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | HougeLangley <hougelangley1987> |
Component: | Current packages | Assignee: | Sam James <sam> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | asturm, codec, ionen, joakim.tjernlund, leio, licenses, marduk, mattst88, mgorny, skruppy+gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=785634 https://bugs.gentoo.org/show_bug.cgi?id=809591 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
HougeLangley
2021-05-21 04:28:29 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 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? (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 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 <whissi@gentoo.org> AuthorDate: 2021-05-21 23:04:22 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> 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 <whissi@gentoo.org> ...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(+) 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. 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 <mgorny@gentoo.org> AuthorDate: 2021-07-06 06:16:42 +0000 Commit: Michał Górny <mgorny@gentoo.org> 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 <mgorny@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+) 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. (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]. (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. (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. (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 (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). 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). (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). (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. (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. (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... as a user, is it possible to set a license for a use flag? This situation reminds me of the kernel and nvidia thing... (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. 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 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 <sam@gentoo.org> AuthorDate: 2021-08-23 03:14:00 +0000 Commit: Sam James <sam@gentoo.org> 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 <sam@gentoo.org> 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(+) 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 <sam@gentoo.org> AuthorDate: 2021-09-13 23:02:01 +0000 Commit: Sam James <sam@gentoo.org> 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 <sam@gentoo.org> 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(+) 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. Sorry, it's regular GPLv3 not LGPL (I did double check that wasn't the L variant but forgot to change it). |