Gentoo Archives: gentoo-nfp

From: Alec Warner <antarus@g.o>
To: gentoo-nfp <gentoo-nfp@l.g.o>
Subject: Re: [gentoo-nfp] Please vote on this proposal related to http://bugs.gentoo.org/667602
Date: Tue, 09 Oct 2018 21:06:23
Message-Id: CAAr7Pr_zySow4WZ7Fznr+rT8b407w89w3PPdhvxFf6WPUpoPLA@mail.gmail.com
In Reply to: Re: [gentoo-nfp] Please vote on this proposal related to http://bugs.gentoo.org/667602 by "Michał Górny"
1 On Thu, Oct 4, 2018 at 12:17 PM Michał Górny <mgorny@g.o> wrote:
2
3 > On Thu, 2018-10-04 at 11:14 -0400, Alec Warner wrote:
4 > > Summary:
5 > > The short version of the bug is that a non-trivial number of developers
6 > > cannot commit with an SoB line because their company has not yet reviewed
7 > > the new Gentoo Copyright GLEP, and so they lack company approval to
8 > attach
9 > > SoB lines or agree to the DCO.
10 > >
11 > > The bug requests that a reprieve be granted until the company reviews the
12 > > new policy and (hopefully) grants approval. This would be in the form of
13 > an
14 > > allowlist where specific identities (approved by some delegate of council
15 > > && trustees) do not require an SoB line to commit for some period of
16 > time.
17 >
18 >
19 Apologies for my tardy reply.
20
21
22 > Don't you think that requiring approval for allowlist means double
23 > standards? I mean, even if you assume that all requests would be
24 > granted, the requirement of approval provides for this 'delegate'
25 > selecting which developers are granted this privilege and which are not.
26 >
27
28 > In other words, I would rather suggest that the reprieve is granted for
29 > everyone and that the allowlist is maintained by Infra as part of opt-
30 > out hook intended to avoid developers accidentally missing the tag.
31 >
32
33 So basically this would be similar to the gentoo-dev-whitelist, where
34 anyone can do anything, but there is auditing?
35
36 I think this goes against my general feeling is that this is a *specific*
37 group of developers whom have raised a *specific legal problem* for their
38 contributions. Based on that I'm happy to grant them a reprieve on that
39 basis. I'm less happy to grant a reprieve to everyone; because its not
40 clear what the basis for the reprieve would be.
41
42
43 >
44 > > Proposal:
45 > > I propose the board grant this reprieve, for whitelisted accounts for 90
46 > > days, with no extension. Williamh will supply the initial list of
47 > accounts,
48 > > to be reviewed verbally by a board delegate and a council delegate.
49 > >
50 > > If the company cannot return a decision in 90 days, we can revisit the
51 > > motion with any updated data.
52 >
53 > I'm confused. This really reads like 'no extension; except we will vote
54 > on extension if necessary'.
55 >
56
57 There are no extensions in this proposal, but the proposal does not limit
58 the actions of the future board. So you read correctly, yes.
59
60
61 >
62 > > If the company returns a decision before 90 days, the whitelist program
63 > > will be terminated (regardless of decision reached.) Note that if the
64 > > company decides that approval will not be granted, we will in effect be
65 > > unable to accept commits from these developers on work time.
66 >
67 > Does this imply the reprieve will be granted only to the employees of
68 > one particular company, or will it extend to all developers in similar
69 > situation? In the latter case, will the decision of one company affect
70 > the status of the reprieve for other developers?
71 >
72
73 Tying it back the first part of my reply, this proposal grants a specific
74 reprieve on a specific basis. If other people want reprieves based on other
75 basis's[0], I'm happy to listen to them.
76
77
78 >
79 > --
80 > Best regards,
81 > Michał Górny
82 >