Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 694790 - [TRACKER] Missing LICENSE entries for cargo (rust) crates
Summary: [TRACKER] Missing LICENSE entries for cargo (rust) crates
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords:
Depends on: 694422 706472 694410 694412 694414 694416 694418 694420 694424 694426 694430 694436 694438 694440 694444 694446 694448 694450 694452 694498 699276 699278
Blocks:
  Show dependency tree
 
Reported: 2019-09-18 12:12 UTC by Michał Górny
Modified: 2020-02-18 06:24 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-09-18 12:12:52 UTC
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.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-09-18 12:38:55 UTC
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.
Comment 2 Joonas Niilola gentoo-dev 2019-11-19 05:31:31 UTC
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
Comment 3 Doug Goldstein gentoo-dev 2019-12-26 19:17:38 UTC
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.
Comment 4 Georgy Yakovlev gentoo-dev 2020-01-02 07:44:18 UTC
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.
Comment 5 Doug Goldstein gentoo-dev 2020-01-26 16:07:19 UTC
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.
Comment 6 Larry the Git Cow gentoo-dev 2020-01-26 16:19:20 UTC
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(+)
Comment 7 Georgy Yakovlev gentoo-dev 2020-02-18 06:24:23 UTC
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.