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 A2874138334 for ; Wed, 10 Apr 2019 06:54:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7CCA0E0933; Wed, 10 Apr 2019 06:54:30 +0000 (UTC) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 E6B08E0903 for ; Wed, 10 Apr 2019 06:54:29 +0000 (UTC) Received: by mail-lj1-x229.google.com with SMTP id v22so1031361lje.9 for ; Tue, 09 Apr 2019 23:54:29 -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=yIzv3Ry14b5CM8rSq4DZt9HZrcWiXCTjR0fECV1Plr8=; b=hoFdvSMxr6AU8rZlwLH9yCTZ6rs06ILJimbI4D9p/4nID/RF5U61Kc/5ZrEcRiDmfR bcnRVtZSAwFlPZXFTp21xe/aXrAWz7T4zKcDSkobwQw5kh66MYp1KjO4sFuD7kE833X4 3xEHo4pafwDNTiN4oPUazDRYyL3iAq746FgCiag2xpQDbkuEqzUdfy+ek75Pr0zHsz4x t0WlDSxPttEFosgMjeIf7JkZqX4nz/KhBnaQ0lE4MkDOMB+Ji/yb47kPxrCglcZ70tf2 zdhwodUTLUmkAP7pVzIj/AD0rHBphj14shnAs3JuLv4bgEHqSVAo29fyv+CsYf3MtrtV st9A== 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=yIzv3Ry14b5CM8rSq4DZt9HZrcWiXCTjR0fECV1Plr8=; b=sImk2TnFlyZSMkLZ2GuQKalfYaPa/QJ7t7agcsHc84V8tWGxx8YlJ3XTEMpcEkA/uJ PCioUA2524xx0OKc9RUFNjD8yT+Dmq0RMBVpRWU1WHknQtyuyuHaScE05YDAh4z9HWKZ QvFCEfuhuszeMPEk+tLiDOp3Y1PuO//j8cfDai7pg5lIm7iSDVYUeiXYfemq0H/9NP95 ve1dpVDeFpqOtRyATN4b3MFZKxK9nvH9XzsXmhaNg/J23ZP4Yo0eWWHJbHp3CyfVEJpz gNWjaoP+LRNNOJ3LrNPWXRLeLraYA6r0NbNHMAzWxm4wpEX469zcJrgtiS59zx/LX+a6 yfcA== X-Gm-Message-State: APjAAAXLrwljEh9yeBrM/4/nMNwDpCN1qgr1Ye9KO5hc4n4B33anFgeO EfpxrAikMZTFtPx3+A0FBPAV1lUfpBzytB+YRDJc1GWEGG6crPtr X-Google-Smtp-Source: APXvYqyb7AprOSgyny4KSnAGz/MeoFQOBxDKrw4Pxfp88Is3aJp7YiUGP5Ke/rWnblKsjuUGTbODcyvCBGpb0yUsrgY= X-Received: by 2002:a2e:9e47:: with SMTP id g7mr23455650ljk.48.1554879267588; Tue, 09 Apr 2019 23:54:27 -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: <4bbfc34f-335f-5521-310a-b66ffd0d9a9a@gentoo.org> <5e30d658-80c8-b608-1505-dc08db3625bf@gentoo.org> <20190403174315.32615d3b9574571e3ed4a399@gentoo.org> <80ed2e482e96c96555bf4fd9331731c4c9ad0d7f.camel@gentoo.org> <232747ba-063c-821f-a66d-5f106ed2aa82@gentoo.org> <20190410062712.jvgec4vhpvvo2e6v@gentoo.org> In-Reply-To: <20190410062712.jvgec4vhpvvo2e6v@gentoo.org> From: Alec Warner Date: Wed, 10 Apr 2019 02:54:16 -0400 Message-ID: Subject: Re: [gentoo-project] call for agenda items -- council meeting 2019-04-14 To: gentoo-project Cc: Ulrich Mueller , Gokturk Yuksek Content-Type: multipart/alternative; boundary="00000000000069e1670586278a89" X-Archives-Salt: 759dd941-0bad-4cd3-b812-a450d48079ff X-Archives-Hash: 06f0ae0161af45bcaefcdcec352fa451 --00000000000069e1670586278a89 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 10, 2019 at 2:17 AM Alice Ferrazzi wrote: > The 04/10/2019 07:59, Ulrich Mueller wrote: > > >>>>> On Wed, 10 Apr 2019, Ulrich Mueller wrote: > > > > >>>>> On Tue, 09 Apr 2019, Gokturk Yuksek wrote: > > > > > I'd like to (informally) propose the following, for which I'm willing > > > to formulate as a GLEP proposal if there is interest: > > > > > The Foundation has an established practice of storing the legal names > > > of developers who join under a pseudonym. The infrastructure is > > > already in place for this. I think that allowing these developers to > > > commit using their pseudonyms as long as the Foundation is informed > > > their real identity does not exacerbate the legal risks they already > > > pose. The foundation may decide their arbitrary criteria on who is > > > eligible for this type of protection, including requiring sound legal > > > reasons for them to keep their identities hidden. I understand that > > > the maintenance of this could be a burden for the Foundation in > > > theory, but in practice I suspect this number is very low already. > > > > That doesn't work, because there would be no way for a person outside of > > the Foundation to verify such identities. > > > There is no way also for foundation to check all sign-off are assigned > to real legal names. > So these are two separate points. I don't quite understand Ulm's point but it is different than the point you are raising. Your point seems to be that somehow the "Foundation must be able to check if all sign-offs are signed by a legal name." We already made it clear we don't do this checking. That doesn't mean its OK to use an pseudonym (it is not, and doing so violates the policy.) If we later find out people violate the policy, we don't accept commits from them anymore. You can call the system crappy or whatever, but its the system we have in place. today. Ulm's point seems to be about transparency: "there would be no way for a person outside of the Foundation to verify such identities." I'm not sure the entire usefulness of such a use case (do people care about being able to do this?) Putting the above points aside for a moment the Foundation has had a policy of shielding specific contributors from having their identity made public. I can't say with a straight face that "the infrastructure is already in place for this" (it really isn't) nor can I say that the Foundation has any written policies about how to safeguard, share, divulge, or otherwise use this information and instead it has ridden on the spoken words of various Foundation officials in the past. Its not something I'd want to build upon. > > To clarify, I won't be opposed against making a specific exception and > > "grandfathering" any devs who had commit access before the cut-off date > > when GLEP 76 was implemented. > > > > I propose foundation to vote for add the use of pseudonym in the GLEP 76. > For keeping Gentoo a confortable and inclusive place. > > > However, going forward, we shouldn't allow any further exceptions from > > the real name policy. > > > I'm not especially keen on grandfathering people into the project in this way because I think it defers the problem. Pseudonymous contributors want to contribute but cannot. Letting in people who happened to be contributors before glep 76 doesn't solve this problem, it just defers it in the hopes that new contributors who fall into this bucket get dissuaded before they push for changes. > > who said that we cannot allow any further excepions from the real name > policy? > > -- > ====================================== > Thanks, > Alice Ferrazzi > > Gentoo Kernel Project Leader > PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A > ====================================== > > --00000000000069e1670586278a89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 10, 2019 at 2:17 AM Alice= Ferrazzi <alicef@gentoo.org>= ; wrote:
The 04/= 10/2019 07:59, Ulrich Mueller wrote:
> >>>>> On Wed, 10 Apr 2019, Ulrich Mueller wrote:
>
> >>>>> On Tue, 09 Apr 2019, Gokturk Yuksek wrote:
>
> > I'd like to (informally) propose the following, for which I&#= 39;m willing
> > to formulate as a GLEP proposal if there is interest:
>
> > The Foundation has an established practice of storing the legal n= ames
> > of developers who join under a pseudonym. The infrastructure is > > already in place for this. I think that allowing these developers= to
> > commit using their pseudonyms as long as the Foundation is inform= ed
> > their real identity does not exacerbate the legal risks they alre= ady
> > pose. The foundation may decide their arbitrary criteria on who i= s
> > eligible for this type of protection, including requiring sound l= egal
> > reasons for them to keep their identities hidden. I understand th= at
> > the maintenance of this could be a burden for the Foundation in > > theory, but in practice I suspect this number is very low already= .
>
> That doesn't work, because there would be no way for a person outs= ide of
> the Foundation to verify such identities.
>
There is no way also for foundation to check all sign-off are assigned
to real legal names.

So these are two s= eparate points. I don't quite understand Ulm's point but it is diff= erent than the point you are raising.

Your point s= eems to be that somehow the "Foundation must be able to check if all s= ign-offs are signed by a legal name." We already made it clear we don&= #39;t do this checking. That doesn't mean its OK to use an pseudonym (i= t is not, and doing so violates the policy.) If we later find out people vi= olate the policy, we don't accept commits from them anymore. You can ca= ll the system crappy or whatever, but its the system we have in place. toda= y.

Ulm's point seems to be about transparency:= "there would be no way for a person outside of the Foundation to veri= fy such identities." I'm not sure the entire usefulness of such a = use case (do people care about being able to do this?)

=
Putting the above points aside for a moment the Foundation has had a p= olicy of shielding specific contributors from having their identity made pu= blic. I can't say with a straight face that "the infrastructure is= already in place for this" (it really isn't) nor can I say that t= he Foundation has any written policies about how to safeguard, share, divul= ge, or otherwise use this information and instead it has ridden on the spok= en words of various Foundation officials in the past. Its not something I&#= 39;d want to build upon.


> To clarify, I won't be opposed against making a specific exception= and
> "grandfathering" any devs who had commit access before the c= ut-off date
> when GLEP 76 was implemented.
>

I propose foundation to vote for add the use of pseudonym in the GLEP 76. For keeping Gentoo a confortable and inclusive place.

> However, going forward, we shouldn't allow any further exceptions = from
> the real name policy.
>

I'm not especially keen on gr= andfathering people into the project in this way because I think it defers = the problem. Pseudonymous contributors want to contribute but cannot. Letti= ng in people who happened to be contributors before glep 76 doesn't sol= ve this problem, it just defers it in the hopes that new contributors who f= all into this bucket get dissuaded before they push for changes.
= =C2=A0

who said that we cannot allow any further excepions from the real name
policy?

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--00000000000069e1670586278a89--