starred/librespot

Fork 0

mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 08:15:50 +03:00

[GH-ISSUE #539] Licensing (in-)compatibility problems #344

New issue

Closed

opened 2026-02-27 19:30:08 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 19:30:08 +03:00

Owner

Originally created by @jnqnfe on GitHub (Nov 26, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/539

edit: please ignore everything except the second issue, as discussed in my followup.

I wish to bring to your attention the fact that your crates are not fully compatible with the licensing of all of their dependencies.

~~I have not gone through every dependency in detail, I'll leave that to you~~, but the problems include the following:

While most of your dependencies are 'MIT or Apache-2.0' licensed (giving dependant crates a choice), some are Apache-2.0 only. While an Apache-2.0 licensed project can use MIT licensed components, I do not believe that conversely an MIT licensed project can depend upon Apache-2.0 only components. Apache 2.0 is more complicated than MIT and for instance it is incompatible with GPL v2. Your crates being MIT licensed are thus non-compliant with their licensing obligations and furthermore mislead any hypothetical users of those crates.
The version of libpulse-sys you currently depend upon (v0.0.0) is LGPL-v3 licensed, which is incompatible with your MIT licensing. Note that this crate was taken over in Feb-2018 by a new owner (myself) for future versions, switching to LGPL-2.1+ initially, then to 'MIT OR Apache-2.0' from v1.11 (Sep-2019) onwards.

I intend to provide a PR shortly to bump the libpulse-sys version to a much newer one which will take care of the second problem.

~~The first problem could obviously be solved by either:~~

a. ~~Dropping/replacing the problematic dependencies.~~
b. ~~Convincing the owners of the problematic dependencies to switch from Apache-2.0 only to 'MIT OR Apache-2.0', switching to those new versions, and yanking your older non-compliant crate versions.~~
c. Switching your crates from MIT to Apache-2.0 (to be clear, Apache-2.0 only, you can not offer MIT at all unless all dependencies offer an MIT compatible licensing option), and yanking your non-compliant versions. However additionally, contributions to your project by others thus far have been defacto licensed to you under the licensing of your project (MIT) and you cannot just switch your codebase to different licensing without either getting explicit permission from every contributor, or removing (reverting) all contributions from those who have not given permission.

Originally created by @jnqnfe on GitHub (Nov 26, 2020). Original GitHub issue: https://github.com/librespot-org/librespot/issues/539 edit: please ignore everything except the second issue, as discussed in my followup. I wish to bring to your attention the fact that your crates are not fully compatible with the licensing of all of their dependencies. ~I have not gone through every dependency in detail, I'll leave that to you~, but the problems include the following: 1. ~While most of your dependencies are 'MIT or Apache-2.0' licensed (giving dependant crates a choice), some are Apache-2.0 only. While an Apache-2.0 licensed project can use MIT licensed components, I do not believe that conversely an MIT licensed project can depend upon Apache-2.0 only components. Apache 2.0 is more complicated than MIT and for instance it is incompatible with GPL v2. Your crates being MIT licensed are thus non-compliant with their licensing obligations and furthermore mislead any hypothetical users of those crates.~ 2. The version of `libpulse-sys` you currently depend upon (v0.0.0) is LGPL-v3 licensed, which is incompatible with your MIT licensing. Note that this crate was taken over in Feb-2018 by a new owner (myself) for future versions, switching to LGPL-2.1+ initially, then to 'MIT OR Apache-2.0' from v1.11 (Sep-2019) onwards. I intend to provide a PR shortly to bump the `libpulse-sys` version to a much newer one which will take care of the second problem. ~The first problem could obviously be solved by either:~ * a. ~Dropping/replacing the problematic dependencies.~ * b. ~Convincing the owners of the problematic dependencies to switch from Apache-2.0 only to 'MIT OR Apache-2.0', switching to those new versions, and yanking your older non-compliant crate versions.~ * c. ~Switching your crates from MIT to Apache-2.0 (to be clear, Apache-2.0 only, you can not offer MIT at all unless all dependencies offer an MIT compatible licensing option), and yanking your non-compliant versions. However additionally, contributions to your project by others thus far have been defacto licensed to you under the licensing of your project (MIT) and you cannot just switch your codebase to different licensing without either getting explicit permission from every contributor, or removing (reverting) all contributions from those who have not given permission.~

kerem closed this issue

2026-02-27 19:30:08 +03:00

kerem commented

2026-02-27 19:30:08 +03:00

Author

Owner

@jnqnfe commented on GitHub (Nov 28, 2020):

Actually, looking into things a little more today, I believe I was mistaken about the compatibility issue with respect to the first issue. Apologies for the noise, please ignore that one. (The aspect regarding masking the underlying use of Apache-2.0 components being problematic to helping GPL projects find compatible crates to use is still correct though.

The second issue regarding libpulse_sys still stands. PR #540 addresses this. Regarding yanking past versions of your crates after releasing a new version combining PR #540, I'd say it's probably not worth worrying about considering the retraction of the first issue. I'm personally not concerned and I'm sure the original author of that v0.0.0 wouldn't be either, so bumping up to a newer version per PR #540 should be entirely sufficient to close this.

@jnqnfe commented on GitHub (Nov 28, 2020): Actually, looking into things a little more today, I believe I was mistaken about the compatibility issue with respect to the first issue. Apologies for the noise, please ignore that one. (The aspect regarding masking the underlying use of Apache-2.0 components being problematic to helping GPL projects find compatible crates to use is still correct though. The second issue regarding `libpulse_sys` still stands. PR #540 addresses this. Regarding yanking past versions of your crates after releasing a new version combining PR #540, I'd say it's probably not worth worrying about considering the retraction of the first issue. I'm personally not concerned and I'm sure the original author of that v0.0.0 wouldn't be either, so bumping up to a newer version per PR #540 should be entirely sufficient to close this.

kerem commented

2026-02-27 19:30:08 +03:00

Author

Owner

@jnqnfe commented on GitHub (Dec 14, 2020):

With PR #540 landed (on the dev branch at least), that resolves the libpulse_sys aspect (assuming it gets merged to master).

The only other thing that should be considered before closing this concerns licensing of the binary.

I think now that it is reasonable for the licensing expressed in Cargo.toml files to cover the code within the crate only, ignoring it's dependencies. So it's fine for the binary crate to specify just MIT. After all the code from the dependencies is not being directly distributed in source form, just referenced as a dependency. Although it is far from certain that this is the correct way to use the license cargo config field. Many projects are doing just that though.
Use and distribution of compiled binaries however, is a different matter. These cannot be used or distributed under only MIT licensing. They must be used and distributed under at least Apache-2.0 only, or combined MIT AND Apache-2.0. The full list of dependencies must be checked for both compatibility and to ensure this covers everything.

Some of the text in the main repo README.md is a little problematic with regards to the seconds point. The text under the "License" heading ("Everything in this repository is licensed under the MIT license.") may be a little misleading, especially combined with the "Quick start" portion giving installation instructions (even though technically does not involve distribution of pre-compiled code).

It may be important to clarify in this text that although the code actually within the repo is MIT licensed, the resulting binaries produced are not simply MIT licensed.

@jnqnfe commented on GitHub (Dec 14, 2020): With PR #540 landed (on the `dev` branch at least), that resolves the `libpulse_sys` aspect (assuming it gets merged to `master`). The only other thing that should be considered before closing this concerns licensing of the binary. 1. I think now that it is reasonable for the licensing expressed in `Cargo.toml` files to cover the code within the crate only, ignoring it's dependencies. So it's fine for the binary crate to specify just `MIT`. After all the code from the dependencies is not being directly distributed in source form, just referenced as a dependency. Although it is far from certain that this is the correct way to use the `license` cargo config field. Many projects are doing just that though. 2. Use and distribution of compiled binaries however, is a different matter. These cannot be used or distributed under only MIT licensing. They must be used and distributed under at least `Apache-2.0` only, or combined `MIT AND Apache-2.0`. The full list of dependencies must be checked for both compatibility and to ensure this covers everything. Some of the text in the main repo `README.md` is a little problematic with regards to the seconds point. The text under the "License" heading ("Everything in this repository is licensed under the MIT license.") may be a little misleading, especially combined with the "Quick start" portion giving installation instructions (even though technically does not involve distribution of pre-compiled code). It may be important to clarify in this text that although the code actually within the repo is MIT licensed, the resulting binaries produced are not simply MIT licensed.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#344

No description provided.

Rows
Columns