Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: William Hubbs <williamh@g.o>
Cc: Gentoo Dev <gentoo-dev@l.g.o>, Michael Orlitzky <mjo@g.o>, Ulrich Mueller <ulm@g.o>
Subject: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
Date: Thu, 12 Sep 2019 16:47:13
Message-Id: CAAr7Pr-jXdAhZCs=bCdTnBDf3iiRwgtD+WCZ7vUcoRhDqTgJKg@mail.gmail.com
In Reply to: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass by William Hubbs
1 On Thu, Sep 12, 2019 at 8:46 AM William Hubbs <williamh@g.o> wrote:
2
3 > On Wed, Sep 11, 2019 at 05:05:50PM -0700, Alec Warner wrote:
4 > > On Wed, Sep 11, 2019 at 4:48 PM William Hubbs <williamh@g.o>
5 > wrote:
6 > >
7 > > > On Wed, Sep 11, 2019 at 04:34:27PM -0700, Alec Warner wrote:
8 > > > > On Wed, Sep 11, 2019 at 10:39 AM Michael Orlitzky <mjo@g.o>
9 > > > wrote:
10 > > > >
11 > > > > > On 9/11/19 1:21 PM, William Hubbs wrote:
12 > > > > > > +++ b/dev-vcs/hub/hub-2.12.3.ebuild
13 > > > > > > ...
14 > > > > > >
15 > > > > > > LICENSE="MIT"
16 > > > > >
17 > > > > > This license is wrong, as it's pretty much guaranteed to be every
18 > time
19 > > > > > you commit one of these packages. I find it pretty troubling that
20 > one
21 > > > > > corporation is able to force this stuff through even though it's a
22 > > > > > security and legal hazard for everyone else.
23 > > > > >
24 > > > >
25 > > > > How is it wrong?
26 > > > >
27 > > > > https://github.com/github/hub/blob/master/LICENSE
28 > > >
29 > > > The argument is that because of the vendoring, LICENSE= needs to list
30 > > > all licenses for the vendored dependencies that are different from MIT
31 > > > as well.
32 > > >
33 > >
34 > > I see, I tend to believe that argument in that case.
35 > >
36 > >
37 > > >
38 > > > Personally I don't have a comment about this, but that's what is being
39 > > > pushed for. I'll let you guys debate this but it isn't really relevant
40 > > > to the eclass. ;-)
41 > > >
42 > >
43 > > I think it's difficult to put instructions in the eclass like:
44 > >
45 > > +# $ cd /my/clone/of/upstream
46 > > +# $ git checkout <release>
47 > > +# $ go mod vendor
48 > > +# $ tar cvf project-version-vendor.tar.gz vendor
49 > >
50 > > And then not mention this fairly easy trap (it's so easy to fall into you
51 > > did it twice.)
52 >
53 > In the case of hub, I didn't make a vendor tarball because upstream does
54 > the vendoring, so I don't see how these two things are related.
55 >
56 > In other words, the way I see this is a tree-wide issue. LICENSE= for
57 > any package should list every license for every package it links to or
58 > uses.
59 >
60
61 So for packages managed by portage this is true by recursion.
62
63 A -> B -> C
64 A_LICENSE: [GPL-2], B_LICENSE: [MIT], C_LICENSE: [BSD]
65
66 So to install A we have to install [A,B,C] and accept licenses [GPL-2, MIT,
67 BSD]. Presumably if ACCEPT_LICENSE was set to "-*" you would be forced to
68 actually accept each of these individually; but the default
69 is @OSI_APPROVED or similar, which contains many common OSS licenses.
70
71 If you bundle a bunch of stuff in package C and don't bother to set the
72 LICENSE variable, this is no longer true; I suspect this is why people are
73 complaining.
74 I don't think we are asking you to do extra work. Current practice is to
75 add dependencies as other packages (with their own LICENSE variable.) Your
76 scheme doesn't do this (saving you work), it bundles the dependencies
77 instead. This means to be equivalent to existing practice the LICENSE
78 should contain the licenses for the bundles as well.
79
80 -A
81
82
83 > William
84 >
85 >