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 |
> |