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 |
> |