From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-project+bounces-8991-garchives=archives.gentoo.org@lists.gentoo.org>
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 C2CDC138334
for <garchives@archives.gentoo.org>; Thu, 4 Jul 2019 20:33:22 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 8DEF8E0844;
Thu, 4 Jul 2019 20:33:21 +0000 (UTC)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33])
(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 650D4E0843
for <gentoo-project@lists.gentoo.org>; Thu, 4 Jul 2019 20:33:21 +0000 (UTC)
Received: by mail-io1-xd33.google.com with SMTP id u19so14893282ior.9
for <gentoo-project@lists.gentoo.org>; Thu, 04 Jul 2019 13:33:21 -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=KOs8OGVXnG+8m5jAOwslAaob4tqn8hAfY1zTpck4YXY=;
b=dpdjodk0zFxPYO1U/z0lDTH4DJJwSFvtiBr/XHKVZnQtcO7/X9bB7jVi6s/RVHNE+l
y+cWPp7l3f4ZDCmIEodEbk5nO16N42XeWoUKE36AHql8owWqy1DjGKzOgWEViz7lrZZW
rmEyQcBOuuxUluUAcqXc3wSIWSulxx7r67aXN0E1dHwgN6uTskpPjQv3ChvVUUbRW61Q
u0es8sZwHRxjr8EzXqWD8nk9/QuQdmhSpTA9TEtKk1x/MnZO60Xx9f599ACbQIV29UGc
tlhtpueoP0RwFCq1EM3jXckn9NYkaTUgyqjUtXx2q+QciphtOMtiVO+4ptG4ehfp4voz
vB3A==
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=KOs8OGVXnG+8m5jAOwslAaob4tqn8hAfY1zTpck4YXY=;
b=PNqZ+0KPdTkalDzQBU94NGPslBlbV4RSwsMB7Bm6HLOttvmo/Ey+oRdZEll8EF7/1H
EgYF1mQPBGs16XOplUVO0D7mvNbe4OMSGe0tq9Z7P259FshoAgu3FnL4bRRWema36X/g
viB9JhrVulebv35xhS3+r0HTOeqrFBwBRsZWB0CAXbuBWSxa1DMrtw/1wuMbJqDMgZnU
ITac0UOUdl202Cg6ujUlwXhC7VTYnx+ncNPYirMPdNEe0bvVAHq8lNnUVS0HrhHTK2tt
Z/RUvgc+sdjP/bwMGQrPo4s0ZCDK8JlexOIUJZdiUlyNmuEfCST9HdxdRQwkAjZHZt2n
1SpQ==
X-Gm-Message-State: APjAAAV8xnoVeiER7ysNAFZCYUncH0PSrfi6su4uVGN65zcQu97r2sBQ
VmkJzwI/CYDg83wjYgZoK6fukQ2/ZqrRa1TrHH84aqiCHOoR2w==
X-Google-Smtp-Source: APXvYqzgr/kJBfMhD0jybCpDHuhA+GKy67ZqTUdaqAeUsdA8YGLUlB2G241bjPHbeZErxTKeVzvH3e/o+YHHy35tNF8=
X-Received: by 2002:a6b:7017:: with SMTP id l23mr226583ioc.159.1562272400197;
Thu, 04 Jul 2019 13:33:20 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
Reply-To: gentoo-project@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
References: <20190615124220.fcf0c08b22481d5bc6c2dbe0@gentoo.org>
<robbat2-20190704T020554-669193988Z@orbis-terrarum.net> <511fe4ea-05c6-a871-cc00-360cff7ac3ff@gentoo.org>
In-Reply-To: <511fe4ea-05c6-a871-cc00-360cff7ac3ff@gentoo.org>
From: Alec Warner <antarus@gentoo.org>
Date: Thu, 4 Jul 2019 13:33:09 -0700
Message-ID: <CAAr7Pr9_V9gd2Jt0vQgEJZ6CQWLi42+Zm4thb8ApNB8cv+qQ4g@mail.gmail.com>
Subject: Re: [gentoo-project] Questions for Gentoo Council nominees: Council
demands on maintainers & council legal liability
To: gentoo-project <gentoo-project@lists.gentoo.org>
Cc: "Robin H. Johnson" <robbat2@gentoo.org>
Content-Type: multipart/alternative; boundary="00000000000074e217058ce0e3eb"
X-Archives-Salt: 48bc23fe-23d6-41be-ae15-6c08059145a8
X-Archives-Hash: 0d7502a9a8db3a9ffba0225084ff9198
--00000000000074e217058ce0e3eb
Content-Type: text/plain; charset="UTF-8"
On Thu, Jul 4, 2019 at 1:05 AM Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 7/4/19 4:14 AM, Robin H. Johnson wrote:
> > I realize that there is only a short period left in the election, but
> > I've been busy with IRL issues, and mgorny's trustee manifesto [1]
> ascribed
> > something to the Council members that concerned me; there's one
> > additional good question for the Council that I'll close with.
> >
> > 1. Points 1a&1c of mgorny's manifesto imply that the council can
> > unilaterally prevent support of any given package in Gentoo, and
> > basically remove the package from the distribution.
> >
> > This is despite any developers that may wish to support the package.
> >
> > What's your opinion of the council using this offensively against
> > packages? As a hypothetical, say systemd-ng comes about, with an even
> > worse opinionated choices than those presently in systemd. Should the
> > council be able to force support for openrc & systemd stop?
>
> Its definitely within the purview of the council to do it, but in most
> cases Gentoo is about flexibility so you don't want to. There are
> scenarios where you would have to consider it, though, e.g large impacts
> on others work (project out of scope), security issues , etc.
>
Clearly someone in Gentoo has this power, because in the end we choose who
has access to the means of production (nominally the mailing lists, irc,
bugzilla, git, etc..)
There is a question of centrality (should it be solely the council) vs some
other facility. If you literally read the GLEP[0] it makes it pretty clear
that:
1) The council is responsible for global issues.
2) Project leads still have some responsibility to their specific area.
3) Disciplinary actions can be appealed to the council.
If you were an originalist[2] and the council decided that
"mail-client/novell-groupwise-client"[1] was not suitable for the tree; I
wouldn't really expect the Council to have any particular say over this.
Not that they could not formulate an argument, but that literally their
purview does not extend here. This is explicitly called out in the GLEP
itself:
"Any dev may create a new project just by creating a new project page on
the wiki.gentoo.org (see [2]) and sending a Request For Comments (RFC)
e-mail to gentoo-dev. Note that this GLEP does not provide for a way for
the community at large to block a new project, even if the comments are
wholly negative."
I struggle to reconcile this text from GLEP 39 with the operational policy
that the "Council can do whatever they want and they are the ultimately
authority on ::gentoo."
Ultimately I think this is part of the point that Robin is raising and is a
key goal / right of Gentoo; because I do not think the council's purview
extends this far.
Note that (1) above is pretty vague, which is where i think all the leeway
comes into place in terms of the power the community lets the council have
(regardless of the actual text of the GLEP). It reminds me of the Commerce
Clause[3] in the US where the literal text of the amendment gives the
government broad regulatory authority. In the case of Gentoo, the Council's
authority extends only so far as the community tolerates them classifying
problems as 'global' (which is their clear purview) vs a local problem,
where its clearly the domain of a project lead or individual developer. I
don't expect a clearly written policy to cover all the ground here (because
there is too much ground to cover.)
-A
[0] https://www.gentoo.org/glep/glep-0039.html
[1] I randomly picked this package as an example.
[2] For the record, I am not, but I can certainly see how others might be.
[3] https://en.wikipedia.org/wiki/Commerce_Clause
> >
> > 2. As an additional point, can you try to give your version of a simple
> > statement on the legal liabilities that the Council as a whole, and
> > the Council members as individuals, have for their actions?
> >
>
> Council is no legal entity, so there is no as a whole, the individual
> legal liability is somewhat limited as there is no fiduciary duty etc
> arising due to this; which means no negligence claims etc.. So basically
> you're left with whatever else you can be sued for as an individual, but
> you're in a more profiled position so it is possibly more likely that
> you will face it by some angry internet people...
>
> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>
>
--00000000000074e217058ce0e3eb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jul 4, 2019 at 1:05 AM Kristian F=
iskerstrand <<a href=3D"mailto:k_f@gentoo.org">k_f@gentoo.org</a>> wr=
ote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">On 7/4/19 4:14 AM, Robin H. Johnson wrote:<br>
> I realize that there is only a short period left in the election, but<=
br>
> I've been busy with IRL issues, and mgorny's trustee manifesto=
[1] ascribed<br>
> something to the Council members that concerned me; there's one<br=
>
> additional good question for the Council that I'll close with.<br>
> <br>
> 1. Points 1a&1c of mgorny's manifesto imply that the council c=
an<br>
>=C2=A0 =C2=A0 unilaterally prevent support of any given package in Gent=
oo, and<br>
>=C2=A0 =C2=A0 basically remove the package from the distribution.<br>
> <br>
>=C2=A0 =C2=A0 This is despite any developers that may wish to support t=
he package.<br>
> <br>
>=C2=A0 =C2=A0 What's your opinion of the council using this offensi=
vely against<br>
>=C2=A0 =C2=A0 packages? As a hypothetical, say systemd-ng comes about, =
with an even<br>
>=C2=A0 =C2=A0 worse opinionated choices than those presently in systemd=
. Should the<br>
>=C2=A0 =C2=A0 council be able to force support for openrc & systemd=
stop?<br>
<br>
Its definitely within the purview of the council to do it, but in most<br>
cases Gentoo is about flexibility so you don't want to. There are<br>
scenarios where you would have to consider it, though, e.g large impacts<br=
>
on others work (project out of scope), security issues , etc.<br></blockquo=
te><div><br></div><div>Clearly someone in Gentoo has this power, because in=
the end we choose who has access to the means of production (nominally the=
mailing lists, irc, bugzilla, git, etc..)</div><div>There is a question of=
centrality (should it be solely the council) vs some other facility. If yo=
u literally read the GLEP[0] it makes it pretty clear that:</div><div><br><=
/div><div>1) The council is responsible for global issues.</div><div>2) Pro=
ject leads still have some responsibility to their specific area.</div><div=
>3) Disciplinary actions can be appealed to the council.</div><div><br></di=
v><div>If you were an originalist[2] and the council decided that "mai=
l-client/novell-groupwise-client"[1] was not suitable for the tree; I =
wouldn't really expect the Council to have any particular say over this=
. Not that they could not formulate an argument, but that literally their p=
urview does not extend here. This is explicitly called out in the GLEP itse=
lf:</div><div><br></div><div>"Any dev may create a new project just by=
creating a new project page on the <a href=3D"http://wiki.gentoo.org">wiki=
.gentoo.org</a> (see [2]) and sending a Request For Comments (RFC) e-mail t=
o gentoo-dev. Note that this GLEP does not provide for a way for the commun=
ity at large to block a new project, even if the comments are wholly negati=
ve."</div><div><br></div><div>I struggle to reconcile this text from G=
LEP 39 with the operational policy that the "Council can do whatever t=
hey want and they are the ultimately authority on ::gentoo."</div><div=
><br></div><div>Ultimately I think this is part of the point that Robin is =
raising and is a key goal / right of Gentoo; because I do not think the cou=
ncil's purview extends this far.</div><div><br></div><div>Note that (1)=
above is pretty vague, which is where i think all the leeway comes into pl=
ace in terms of the power the community lets the council have (regardless o=
f the actual text of the GLEP). It reminds me of the Commerce Clause[3] in =
the US where the literal text of the amendment gives the government broad r=
egulatory authority. In the case of Gentoo, the Council's authority ext=
ends only so far as the community tolerates them classifying problems as &#=
39;global' (which is their clear purview) vs a local problem, where its=
clearly the domain of a project lead or individual developer. I don't =
expect a clearly written policy to cover all the ground here (because there=
is too much ground to cover.)</div><div><br></div><div>-A</div><div><br></=
div><div>[0]=C2=A0<a href=3D"https://www.gentoo.org/glep/glep-0039.html">ht=
tps://www.gentoo.org/glep/glep-0039.html</a></div><div>[1] I randomly picke=
d this package as an example.</div><div>[2] For the record, I am not, but I=
can certainly see how others might be.</div><div>[3]=C2=A0<a href=3D"https=
://en.wikipedia.org/wiki/Commerce_Clause">https://en.wikipedia.org/wiki/Com=
merce_Clause</a></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
> <br>
> 2. As an additional point, can you try to give your version of a simpl=
e<br>
>=C2=A0 =C2=A0 statement on the legal liabilities that the Council as a =
whole, and<br>
>=C2=A0 =C2=A0 the Council members as individuals, have for their action=
s?<br>
> <br>
<br>
Council is no legal entity, so there is no as a whole, the individual<br>
legal liability is somewhat limited as there is no fiduciary duty etc<br>
arising due to this; which means no negligence claims etc.. So basically<br=
>
you're left with whatever else you can be sued for as an individual, bu=
t<br>
you're in a more profiled position so it is possibly more likely that<b=
r>
you will face it by some angry internet people...<br></blockquote><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><br>
-- <br>
Kristian Fiskerstrand<br>
OpenPGP keyblock reachable at hkp://<a href=3D"http://pool.sks-keyservers.n=
et" rel=3D"noreferrer" target=3D"_blank">pool.sks-keyservers.net</a><br>
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3<br>
<br>
</blockquote></div></div>
--00000000000074e217058ce0e3eb--