Opening this tracker mostly as a single point of reference for how to fix missing LICENSE entries. I've been able to find most of the missing licenses via the following grep: $ find -name 'Cargo.toml' -exec grep -h license {} + | sort -u This lists all unique license values in crate descriptions. Note that some of them use '/', some 'OR' and some 'AND', so please make sure not to get this confused. You will probably also notice license-file entries which you have to find manually and read the referenced file to learn the license.
A generic note on license compatibility: if the packages vendors any dependency whose license is LGPL and GPL (and does not include explicit linking exception on top), then the package must be LGPL/GPL as well. This is something that needs to be reported upstream. Feel free to ping me for help.
I've added cargo-license package to help checking out licenses for proxy-maint rust packages. Simple steps to use it: emerge -1av cargo-license cd /tmp equery m rust-package <open github etc> <git clone the _released_ tag> cd rust-package cargo-license . Output is something along of: ---------- Apache-2.0 AND BSD-2-Clause/MIT (1): crossbeam-channel Apache-2.0 OR BSL-1.0 (1): ryu Apache-2.0/MIT (23): bytecount, winapi-i686-pc-windows-gnu, bitflags, crossbeam-utils, cfg-if, base64, itoa, pkg-config, encoding_rs, cc, num_cpus, glob, unicode-width, memmap, winapi, winapi-x86_64-pc-windows-gnu, regex-syntax, jemalloc-sys, jemallocator, regex, lazy_static, thread_local, fnv MIT (5): textwrap, clap, fs_extra, strsim, atty MIT OR Apache-2.0 (11): syn, serde_derive, bstr, proc-macro2, encoding_rs_io, serde, serde_json, libc, log, quote, unicode-xid MIT/Unlicense (17): regex-automata, grep-printer, aho-corasick, pcre2, grep, walkdir, grep-cli, memchr, winapi-util, grep-searcher, ignore, same-file, grep-regex, globset, grep-matcher, grep-pcre2, pcre2-sys Unlicense OR MIT (4): wincolor, termcolor, byteorder, ripgrep ---------- FYI, the "/" is a deprecated separator, and now they use "OR". Both present in the example above. Apache-2.0/MIT Apache-2.0 OR MIT
Since most of these ebuilds were created by the cargo-ebuild tool, I'd recommend that folks open a bug for cargo-ebuild when they discover issues like this. Future versions will likely improve the license handling.
for future reference, static linking with LGPL is usually fine for typical rust crates but warning about GPL still stands tho and I found one package with wrong license. https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic) For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3): (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. (2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides. https://copyleft.org/guide/comprehensive-gpl-guidech12.html#x15-11500011.5 Taken all together, LGPLv3 §4’s primary implications for redistributors are two-fold, as follows: If you create a program that links through a shared library mechanism to a work that is separately distributed under LGPLv3, then you can distribute the resultant program under a license of your choice and you need not convey the LGPLv3’d work’s source code. If you distribute the library along with your program, or are the separate distributor of the work in another context or as another product, you must distribute its corresponding source under the terms of LGPLv3 or GPLv3-or-later. If you choose to statically link or otherwise combine your program with an LGPLv3’d work via mechanisms other than a shared library, you may choose your own license for the work provided the license terms limitations for user modification, reverse engineering and debugging are met, and given that the LGPL’d components are still governed by LGPL’s terms. You must offer or provide CCS for the LGPL’d components. The source code material provided must be sufficient to regenerate the combined work with a user-modified version of the LGPL’d components.
I've created cargo-ebuild 0.3.0 which uses a different Cargo.toml parser which can provide license information. This license information is ANDed together and not necessarily ORed correctly but this is a step forward to solve this. Unfortunately Cargo and cargo-ebuild both use SPDX short identifiers to identify licenses. But Gentoo does not do so. I've created https://bugs.gentoo.org/706472 so have Gentoo fix this.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd1a6dc9278a5d0f5ce4d85f2e6451ed0dceb8e7 commit fd1a6dc9278a5d0f5ce4d85f2e6451ed0dceb8e7 Author: Doug Goldstein <cardoe@gentoo.org> AuthorDate: 2020-01-26 16:14:16 +0000 Commit: Doug Goldstein <cardoe@gentoo.org> CommitDate: 2020-01-26 16:18:15 +0000 dev-util/cargo-ebuild: version bump to 0.3.0 Switched to using cargo_metadata from cargo for gathering data about the crate. This has some disadvantages as some data is lost but it has the advantage of letting us gather license information which was more important for folks. Bug: https://bugs.gentoo.org/694790 Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Doug Goldstein <cardoe@gentoo.org> dev-util/cargo-ebuild/Manifest | 5 ++ dev-util/cargo-ebuild/cargo-ebuild-0.3.0.ebuild | 62 +++++++++++++++++++++++++ 2 files changed, 67 insertions(+)
I fixed everything except bingrep https://bugs.gentoo.org/show_bug.cgi?id=694422, which legally should be distributed under GPL-3. we do list GPL-3 as a license of the ebuild to I think we are fine distributing it like this with all licenses listed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=09efbf4ed38ffb300545cb132cd313d4943c8010 commit 09efbf4ed38ffb300545cb132cd313d4943c8010 Author: Konstantin Podshumok <kpp.live+signed@gmail.com> AuthorDate: 2020-04-25 01:35:05 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-05-12 13:57:08 +0000 dev-go/licenseclassifier: new ebuild I find this tool very helpful for managing LICENSE in different ebuilds. Just run identify_license on any file - just a source code or COPYING/LICENSE file. It also can be built against licenses in /var/db/repos/gentoo/licenses, but this is not yet implemented in this commit. Bug: https://bugs.gentoo.org/694792 Bug: https://bugs.gentoo.org/694790 Signed-off-by: Konstantin Podshumok <kpp.live+signed@gmail.com> Signed-off-by: Joonas Niilola <juippis@gentoo.org> dev-go/licenseclassifier/Manifest | 12 ++++ .../licenseclassifier-0_pre20200402.ebuild | 84 ++++++++++++++++++++++ dev-go/licenseclassifier/metadata.xml | 22 ++++++ 3 files changed, 118 insertions(+)
