1 |
On 28/07/2021 06:07, Joonas Niilola wrote: |
2 |
> Summary: |
3 |
> Make it clearer that a sign-off to a git commit is only required from |
4 |
> the committer, not from the author. It's only encouraged for the |
5 |
> authors. |
6 |
|
7 |
I am not a lawyer so I might be completely wrong, but to me this is very |
8 |
confusing. According to the GLEP the whole point of the sign-off is to |
9 |
state agreement to the Certificate of Origin, the purpose of which "is |
10 |
to declare that the contribution can be modified and redistributed in |
11 |
accordance with the project's license". |
12 |
|
13 |
Now if I read this Certificate of Origin, and apply it to the situation |
14 |
where I am merging an user contribution: |
15 |
|
16 |
> 1. The contribution was created in whole or in part by me, and I have |
17 |
the right to submit it under the free software license indicated in the |
18 |
file; or |
19 |
|
20 |
1 does not apply since I did not create the contribution, I am only |
21 |
merging it. |
22 |
|
23 |
> 2. The contribution is based upon previous work that, to the best of |
24 |
my knowledge, is covered under an appropriate free software license, and |
25 |
I have the right under that license to submit that work with |
26 |
modifications, whether created in whole or in part by me, under the same |
27 |
free software license (unless I am permitted to submit under a different |
28 |
license), as indicated in the file; or |
29 |
|
30 |
2 may or may not apply depending on what the contribution exactly is. |
31 |
e.g. a new ebuild may or may not be based on previous work. (Though one |
32 |
could argue that everything is based on something (e.g. on an example in |
33 |
the devmanual), but in this interpretation point 2 more or less loses |
34 |
all meaning since it would apply to *everything*) |
35 |
|
36 |
> 3. The contribution is a license text (or a file of similar nature), |
37 |
and verbatim distribution is allowed; or |
38 |
|
39 |
3 applies only if it is a license, for the sake of argument lets assume |
40 |
this contribution is not a license file. |
41 |
|
42 |
> 4. The contribution was provided directly to me by some other person |
43 |
who certified 1., 2., 3., or 4., and I have not modified it. |
44 |
|
45 |
4 applies, but here's the catch. It only applies if the contributor has |
46 |
also included a sign-off. |
47 |
|
48 |
So if we allow contributions without a sign-off from the contributor the |
49 |
sign-off from the developer is meaningless since neither 1, 2, 3, or 4 |
50 |
applies to the commit. |
51 |
|
52 |
Given the rationale outlined below, I do agree that something should |
53 |
change. However, I'm a bit concerned that the suggested solution of only |
54 |
requiring the sign-off from the developer kinda breaks the whole point |
55 |
of having the sign-offs in the first place since it breaks the |
56 |
Certificate of Origin. |
57 |
|
58 |
Which brings me to my second point. As far as I know, pseudonyms can in |
59 |
fact hold (and therefore transfer and sign-off) copyright. There are |
60 |
many examples of books and other texts written by authors using a |
61 |
different name then their 'legal name'. Such texts are not treated |
62 |
(fundamentally) different under copyright law simply because the author |
63 |
chose to use a pseudonym. Now a book is not an ebuild, but why wouldn't |
64 |
the same apply here? |
65 |
|
66 |
So given the above, why not simply drop the requirement for using a |
67 |
persons 'legal name' (which we cannot enforce anyway), and allow the use |
68 |
of pseudonyms? Isn't this a way easier solution to the problem that |
69 |
doesn't break the whole point of the sign-off? |
70 |
|
71 |
But then again, I am not a lawyer, so please correct me if my analysis |
72 |
is wrong. |
73 |
|
74 |
> Rationale: |
75 |
> 1. We're actively rejecting contributions from people who do not wish to |
76 |
> have their real name shown in public, or link it to their Git* |
77 |
> accounts. |
78 |
> |
79 |
> 2. We have no way of knowing or confirming whether the given name is |
80 |
> "legal". I'd rather not have the sign-off from the author in the first |
81 |
> place than see clearly made up names in there, with a fresh-made Git* |
82 |
> account with no prior activity. |
83 |
> |
84 |
> 3. Recently we've had a couple of cases where our long-standing |
85 |
> contributors, with ~300 commits in total, reveal they've been using |
86 |
> pseudonyms. I'm sure there are many others. AFAIK all their commits |
87 |
> should then be revoked, and possibly future contributions rejected |
88 |
> due to trust issues? |
89 |
> |
90 |
> 4. As said, there are already devs committing work from people we |
91 |
> know to have made-up names. And/or there are devs committing patches |
92 |
> without the sign-off to begin with. |
93 |
> |
94 |
> 5. The infra git-hooks currently only check for a matching sign-off |
95 |
> from the committer anyway. |
96 |
> |
97 |
> Final words: |
98 |
> So currently, this GLEP can be interpreted in two different ways: the |
99 |
> sign-off is and isn't required from the author. This does harm |
100 |
> towards contributors who work with devs who do require the sign-off |
101 |
> from the author, and thus the GLEP needs to be updated and enforced |
102 |
> one way or the other. I vote what benefits our contributors, and |
103 |
> therefore us, better. |
104 |
> |
105 |
> Signed-off-by: Joonas Niilola <juippis@g.o> |
106 |
> --- |
107 |
> glep-0076.rst | 15 +++++++++++---- |
108 |
> 1 file changed, 11 insertions(+), 4 deletions(-) |
109 |
> |
110 |
> diff --git a/glep-0076.rst b/glep-0076.rst |
111 |
> index 4aa5ee5..faa760d 100644 |
112 |
> --- a/glep-0076.rst |
113 |
> +++ b/glep-0076.rst |
114 |
> @@ -8,10 +8,11 @@ Author: Richard Freeman <rich0@g.o>, |
115 |
> Michał Górny <mgorny@g.o> |
116 |
> Type: Informational |
117 |
> Status: Active |
118 |
> -Version: 1.1 |
119 |
> +Version: 1.2 |
120 |
> Created: 2013-04-23 |
121 |
> -Last-Modified: 2018-12-09 |
122 |
> -Post-History: 2018-06-10, 2018-06-19, 2018-08-31, 2018-09-26 |
123 |
> +Last-Modified: 2021-07-28 |
124 |
> +Post-History: 2018-06-10, 2018-06-19, 2018-08-31, 2018-09-26, |
125 |
> + 2021-07-28 |
126 |
> Content-Type: text/x-rst |
127 |
> --- |
128 |
> |
129 |
> @@ -138,7 +139,10 @@ the Certificate of Origin by adding :: |
130 |
> |
131 |
> to the commit message as a separate line. The sign-off must contain |
132 |
> the committer's legal name as a natural person, i.e., the name that |
133 |
> -would appear in a government issued document. |
134 |
> +would appear in a government issued document. It's strongly encouraged |
135 |
> +that the original contribution author also adds their sign-off, to at |
136 |
> +least indicate they are aware of this GLEP. But it's required only |
137 |
> +from the committer. |
138 |
> |
139 |
> The following is the current Gentoo Certificate of Origin, revision 1: |
140 |
> |
141 |
> @@ -301,6 +305,9 @@ iv. The original point (d) has been transformed into a stand-alone |
142 |
> v. The term "open source" has been replaced by "free software" |
143 |
> throughout. |
144 |
> |
145 |
> +vi. Clarify that a sign-off is only strictly required from the |
146 |
> + committer, not from the author. |
147 |
> + |
148 |
> The new point was deemed necessary to allow committing license files |
149 |
> into the Gentoo repository, since those files usually do not permit |
150 |
> modification. It has been established that adding a clear provision |
151 |
> |