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 9EDC8138334 for ; Wed, 10 Apr 2019 07:13:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 68A35E07E2; Wed, 10 Apr 2019 07:13:21 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 1A4DCE07D1 for ; Wed, 10 Apr 2019 07:13:20 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 52FA83408F9; Wed, 10 Apr 2019 07:13:18 +0000 (UTC) Message-ID: <2495c3061f522db40cbd37a6f809d309063294c0.camel@gentoo.org> Subject: Re: [gentoo-project] call for agenda items -- council meeting 2019-04-14 From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org, Alec Warner Date: Wed, 10 Apr 2019 09:13:14 +0200 In-Reply-To: <5e5d94b9-4930-ebb0-2efd-c32abe6827d8@gentoo.org> 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> <5e5d94b9-4930-ebb0-2efd-c32abe6827d8@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-tP3s+l+yNVXB4NWgKsd5" User-Agent: Evolution 3.30.5 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 X-Archives-Salt: e78f69b1-fb17-4580-bc65-782df09c95ef X-Archives-Hash: 535da78018ab2b569d9be30a16eb2ca7 --=-tP3s+l+yNVXB4NWgKsd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2019-04-09 at 21:13 +0000, Gokturk Yuksek wrote: > > 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. > >=20 > > 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 jus= t > > leave the project now. If project members are looking for "a list of ru= les > > 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= . > >=20 >=20 > My point about the guidelines is for the concern on the receiving party. > I suspect there may be situations where saying "I'm not convinced that > this is a real name of a person. Would you please provide me a proof of > ID?" is perceived offensive. Guidelines published by the Foundation help > developers justify their stance and ease people into compliance, I think. >=20 > > > > > 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. > > > >=20 > > > > 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 = match > > > > your private interest? > > > >=20 > > >=20 > > > 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 dismissi= ve > > > on this point. > > >=20 > >=20 > > I don't believe any policies require collecting personal data currently= . > >=20 >=20 > If I have suspicions about a contributor's identity, would you advise me > on a method of validation that doesn't require the electronic transfer > of a government approved identification? My suggestion would be to use the solution that's been there for years -- OpenPGP web of trust. Establish a path of trust and/or keysign with the person in question. This naturally involves verifying one's ID, and reduces the risk of stealing personal data to the minimum. > > The Foundation has always carried legal risk. Only recently have we > > (through the awesome work of ulm@ and others) had a policy to help miti= gate > > it. These contributors have not 'suddenly become a legal risk' but inst= ead > > 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 t= o be > > explained. > >=20 > >=20 >=20 > To the best of my knowledge, the Foundation has a long established > practice of allowing developers to use pseudonyms on the condition that > they reveal their legal identity to the Foundation for legal protection. > Was the exclusion of developers with pseudonyms as per GLEP76 a result > of a conclusion that the Foundation being informed about developers > legal identity wrt copyright infringement carries more risk compared to > their total exclusion from development? Did you read the Linux policy? It is clear: the problem's not Foundation knowing, it's *community* knowing. Foundation is just a temporary opaque body that's going to be dissolved one day. Code's going to live much longer, and it needs to be sustainable without having to refer to secret records of the Foundation. > > 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 t= hink > > we just disagree on that point. Don't make it out like we made the deci= sion > > 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. > >=20 > > That doesn't mean we didn't hear their thoughts and objections though. > >=20 > Perhaps the people I talked to didn't find the right people to talk to > before me. I'm not trying to paint the leadership as ignorant or bad. I > understand that this is all volunteer work first and foremost. I wasn't > implying to enact a change in the policy on the basis that people's > opinions haven't been sufficiently heard. >=20 Perhaps the person you talked to don't 'take no for an answer'. If the policy works for the majority of people, and there are only few who disagree with it (no matter how much they try to exaggerate it), and most of those few so far have failed to provide a really good argument why they can't do it, then I'm sorry but that's just how things work. I'm certainly against changing the policy on arguments like 'but I want to brand myself as X' or 'but you can't prove people are using fake identities'. If you really want to push for the latter, I wouldn't mind making some form of identity verification obligatory for everyone.=20 However, I doubt that's the result you want. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-tP3s+l+yNVXB4NWgKsd5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlytl4pfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQrTmhAA1KbdaFwYt5C0DqdVtosYalyFh2wKJPQuzE5GlQsOG6YiIbYAz4b0VO5I Pb00Fvpq/MQMor2QtpL4fS6xSVeGymzaCPxZtHWvNF35uiEfUy0FrUaQrC3a8mE2 9F+pLg/06TYhuvg6y/Na0bDwGHSa5Z+FfD0zp3S1EDJwyUkY9ZMR8AyPaXjHtZ88 6K6n6JXvbeNkkdGVTZ8N58YFOlWrWGpz57HzTfVMcS1T0wMoFz0jGjeF+7TOebky mfO27TpMYAxU6e3bQpUW2rSvmEeixlu66V1JPsBtvsI0FLNZfIfSipNi4dkmVzS5 7zKeQXCegaElNlz7fN96ETUSNvBOx2ZFwx1qeD476e4WPC+tYjK3PKAF8w/qc2aJ XFgCjlme7ykU9bNxC0Tea2IdDITlcDT9+FsS9E94dN3pTmi6J3e/bENLMLH5UwV/ BHAr9+bQs/gGln5XQsaxmL2ghjRdMIX9wXR4f+VPwULjzGeAABzO6T6njGBxrNhh ucGSb2PK0NjckuAGHTLKsm4PpCLA08XmwWSWZsKVjPhi28gn1g7NLXoIdIiI+FhO SyLkkmmFNwGPeEMRzbatQg8dtYP3RcPqAtQLKW2TzKkaFAQhyxTjFAMdm+glbure 2W0Yye9Hxh0cXkFjrwauhfin+l9pbX/jJniPcgLqVTqc9XIAQQY= =AsCQ -----END PGP SIGNATURE----- --=-tP3s+l+yNVXB4NWgKsd5--