Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 694438

Summary: sys-apps/bat: Missing LICENSE for bundled crates
Product: Gentoo Linux Reporter: Michał Górny <mgorny>
Component: Current packagesAssignee: Georgy Yakovlev <gyakovlev>
Status: RESOLVED FIXED    
Severity: normal CC: licenses
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 694790    

Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-09-15 07:27:02 UTC
FWICS, the package is bundling a bunch of crates with licenses:
- MIT
- || ( MIT Apache-2.0 )
- || ( MIT Unlicense )
- || ( Apache-2.0 Boost-1.0 )
- ISC
- BSD
- BSD-2
- CC0
- zlib
- LGPL-3+

However, they are not listed in LICENSE.

Now, if those things are linked statically with ansi_colours (I presume they are but please confirm), bat needs to be licensed LGPL-3+ as well to avoid license violation.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-11-03 20:00:04 UTC
Ping.
Comment 2 Georgy Yakovlev archtester gentoo-dev 2019-12-31 06:55:12 UTC
ok I have a case here

sys-apps/bat depends on ansi_colours which is LGPL-3+

TLDR explanation of license says that"
Derivatives works (including modifications or anything statically linked to the library) can only be redistributed under LGPL, but applications that use the library don't have to be


addling licenses for consult before pestering upstream.


output of cargo-license
Apache-2.0 (2): line-wrap, clang-sys
Apache-2.0 OR BSL-1.0 (1): ryu
Apache-2.0 OR MIT (85): regex-syntax, encode_unicode, itoa, idna, linked-hash-map, proc-macro2, unicode-normalization, winapi-i686-pc-windows-gnu, content_inspector, libz-sys, cc, thread_local, yaml-rust, error-chain, serde_derive, failure_derive, escargot, vcpkg, libc, remove_dir_all, git2, smallvec, libgit2-sys, glob, serde, predicates-core, url, winapi-x86_64-pc-windows-gnu, cexpr, regex, humantime, lazy_static, dirs, safemem, fxhash, percent-encoding, base64, rust-argon2, rustc-demangle, unicode-xid, crossbeam-utils, shlex, assert_cmd, proc-macro2, bitflags, peeking_take_while, lazycell, arrayvec, flate2, quick-error, unicode-bidi, rand_core, term_size, backtrace, tempdir, winapi, dirs-sys, miniz-sys, unicode-width, cfg-if, autocfg, version_check, bat, rand_core, rand, nodrop, serde_json, predicates-tree, rand_os, pkg-config, syn, backtrace-sys, predicates, unicode-xid, crc32fast, fnv, shell-words, quote, quote, vec_map, syn, env_logger, log, escargot, failure
BSD-2-Clause (2): cloudabi, arrayref
BSD-3-Clause (1): bindgen
BSD-3-Clause AND Zlib (1): adler32
CC0-1.0 (7): encoding-index-simpchinese, encoding_index_tests, encoding-index-singlebyte, encoding-index-japanese, constant_time_eq, encoding-index-tradchinese, encoding-index-korean
ISC (2): libloading, rdrand
LGPL-3.0-or-later (1): ansi_colours
MIT (30): syntect, plist, blake2b_simd, winapi, textwrap, atty, strsim, termios, winapi-build, redox_users, console, onig_sys, kernel32-sys, matches, xml-rs, nom, ansi_term, which, synstructure, ansi_term, miniz_oxide, wild, onig, clicolors-control, treeline, redox_syscall, encoding, bincode, difference, clap
MIT OR Unlicense (8): aho-corasick, same-file, termcolor, walkdir, winapi-util, memchr, wincolor, byteorder
N/A (1): fuchsia-cprng
Comment 3 Georgy Yakovlev archtester gentoo-dev 2019-12-31 06:57:00 UTC
snip from cargo-tree
bat v0.12.1 (/home/ya/Downloads/bat-0.12.1)
├── ansi_colours v1.0.1
│   [build-dependencies]
│   └── cc v1.0.41
├── ansi_term v0.12.1
├── atty v0.2.13
│   └── libc v0.2.62
├── clap v2.33.0
│   ├── ansi_term v0.11.0
│   ├── atty v0.2.13 (*)
│   ├── bitflags v1.1.0
│   ├── strsim v0.8.0
│   ├── term_size v0.3.1
│   │   └── libc v0.2.62 (*)
│   ├── textwrap v0.11.0
│   │   ├── term_size v0.3.1 (*)
│   │   └── unicode-width v0.1.6
│   ├── unicode-width v0.1.6 (*)
│   └── vec_map v0.8.1
├── console v0.8.0
...

so it's a direct dep of bat, not buried deeper into the depgraph
Comment 4 Georgy Yakovlev archtester gentoo-dev 2019-12-31 06:59:05 UTC
https://github.com/sharkdp/bat/issues/792
Comment 5 Larry the Git Cow gentoo-dev 2020-01-02 07:38:56 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2777f84bebe2b4c8d8620de80036620753a0b8fa

commit 2777f84bebe2b4c8d8620de80036620753a0b8fa
Author:     Georgy Yakovlev <gyakovlev@gentoo.org>
AuthorDate: 2020-01-02 07:35:31 +0000
Commit:     Georgy Yakovlev <gyakovlev@gentoo.org>
CommitDate: 2020-01-02 07:38:42 +0000

    sys-apps/bat: bump to 0.12.1
    
    Issue: https://github.com/sharkdp/bat/issues/792
    Closes: https://bugs.gentoo.org/694438
    Package-Manager: Portage-2.3.84, Repoman-2.3.20
    Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>

 sys-apps/bat/Manifest                                 |  5 ++---
 sys-apps/bat/{bat-0.12.0.ebuild => bat-0.12.1.ebuild} | 11 +++++------
 2 files changed, 7 insertions(+), 9 deletions(-)
Comment 6 Georgy Yakovlev archtester gentoo-dev 2020-01-02 07:41:16 UTC
ok upstream provided reasonable explanation, it's ok to distribute under MIT or Apache-2.0 as long as it's free license, see upstream thread comment on github.

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.



feel free to reopen if something is wrong.