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 C2CDC138334 for ; 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 ; Thu, 4 Jul 2019 20:33:21 +0000 (UTC) Received: by mail-io1-xd33.google.com with SMTP id u19so14893282ior.9 for ; 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: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list 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> <511fe4ea-05c6-a871-cc00-360cff7ac3ff@gentoo.org> In-Reply-To: <511fe4ea-05c6-a871-cc00-360cff7ac3ff@gentoo.org> From: Alec Warner Date: Thu, 4 Jul 2019 13:33:09 -0700 Message-ID: Subject: Re: [gentoo-project] Questions for Gentoo Council nominees: Council demands on maintainers & council legal liability To: gentoo-project Cc: "Robin H. Johnson" 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 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
On Thu, Jul 4, 2019 at 1:05 AM Kristian F= iskerstrand <k_f@gentoo.org> wr= ote:
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<= br> > 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 c= an
>=C2=A0 =C2=A0 unilaterally prevent support of any given package in Gent= oo, and
>=C2=A0 =C2=A0 basically remove the package from the distribution.
>
>=C2=A0 =C2=A0 This is despite any developers that may wish to support t= he package.
>
>=C2=A0 =C2=A0 What's your opinion of the council using this offensi= vely against
>=C2=A0 =C2=A0 packages? As a hypothetical, say systemd-ng comes about, = with an even
>=C2=A0 =C2=A0 worse opinionated choices than those presently in systemd= . Should the
>=C2=A0 =C2=A0 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 yo= u literally read the GLEP[0] it makes it pretty clear that:

<= /div>
1) The council is responsible for global issues.
2) Pro= ject 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 "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:

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

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

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.

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

-A

[1] I randomly picke= d this package as an example.
[2] For the record, I am not, but I= can certainly see how others might be.
=C2=A0
>
> 2. As an additional point, can you try to give your version of a simpl= e
>=C2=A0 =C2=A0 statement on the legal liabilities that the Council as a = whole, and
>=C2=A0 =C2=A0 the Council members as individuals, have for their action= s?
>

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, bu= t
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--