From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D0250138334 for ; Thu, 12 Sep 2019 16:47:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A6B61E09B8; Thu, 12 Sep 2019 16:47:10 +0000 (UTC) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6264CE0963 for ; Thu, 12 Sep 2019 16:47:09 +0000 (UTC) Received: by mail-io1-xd44.google.com with SMTP id b136so56404815iof.3 for ; Thu, 12 Sep 2019 09:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T05V+guDWCreOjFOYm8im8aW1C20+Okmfqb3bibfmRU=; b=MghDm84Dx7OjuvKcCwR9ie0IJg5cB0Gdv/dHS3HX3ilFoMDHlDOSiZPWrIaTuFoRWw /BhlHKLCohDTboOfjHVA/UVgzvfTnMcLgJSEihWQMmzF0LtLtqbP4g5M/DSrC9R3AnDf sfc8yRfhh9w02Mj52xlrcWwp0KN8B6IJ80O81K0h3v8l6AMxSNH2mg33ChKuhXCYGeED lIxRdTprvCQ6AvgKWnfo4RGC4xfsFmHLqjNh1TOsr/mVmx7GOVFVs9lYy3+NzRfCmSY9 3IPZi8wvqKTmAZf0BnlO9iYqK0wXAVtwYxzUS+982OCc9Orpf2X28qvsd8AIazwaMbQI aKPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T05V+guDWCreOjFOYm8im8aW1C20+Okmfqb3bibfmRU=; b=IDUxgYxFF3lNpSc99b//CoVXIXcXpV/OTMxNsMX9gSE7K5R9xmmgz5092NGkqfq15K RL6sqJeL9DLex5XjxH0KRKRX+DG381JnLwc8Q35i/buhReplUBz7fv4u3g0/z7ytSSkL APe3e5eINux9NTP51aEfavqd4umo2Zj7uEWIbJZmcH1eAuqhbQ2/j+VmXnp/JRYqgzpY yQ7o/Vb50Tx/X6Jfsi8pHDmwJtldA/DOGk5YGNqpr/IiNa34OIwOUOlkQ37rFnKeR555 QpYANguuKxh9D/KRRi97393zJ3TsMSHddRjsZowdv1ZprFfPviMdVi114q/BAJ5lx1qv 9OLQ== X-Gm-Message-State: APjAAAW5BKDJeDfRzqH9fybxmcssRS3cxcdHEki7VDjY2Yrfy/u4rU2a K4saf+hjEVsYunuSUx9MHsZPL1VVS3u7si8pzhhOIi8z X-Google-Smtp-Source: APXvYqwK4JH8/Eoob3gpKyjvRbKtkLOwmCsY6XAB2DNdCF/V13JIeVsWPCG9zRU76zRcg6qq+9JMdWJewzi4ZR2zicU= X-Received: by 2002:a02:7009:: with SMTP id f9mr44792491jac.81.1568306828332; Thu, 12 Sep 2019 09:47:08 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20190911172128.18885-1-williamh@gentoo.org> <20190911172128.18885-4-williamh@gentoo.org> <20190911234815.GA21591@whubbs1.dev.av1.gaikai.org> <20190912154634.GB23846@whubbs1.dev.av1.gaikai.org> In-Reply-To: <20190912154634.GB23846@whubbs1.dev.av1.gaikai.org> From: Alec Warner Date: Thu, 12 Sep 2019 09:46:57 -0700 Message-ID: Subject: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass To: William Hubbs Cc: Gentoo Dev , Michael Orlitzky , Ulrich Mueller Content-Type: multipart/alternative; boundary="00000000000066eea205925de321" X-Archives-Salt: 830f71f3-625f-4cc9-acdc-c5f676291f27 X-Archives-Hash: 0965b0a25b5716f504f924767fb3b156 --00000000000066eea205925de321 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 12, 2019 at 8:46 AM William Hubbs wrote: > On Wed, Sep 11, 2019 at 05:05:50PM -0700, Alec Warner wrote: > > On Wed, Sep 11, 2019 at 4:48 PM William Hubbs > wrote: > > > > > On Wed, Sep 11, 2019 at 04:34:27PM -0700, Alec Warner wrote: > > > > On Wed, Sep 11, 2019 at 10:39 AM Michael Orlitzky > > > wrote: > > > > > > > > > On 9/11/19 1:21 PM, William Hubbs wrote: > > > > > > +++ b/dev-vcs/hub/hub-2.12.3.ebuild > > > > > > ... > > > > > > > > > > > > LICENSE="MIT" > > > > > > > > > > This license is wrong, as it's pretty much guaranteed to be every > time > > > > > you commit one of these packages. I find it pretty troubling that > one > > > > > corporation is able to force this stuff through even though it's a > > > > > security and legal hazard for everyone else. > > > > > > > > > > > > > How is it wrong? > > > > > > > > https://github.com/github/hub/blob/master/LICENSE > > > > > > The argument is that because of the vendoring, LICENSE= needs to list > > > all licenses for the vendored dependencies that are different from MIT > > > as well. > > > > > > > I see, I tend to believe that argument in that case. > > > > > > > > > > Personally I don't have a comment about this, but that's what is being > > > pushed for. I'll let you guys debate this but it isn't really relevant > > > to the eclass. ;-) > > > > > > > I think it's difficult to put instructions in the eclass like: > > > > +# $ cd /my/clone/of/upstream > > +# $ git checkout > > +# $ go mod vendor > > +# $ tar cvf project-version-vendor.tar.gz vendor > > > > And then not mention this fairly easy trap (it's so easy to fall into you > > did it twice.) > > In the case of hub, I didn't make a vendor tarball because upstream does > the vendoring, so I don't see how these two things are related. > > In other words, the way I see this is a tree-wide issue. LICENSE= for > any package should list every license for every package it links to or > uses. > So for packages managed by portage this is true by recursion. A -> B -> C A_LICENSE: [GPL-2], B_LICENSE: [MIT], C_LICENSE: [BSD] So to install A we have to install [A,B,C] and accept licenses [GPL-2, MIT, BSD]. Presumably if ACCEPT_LICENSE was set to "-*" you would be forced to actually accept each of these individually; but the default is @OSI_APPROVED or similar, which contains many common OSS licenses. If you bundle a bunch of stuff in package C and don't bother to set the LICENSE variable, this is no longer true; I suspect this is why people are complaining. I don't think we are asking you to do extra work. Current practice is to add dependencies as other packages (with their own LICENSE variable.) Your scheme doesn't do this (saving you work), it bundles the dependencies instead. This means to be equivalent to existing practice the LICENSE should contain the licenses for the bundles as well. -A > William > > --00000000000066eea205925de321 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 12, 2019 at 8:46 AM William H= ubbs <williamh@gentoo.org>= wrote:
On Wed, Sep 11, 2019 at 05:05:50PM -0700, Alec Warner wr= ote:
> On Wed, Sep 11, 2019 at 4:48 PM William Hubbs <williamh@gentoo.org> wrote:
>
> > On Wed, Sep 11, 2019 at 04:34:27PM -0700, Alec Warner wrote:
> > > On Wed, Sep 11, 2019 at 10:39 AM Michael Orlitzky <mjo@gentoo.org>
> > wrote:
> > >
> > > > On 9/11/19 1:21 PM, William Hubbs wrote:
> > > > > +++ b/dev-vcs/hub/hub-2.12.3.ebuild
> > > > > ...
> > > > >
> > > > > LICENSE=3D"MIT"
> > > >
> > > > This license is wrong, as it's pretty much guarante= ed to be every time
> > > > you commit one of these packages. I find it pretty trou= bling that one
> > > > corporation is able to force this stuff through even th= ough it's a
> > > > security and legal hazard for everyone else.
> > > >
> > >
> > > How is it wrong?
> > >
> > > https://github.com/github/hub/blob/m= aster/LICENSE
> >
> > The argument is that because of the vendoring, LICENSE=3D needs t= o list
> > all licenses for the vendored dependencies that are different fro= m MIT
> > as well.
> >
>
> I see, I tend to believe that argument in that case.
>
>
> >
> > Personally I don't have a comment about this, but that's = what is being
> > pushed for. I'll let you guys debate this but it isn't re= ally relevant
> > to the eclass. ;-)
> >
>
> I think it's difficult to put instructions in the eclass like:
>
> +# $ cd /my/clone/of/upstream
> +# $ git checkout <release>
> +# $ go mod vendor
> +# $ tar cvf project-version-vendor.tar.gz vendor
>
> And then not mention this fairly easy trap (it's so easy to fall i= nto you
> did it twice.)

In the case of hub, I didn't make a vendor tarball because upstream doe= s
the vendoring, so I don't see how these two things are related.

In other words, the way I see this is a tree-wide issue. LICENSE=3D for
any package should list every license for every package it links to or
uses.

So for packages managed by portag= e this is true by recursion.

A -> B -> C
A_LICENSE: [GPL-2], B_LICENSE: [MIT], C_LICENSE: [BSD]
So to install A we have to install [A,B,C] and accept licenses = [GPL-2, MIT, BSD]. Presumably if ACCEPT_LICENSE was set to "-*" y= ou would be forced to actually accept each of these individually; but the d= efault is=C2=A0@OSI_APPROVED or similar, which contains many common OSS lic= enses.
=C2=A0
If you bundle a bunch of stuff in package= C and don't bother to set the LICENSE variable, this is no longer true= ; I suspect this is why people are complaining.
I don't think= we are asking you to do extra work. Current practice is to add dependencie= s as other packages (with their own LICENSE variable.) Your scheme doesn= 9;t do this (saving you work), it bundles the dependencies instead. This me= ans to be equivalent to existing practice the LICENSE should contain the li= censes for the bundles as well.

-A

<= /div>

William

--00000000000066eea205925de321--