Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Cc: Andrew Ammerlaan <andrewammerlaan@g.o>
Subject: Re: [gentoo-project] [RFC] glep-0076: add clarification about the sign-off requirements
Date: Wed, 28 Jul 2021 14:33:27
Message-Id: CAGfcS_kc9SNHN7KP=3RYoN17eSQWi6m+hW1jEWMOKOEGdqXJBQ@mail.gmail.com
In Reply to: Re: [gentoo-project] [RFC] glep-0076: add clarification about the sign-off requirements by Ulrich Mueller
1 On Wed, Jul 28, 2021 at 7:22 AM Ulrich Mueller <ulm@g.o> wrote:
2 >
3 > >>>>> On Wed, 28 Jul 2021, Andrew Ammerlaan wrote:
4 >
5 > > So if we allow contributions without a sign-off from the contributor
6 > > the sign-off from the developer is meaningless since neither 1, 2, 3,
7 > > or 4 applies to the commit.
8 >
9 > if there's even the slightest chance that the contribution could be
10 > taken from proprietary software, you are well-advised _not_ to accept it
11 > unless it carries a sign-off of its contributor.
12
13 In the US at least (and probably most countries), ALL code is
14 proprietary, unless the author of the code has released it under an
15 open source license.
16
17 If the original contributor hasn't signed off on the DCO, or somehow
18 otherwise communicated how they have licensed it, under what basis
19 would you conclude that it isn't anything other than proprietary
20 software? At best you'd have to determine whether the contribution is
21 so trivial as to not be copyrightable, and that seems like a road we
22 wouldn't want to go down. (Note: copyrightable patches to GPL
23 software are not automatically GPL, even if they are illegal to
24 distribute under anything other than the GPL. The author STILL has to
25 actively license it under the GPL, otherwise it basically becomes
26 non-distributable due to license conflict.)
27
28 Now, whether we want to require real names/etc from outside
29 contributors is another matter.
30
31 Part of the purpose of the DCO is to be a streamlined way for
32 contributors to communicate the copyright status of their
33 contributions. If we're not going to accept pseudonyms there, then it
34 doesn't make sense to instead accept them using non-standard wording
35 in random emails that are themselves backed only by a pseudonym, or
36 random non-logged conversations. If we are going to want committers
37 to somehow confirm that the contributor has made the contribution FOSS
38 then we might as well just have the contributors sign the DCO however
39 they wish since that at least systematically captures this event.
40
41 I'd suggest maybe clarifying that the real-name requirement only
42 applies to committers, and that the 4 elements of the DCO always
43 apply, and the 4th element can be accomplished by having the
44 contributor sign the DCO however they wish. Basically that would be
45 the status quo in terms of what is actually going on, as I understand
46 it.
47
48 --
49 Rich

Replies