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 D1034138334 for ; Tue, 9 Apr 2019 20:45:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8B360E0874; Tue, 9 Apr 2019 20:45:43 +0000 (UTC) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 E6F13E086F for ; Tue, 9 Apr 2019 20:45:42 +0000 (UTC) Received: by mail-lj1-x232.google.com with SMTP id v22so9534lje.9 for ; Tue, 09 Apr 2019 13:45:42 -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; bh=fc/Yxn8JRRJzkRtiUKwIAYhVSYGxdhfAQC2Bl41OQkc=; b=hVC0aQBkMj0wLXLAcF+HpDhrnUSmh1uXum7pan2vBX9Q3sJojX5fTyHCgj5L5k3JJZ oC/R4kLKsOPUAs5MrddRJFT/PbqOxdqQN7Hba/H6vNue+gdIVrnxTLvBahXNtRqZ86Mc nwkbfMDuZ/Fz/k5PReYwcpSY8YPVB3sx3vtMOy+Xf9juRInPNoGSou+7JUeIEqxyyFWT mUzUVFNAfeISzvMByW17QLhi7ebqGU1jlx4lEnb0nI1+dwkYd1ZgQ2kZRBV5C6DMjcFC D6c9+YszYbLEkipcQr4wKEuIPw95X/eKTfaT/klBkF2tgwIfAexAezXKOT5wVn15Nd0w ObMw== 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; bh=fc/Yxn8JRRJzkRtiUKwIAYhVSYGxdhfAQC2Bl41OQkc=; b=mZM7gToUBX3buFOeaAZ+bSRcFQZW/Uav4h+FEfb5WF3B/hjFqaoLh7eI2y/TuF51WX VQYYcphr5lUFYWAQYNkF+HTFBgaJ85OTPiedI39XteifHvrU/GTdNtncoAa/6v4mAkzl 1QlSOGUiYzfSmRdJqWyKVee7nByBjQ4diGraWiqm5lOjFhepgVQyfsgbP1foiXJHQPFw rKUhXikwzLo1lQc1Ep7Phut2ddSrF/C45HrGIPrGQp2qqAhNL+AFIdtFiEV5VzMfSIWj x6POoXmRnpVs7cNuERB7SOymoyDq//+ad5nZDpKlekZkQWKrKgajNLsdvk8+XBa5Jr2e pw9w== X-Gm-Message-State: APjAAAXNCpEND5LXFTCVn78WBdjzFCgmO+o6+TIf2QzFog1utYpJUk1e lIWdG6ytL6QAgcRVS/5TAyprvknDtZxOYY0btKgz0XIBM5XAPD6J X-Google-Smtp-Source: APXvYqzQcak/RDNpvf1UUARAN5B3n5yhoZhjLdYY2fkimQgoVDHylVkYom3vwnyCTeZ2jGYoFoQSdt1zBUKBB8Z5g7o= X-Received: by 2002:a2e:6a14:: with SMTP id f20mr21842637ljc.65.1554842740536; Tue, 09 Apr 2019 13:45:40 -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: <20190401032055.GA9497@linux1.home> <4bbfc34f-335f-5521-310a-b66ffd0d9a9a@gentoo.org> <5e30d658-80c8-b608-1505-dc08db3625bf@gentoo.org> <20190403174315.32615d3b9574571e3ed4a399@gentoo.org> <80ed2e482e96c96555bf4fd9331731c4c9ad0d7f.camel@gentoo.org> In-Reply-To: From: Alec Warner Date: Tue, 9 Apr 2019 16:45:29 -0400 Message-ID: Subject: Re: [gentoo-project] call for agenda items -- council meeting 2019-04-14 To: gentoo-project Content-Type: multipart/alternative; boundary="0000000000003b519105861f0939" X-Archives-Salt: 2a03c0ae-45b0-4ab3-8469-a192644d41de X-Archives-Hash: 36af115cdce2e4879a54c0153184d8e8 --0000000000003b519105861f0939 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 9, 2019 at 4:18 PM Gokturk Yuksek wrote: > Hi, > > I'd like to voice my opinion on the matter as well. Full disclosure: > NP-Hardass is my mentor and I also had a co-maintainer who has been > distressed by the enforcement of the GLEP. > > Micha=C5=82 G=C3=B3rny: > > On Wed, 2019-04-03 at 17:43 +0300, Andrew Savchenko wrote: > >> Why? We have no way to verify that provided names are valid or that > >> provided ID's are valid. At least in my jurisdiction such > >> information collected can't be used for legal action or protection > >> without following established government-assisted verification > >> procedure. In other jurisdictions similar problems may and will > >> arise. > > > > 'Perfect is the enemy of good'. Claiming that you can't be 100% sure > > that someone's giving his real name doesn't imply that everyone is usin= g > > fake names. Or that it makes no sense to use them. > > > > I understand that but it creates problems with the consistent > enforcement of the policy. There are no clear guidelines as to how we > decide who requires identity validation and who doesn't. We don't even > know who is tasked with making the request and performing the > validation. If I work with a user and I am convinced that they provide > their real name, is that sufficient for the foundation? Can I > arbitrarily be suspicious of any user and demand them to provide their > identity? > So first a preface: I would prefer we accept a name until we have some reasonable suspicion that it is wrong. If someone submitted as "boaty mcboatface" it might immediately raise such a suspicion; but a contributor who contributed as "John Doe" might not. Its very subjective, yes, and we don't offer better guidelines. So to your first question, yes its sufficient. To your second question, you could, but I think that would be wrong and if I found out I'd probably talk to you about it and if it continued, I'd probably take some kind of remedial action. The intent is to have a reasonable suspicion of fraud or wrongdoing, not to do just do it willy nilly. That being said I don't intend to forge a policy that is bullet-proof. If I cannot trust fellow project members to act well, they might as well just leave the project now. If project members are looking for "a list of rules to follow" my only rules are "don't be an ass" and if you are told you are being an ass, maybe listen and take that advice as opposed to objecting. > > >> Additional problem is personal data collection, it is > >> restricted or heavily regulated in many countries. One can't just > >> demand to show an ID via electronic means without following > >> complicated data protection procedures which are likely to be > >> incompatible between jurisdictions. > > > > Do you have any proof of that, or are you just basing your comments > > on the common concept of misunderstanding GDPR and extending it to matc= h > > your private interest? > > > > At the very least, insecure transportation and storage of legal > documents has a potential to lead to identity theft, which makes it a > legal liability in and of itself. I don't think we should be dismissive > on this point. > I don't believe any policies require collecting personal data currently. > > >> So the real name requirement gives us no real protection from > >> possible cases, but creates real and serious problems by kicking > >> active developers and contributors from further contributions. > >> NP-Hardass is not the only one. > > > > Do you have any proof of that? As far as I'm concerned, we're pretty > > clear that NP-Hardass can't contribute to Gentoo, and that his previous > > contributions shouldn't have been accepted in the first place (and why > > Trustees agreed to them is another problem). Are you going to take > > legal and financial responsibility if his employer claims copyright to > > his contributions? And if you say yes, are you going to really take it > > or go with the forementioned attitude that we can't legally force you > > to? > > > > I do disagree on this point. I believe the Foundation did take > appropriate measures to reduce the legal liability when he was > recruited. I think it should have been clearly explained how he has > become a legal liability to the Foundation before his access was taken > away from him. > The Foundation has always carried legal risk. Only recently have we (through the awesome work of ulm@ and others) had a policy to help mitigate it. These contributors have not 'suddenly become a legal risk' but instead the community (council and foundation combined) have adopted a more risk-averse stance by adopting GLEP-76 and that results in some contributors being unable to contribute. I'm not sure what else needs to be explained. > > You also bring up a more interesting point here. If I work with a user > who has lied to me about their identity, and their employer decided to > take it to court, who is liable? Am I at fault for having good faith or > is it a neglect on the Foundation's side? > I'm not a lawyer, so I won't speculate on this specific instance. Having a policy where commits require a DCO and we take some measure to not accept contributions when we have knowledge that the DCO is wrong / invalid is clearly better than our previous policy (which was basically "accept all contributions.") Whether it is sufficient to prevent any specific legal suit, I couldn't tell you. > > >> I invited some gifted people with > >> high quality out-of-tree work to become contributors or developers, > >> but due to hostile attitude towards anonymous contributors they > >> can't join. And people want to stay anonymous for good reasons, > >> because they are engaged with privacy oriented development. > > > > This is a very vague statement that sounds like serious overstatement > > with no proof, aimed purely to force emotional reaction to support your > > proposal. If you really want to propose something meaningful, I'd > > really appreciate if you used real evidence to support it rather than > > vague claims. > > > >> We are loosing real people, real contributions and real community. > >> What for? For solving imaginary problems with inappropriate tools. > >> > > > > Thank you for telling us that copyright is an imaginary problem. > > > > I can't help but agree with the point that we are losing real > contributors and real community. And people whom I talked to didn't > oppose the Foundation's attempt to reduce legal liability. They were > frustrated by the arbitrary enforcement and not having their opinions > heard. The fact that people can get away with using a pseudonym as long > as it reads like a normal person name (for which there is no definition) > is something we have to address to the people who weren't as lucky with > their choice of pseudonym and lost their ability to contribute. > If you want to make a point that Gentoo leadership is bad at making opposing feelings heard, well I'd probably agree with you (this thread is one such example.) If you want to make some kind of point that "having an opinion heard means we change the policy to suit that opinion" then I think we just disagree on that point. Don't make it out like we made the decision without thinking of anonymous / pseudonymous contributors; numerous discussions were had about them and we could not find a way to include them in the policy. That doesn't mean we didn't hear their thoughts and objections though. -A > > -- > gokturk > > --0000000000003b519105861f0939 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 9, 2019 at 4:18 PM Goktur= k Yuksek <gokturk@gentoo.org&g= t; wrote:
Hi,
I'd like to voice my opinion on the matter as well. Full disclosure: NP-Hardass is my mentor and I also had a co-maintainer who has been
distressed by the enforcement of the GLEP.

Micha=C5=82 G=C3=B3rny:
> On Wed, 2019-04-03 at 17:43 +0300, Andrew Savchenko wrote:
>> Why? We have no way to verify that provided names are valid or tha= t
>> provided ID's are valid. At least in my jurisdiction such
>> information collected can't be used for legal action or protec= tion
>> without following established government-assisted verification
>> procedure. In other jurisdictions similar problems may and will >> arise.
>
> 'Perfect is the enemy of good'.=C2=A0 Claiming that you can= 9;t be 100% sure
> that someone's giving his real name doesn't imply that everyon= e is using
> fake names.=C2=A0 Or that it makes no sense to use them.
>

I understand that but it creates problems with the consistent
enforcement of the policy. There are no clear guidelines as to how we
decide who requires identity validation and who doesn't. We don't e= ven
know who is tasked with making the request and performing the
validation. If I work with a user and I am convinced that they provide
their real name, is that sufficient for the foundation? Can I
arbitrarily be suspicious of any user and demand them to provide their
identity?

So first a preface: I would p= refer we accept a name until we have some reasonable suspicion that it is w= rong.
If someone submitted as "boaty mcboatface" it mig= ht immediately raise such a suspicion; but a contributor who contributed as= "John Doe" might not. Its very subjective, yes, and we don't= offer better guidelines.

So to your first questio= n, yes its sufficient.
To your second question, you could, but I = think that would be wrong and if I found out I'd probably talk to you a= bout it and if it continued, I'd probably take some kind of remedial ac= tion. The intent is to have a reasonable suspicion of fraud or wrongdoing, = not to do just do it willy nilly.

That being said = I don't intend to forge a policy that is bullet-proof. If I cannot trus= t fellow project members to act well, they might as well just leave the pro= ject now. If project members are looking for "a list of rules to follo= w" my only rules are "don't be an ass" and if you are to= ld you are being an ass, maybe listen and take that advice as opposed to ob= jecting.
=C2=A0

>> Additional problem is personal data collection, it is
>> restricted or heavily regulated in many countries. One can't j= ust
>> demand to show an ID via electronic means without following
>> complicated data protection procedures which are likely to be
>> incompatible between jurisdictions.
>
> Do you have any proof of that, or are you just basing your comments > on the common concept of misunderstanding GDPR and extending it to mat= ch
> your private interest?
>

At the very least, insecure transportation and storage of legal
documents has a potential to lead to identity theft, which makes it a
legal liability in and of itself. I don't think we should be dismissive=
on this point.

I don't believe any = policies require collecting personal data currently.
=C2=A0
=

>> So the real name requirement gives us no real protection from
>> possible cases, but creates real and serious problems by kicking >> active developers and contributors from further contributions.
>> NP-Hardass is not the only one.
>
> Do you have any proof of that?=C2=A0 As far as I'm concerned, we&#= 39;re pretty
> clear that NP-Hardass can't contribute to Gentoo, and that his pre= vious
> contributions shouldn't have been accepted in the first place (and= why
> Trustees agreed to them is another problem).=C2=A0 Are you going to ta= ke
> legal and financial responsibility if his employer claims copyright to=
> his contributions?=C2=A0 And if you say yes, are you going to really t= ake it
> or go with the forementioned attitude that we can't legally force = you
> to?
>

I do disagree on this point. I believe the Foundation did take
appropriate measures to reduce the legal liability when he was
recruited. I think it should have been clearly explained how he has
become a legal liability to the Foundation before his access was taken
away from him.

The Foundation has alway= s carried legal risk. Only recently have we (through the awesome work of ul= m@ and others) had a policy to help mitigate it. These contributors have no= t 'suddenly become a legal risk' but instead the community (council= and foundation combined) have adopted a more risk-averse stance by adoptin= g GLEP-76 and that results in some contributors being unable to contribute.= I'm not sure what else needs to be explained.
=C2=A0

You also bring up a more interesting point here. If I work with a user
who has lied to me about their identity, and their employer decided to
take it to court, who is liable? Am I at fault for having good faith or
is it a neglect on the Foundation's side?

I'm not a lawyer, so I won't speculate on this specific inst= ance. Having a policy where commits require a DCO and we take some measure = to not accept contributions when we have knowledge that the DCO is wrong / = invalid is clearly better than our previous policy (which was basically &qu= ot;accept all contributions.") Whether it is sufficient to prevent any= specific legal suit, I couldn't tell you.
=C2=A0

>> I invited some gifted people with
>> high quality out-of-tree work to become contributors or developers= ,
>> but due to hostile attitude towards anonymous contributors they >> can't join. And people want to stay anonymous for good reasons= ,
>> because they are engaged with privacy oriented development.
>
> This is a very vague statement that sounds like serious overstatement<= br> > with no proof, aimed purely to force emotional reaction to support you= r
> proposal.=C2=A0 If you really want to propose something meaningful, I&= #39;d
> really appreciate if you used real evidence to support it rather than<= br> > vague claims.
>
>> We are loosing real people, real contributions and real community.=
>> What for? For solving imaginary problems with inappropriate tools.=
>>
>
> Thank you for telling us that copyright is an imaginary problem.
>

I can't help but agree with the point that we are losing real
contributors and real community. And people whom I talked to didn't
oppose the Foundation's attempt to reduce legal liability. They were frustrated by the arbitrary enforcement and not having their opinions
heard. The fact that people can get away with using a pseudonym as long
as it reads like a normal person name (for which there is no definition) is something we have to address to the people who weren't as lucky with=
their choice of pseudonym and lost their ability to contribute.

If you want to make a point that Gentoo leadership= is bad at making opposing feelings heard, well I'd probably agree with= you (this thread is one such example.) If you want to make some kind of po= int that "having an opinion heard means we change the policy to suit t= hat opinion" then I think we just disagree on that point. Don't ma= ke it out like we made the decision without thinking of anonymous / pseudon= ymous contributors; numerous discussions were had about them and we could n= ot find a way to include them in the policy.

That = doesn't mean we didn't hear their thoughts and objections though.

-A
=C2=A0

--
gokturk

--0000000000003b519105861f0939--