Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 694412 - app-crypt/nitrocli: Missing LICENSE for bundled crates
Summary: app-crypt/nitrocli: Missing LICENSE for bundled crates
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: deso
URL:
Whiteboard:
Keywords: PullRequest
Depends on:
Blocks: 694790
  Show dependency tree
 
Reported: 2019-09-15 06:16 UTC by Michał Górny
Modified: 2019-11-07 05:42 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-15 06:16:30 UTC
FWICS, the package is bundling a bunch of crates with licenses:
- || ( MIT Apache-2.0 )
- || ( MIT Unlicense )
- Unicode
- ISC
- LGPL-3
- BSD
- MIT

However, they are not listed in LICENSE.
Comment 1 deso 2019-09-15 16:25:04 UTC
Just because its source code ships with a snapshot of its dependencies, how is it different from any other Cargo managed project which pulls in all various dependencies at build time?

Consider sys-apps/fd which has LICENSE="|| ( MIT Apache-2.0 )" [0] and fuchsia-cprng, a dependency, is licensed as "non-standard" only. Why does it not appear in the list?

In general, I am not going to claim that my software is released under, say, MIT/BSD/Apache and so I am not willing to put that into this field unless it is clearly specified somewhere that this field does *not* represent the license the software is released under but an accumulation of the licenses of the packages it pulls in (and in any case, shouldn't that be something that the package manager or other software should take care of and not be a manual process?).

If you take a look at this thread on the Gentoo forums [1] you'll see that this can exactly be the kind of inference that people make.

I haven't found a document stating what *exactly* LICENSE represents. The thing coming closest is the handbook [2] which has the following to say:

> The LICENSE variable in an ebuild is only a guideline for Gentoo developers and users. It is not a legal statement, and there is no guarantee that it will reflect reality. So don't rely on it, but check the package itself in depth, including all files that you use.

As per this statement, my license specification is fine.

[0] https://github.com/gentoo/gentoo/blob/5a214ff859767cc8a961bb5719930ac42c564acd/sys-apps/fd/fd-7.3.0.ebuild#L73
[1] https://forums.gentoo.org/viewtopic-p-8133366.html
[2] https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage#Licenses
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-11-03 20:00:04 UTC
Ping.
Comment 3 deso 2019-11-04 01:46:45 UTC
Is there any chance I could get a response to the questions I raised and concerns I expressed?
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-11-04 07:34:47 UTC
(In reply to deso from comment #1)
> Just because its source code ships with a snapshot of its dependencies, how
> is it different from any other Cargo managed project which pulls in all
> various dependencies at build time?

It's not.

> Consider sys-apps/fd which has LICENSE="|| ( MIT Apache-2.0 )" [0] and
> fuchsia-cprng, a dependency, is licensed as "non-standard" only. Why does it
> not appear in the list?

It does.  Bug #694444.

> In general, I am not going to claim that my software is released under, say,
> MIT/BSD/Apache and so I am not willing to put that into this field unless it
> is clearly specified somewhere that this field does *not* represent the
> license the software is released under but an accumulation of the licenses
> of the packages it pulls in (and in any case, shouldn't that be something
> that the package manager or other software should take care of and not be a
> manual process?).

It is.  https://devmanual.gentoo.org/general-concepts/licenses/index.html

> If you take a look at this thread on the Gentoo forums [1] you'll see that
> this can exactly be the kind of inference that people make.

Then it's a bug in documentation/tooling.  The syntax and policy are well-defined.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-11-04 07:35:15 UTC
Also I'm sorry for not answering earlier, your comment got lost in huge bugspam due to filing those bugs.
Comment 6 deso 2019-11-05 06:34:10 UTC
(In reply to Michał Górny from comment #4)
> > In general, I am not going to claim that my software is released under, say,
> > MIT/BSD/Apache and so I am not willing to put that into this field unless it
> > is clearly specified somewhere that this field does *not* represent the
> > license the software is released under but an accumulation of the licenses
> > of the packages it pulls in (and in any case, shouldn't that be something
> > that the package manager or other software should take care of and not be a
> > manual process?).
> 
> It is.  https://devmanual.gentoo.org/general-concepts/licenses/index.html

Thanks!

You mentioned the following list of licenses:
- || ( MIT Apache-2.0 )
- || ( MIT Unlicense )
- Unicode
- ISC
- LGPL-3
- BSD
- MIT

Can you please shed some light as to how it came into being?

My compilation yields

argparse: MIT
base32: MIT || APACHE 2.0
cc: MIT || APACHE 2.0
lazy-static: MIT || APACHE 2.0
libc: MIT || APACHE 2.0
nitrokey: MIT
nitrokey-sys: LGPL-3

I don't see anything else used during compilation. I suspect you used all dependencies from the CRATES variable, but that includes dev-only ones, which don't make their way into the binary installed here.

I'd also like to request guidance on how to compile that list into an actual LICENSE specification. What is correct:

> LICENSE = "GPL-3+ LGPL-3 MIT Apache-2.0"
or
> LICENSE = "GPL-3+ LGPL-3 MIT || ( MIT Apache-2.0 )"
(or something else)? This is seemingly underspecified in the document you provided. Or I am missing something.
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-11-05 13:11:17 UTC
(In reply to deso from comment #6)
> (In reply to Michał Górny from comment #4)
> > > In general, I am not going to claim that my software is released under, say,
> > > MIT/BSD/Apache and so I am not willing to put that into this field unless it
> > > is clearly specified somewhere that this field does *not* represent the
> > > license the software is released under but an accumulation of the licenses
> > > of the packages it pulls in (and in any case, shouldn't that be something
> > > that the package manager or other software should take care of and not be a
> > > manual process?).
> > 
> > It is.  https://devmanual.gentoo.org/general-concepts/licenses/index.html
> 
> Thanks!
> 
> You mentioned the following list of licenses:
> - || ( MIT Apache-2.0 )
> - || ( MIT Unlicense )
> - Unicode
> - ISC
> - LGPL-3
> - BSD
> - MIT
> 
> Can you please shed some light as to how it came into being?

The command is on the tracker bug.

> 
> My compilation yields
> 
> argparse: MIT
> base32: MIT || APACHE 2.0
> cc: MIT || APACHE 2.0
> lazy-static: MIT || APACHE 2.0
> libc: MIT || APACHE 2.0
> nitrokey: MIT
> nitrokey-sys: LGPL-3
> 
> I don't see anything else used during compilation. I suspect you used all
> dependencies from the CRATES variable, but that includes dev-only ones,
> which don't make their way into the binary installed here.

Yes.  I've erred on the side of caution, to say.  Though I'm a bit surprised that that many crates are needed only at build time.

> I'd also like to request guidance on how to compile that list into an actual
> LICENSE specification. What is correct:
> 
> > LICENSE = "GPL-3+ LGPL-3 MIT Apache-2.0"
> or
> > LICENSE = "GPL-3+ LGPL-3 MIT || ( MIT Apache-2.0 )"
> (or something else)? This is seemingly underspecified in the document you
> provided. Or I am missing something.

Because both are technically fine.  I'd personally recommend the latter as it gives the user clearer image of what's inside, though the former is also technically correct.
Comment 8 Larry the Git Cow gentoo-dev 2019-11-07 05:42:43 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6b0bd179f634839ba872980c4c84d26e1f2dc7f3

commit 6b0bd179f634839ba872980c4c84d26e1f2dc7f3
Author:     Daniel Mueller <deso@posteo.net>
AuthorDate: 2019-11-06 02:06:01 +0000
Commit:     Joonas Niilola <juippis@gentoo.org>
CommitDate: 2019-11-07 05:42:31 +0000

    app-crypt/nitrocli: Adjust LICENSE for 0.2.4 ebuild
    
    This change adjusts the value of LICENSE to include the licenses of all
    crates that find their way into the final installed binary.
    
    Closes: https://bugs.gentoo.org/694412
    Signed-off-by: Daniel Müller <deso@posteo.net>
    Closes: https://github.com/gentoo/gentoo/pull/13564
    Signed-off-by: Joonas Niilola <juippis@gentoo.org>

 app-crypt/nitrocli/nitrocli-0.2.4.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)