1 |
The 04/10/2019 09:13, Michał Górny wrote: |
2 |
> On Tue, 2019-04-09 at 21:13 +0000, Gokturk Yuksek wrote: |
3 |
> > > To your second question, you could, but I think that would be wrong and if |
4 |
> > > I found out I'd probably talk to you about it and if it continued, I'd |
5 |
> > > probably take some kind of remedial action. The intent is to have a |
6 |
> > > reasonable suspicion of fraud or wrongdoing, not to do just do it willy |
7 |
> > > nilly. |
8 |
> > > |
9 |
> > > That being said I don't intend to forge a policy that is bullet-proof. If I |
10 |
> > > cannot trust fellow project members to act well, they might as well just |
11 |
> > > leave the project now. If project members are looking for "a list of rules |
12 |
> > > to follow" my only rules are "don't be an ass" and if you are told you are |
13 |
> > > being an ass, maybe listen and take that advice as opposed to objecting. |
14 |
> > > |
15 |
> > |
16 |
> > My point about the guidelines is for the concern on the receiving party. |
17 |
> > I suspect there may be situations where saying "I'm not convinced that |
18 |
> > this is a real name of a person. Would you please provide me a proof of |
19 |
> > ID?" is perceived offensive. Guidelines published by the Foundation help |
20 |
> > developers justify their stance and ease people into compliance, I think. |
21 |
> > |
22 |
> > > > > > Additional problem is personal data collection, it is |
23 |
> > > > > > restricted or heavily regulated in many countries. One can't just |
24 |
> > > > > > demand to show an ID via electronic means without following |
25 |
> > > > > > complicated data protection procedures which are likely to be |
26 |
> > > > > > incompatible between jurisdictions. |
27 |
> > > > > |
28 |
> > > > > Do you have any proof of that, or are you just basing your comments |
29 |
> > > > > on the common concept of misunderstanding GDPR and extending it to match |
30 |
> > > > > your private interest? |
31 |
> > > > > |
32 |
> > > > |
33 |
> > > > At the very least, insecure transportation and storage of legal |
34 |
> > > > documents has a potential to lead to identity theft, which makes it a |
35 |
> > > > legal liability in and of itself. I don't think we should be dismissive |
36 |
> > > > on this point. |
37 |
> > > > |
38 |
> > > |
39 |
> > > I don't believe any policies require collecting personal data currently. |
40 |
> > > |
41 |
> > |
42 |
> > If I have suspicions about a contributor's identity, would you advise me |
43 |
> > on a method of validation that doesn't require the electronic transfer |
44 |
> > of a government approved identification? |
45 |
> |
46 |
> My suggestion would be to use the solution that's been there for years |
47 |
> -- OpenPGP web of trust. Establish a path of trust and/or keysign with |
48 |
> the person in question. This naturally involves verifying one's ID, |
49 |
> and reduces the risk of stealing personal data to the minimum. |
50 |
|
51 |
I'm interested in using OpenPGP for verifying the identity. |
52 |
|
53 |
> |
54 |
> > > The Foundation has always carried legal risk. Only recently have we |
55 |
> > > (through the awesome work of ulm@ and others) had a policy to help mitigate |
56 |
> > > it. These contributors have not 'suddenly become a legal risk' but instead |
57 |
> > > the community (council and foundation combined) have adopted a more |
58 |
> > > risk-averse stance by adopting GLEP-76 and that results in some |
59 |
> > > contributors being unable to contribute. I'm not sure what else needs to be |
60 |
> > > explained. |
61 |
> > > |
62 |
> > > |
63 |
> > |
64 |
> > To the best of my knowledge, the Foundation has a long established |
65 |
> > practice of allowing developers to use pseudonyms on the condition that |
66 |
> > they reveal their legal identity to the Foundation for legal protection. |
67 |
> > Was the exclusion of developers with pseudonyms as per GLEP76 a result |
68 |
> > of a conclusion that the Foundation being informed about developers |
69 |
> > legal identity wrt copyright infringement carries more risk compared to |
70 |
> > their total exclusion from development? |
71 |
> |
72 |
> Did you read the Linux policy? It is clear: the problem's not |
73 |
> Foundation knowing, it's *community* knowing. Foundation is just |
74 |
> a temporary opaque body that's going to be dissolved one day. Code's |
75 |
> going to live much longer, and it needs to be sustainable without having |
76 |
> to refer to secret records of the Foundation. |
77 |
|
78 |
For example the debian project got in same problems in this last 10years |
79 |
about real names. |
80 |
In the end they decided to accept pseudonym. |
81 |
https://nm.debian.org/process/610/keycheck |
82 |
|
83 |
> |
84 |
> > > If you want to make a point that Gentoo leadership is bad at making |
85 |
> > > opposing feelings heard, well I'd probably agree with you (this thread is |
86 |
> > > one such example.) If you want to make some kind of point that "having an |
87 |
> > > opinion heard means we change the policy to suit that opinion" then I think |
88 |
> > > we just disagree on that point. Don't make it out like we made the decision |
89 |
> > > without thinking of anonymous / pseudonymous contributors; numerous |
90 |
> > > discussions were had about them and we could not find a way to include them |
91 |
> > > in the policy. |
92 |
> > > |
93 |
> > > That doesn't mean we didn't hear their thoughts and objections though. |
94 |
> > > |
95 |
> > Perhaps the people I talked to didn't find the right people to talk to |
96 |
> > before me. I'm not trying to paint the leadership as ignorant or bad. I |
97 |
> > understand that this is all volunteer work first and foremost. I wasn't |
98 |
> > implying to enact a change in the policy on the basis that people's |
99 |
> > opinions haven't been sufficiently heard. |
100 |
> > |
101 |
> |
102 |
> Perhaps the person you talked to don't 'take no for an answer'. |
103 |
> If the policy works for the majority of people, and there are only few |
104 |
> who disagree with it (no matter how much they try to exaggerate it), |
105 |
> and most of those few so far have failed to provide a really good |
106 |
> argument why they can't do it, then I'm sorry but that's just how things |
107 |
> work. |
108 |
|
109 |
If you have any better data, that is not just a presumption please show us. |
110 |
saying that the majority of people is contributing in Gentoo, is no |
111 |
meaning. On how many people you are talking about ? you are taking in |
112 |
consideration all the Gentoo users? |
113 |
For me having people quitting Gentoo devs or Gentoo contribution for a |
114 |
change in GLEP is a big deal, we are already not that many. |
115 |
|
116 |
That is just how things works for you. |
117 |
|
118 |
> |
119 |
> I'm certainly against changing the policy on arguments like 'but I want |
120 |
> to brand myself as X' or 'but you can't prove people are using fake |
121 |
> identities'. If you really want to push for the latter, I wouldn't mind |
122 |
> making some form of identity verification obligatory for everyone. |
123 |
> However, I doubt that's the result you want. |
124 |
|
125 |
Happy to ear your personal opinion but not everyone thinks in the same |
126 |
way as you. |
127 |
I think the opinion of other people is a valuable opinion whathever they |
128 |
say. |
129 |
|
130 |
What I think we want, is more people contributing in Gentoo. |
131 |
|
132 |
|
133 |
|
134 |
-- |
135 |
====================================== |
136 |
Thanks, |
137 |
Alice Ferrazzi |
138 |
|
139 |
Gentoo Kernel Project Leader |
140 |
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A |
141 |
====================================== |