Gentoo Archives: gentoo-project

From: NP-Hardass <NP-Hardass@g.o>
To: gentoo-project@l.g.o, Rich Freeman <rich0@g.o>
Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy
Date: Mon, 11 Jun 2018 18:08:46
Message-Id: e8eab4d3-2f52-b70f-1b54-fcece76b3f03@gentoo.org
In Reply to: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy by Rich Freeman
1 On 06/11/2018 01:07 PM, Rich Freeman wrote:
2 > On Mon, Jun 11, 2018 at 12:25 PM NP-Hardass <NP-Hardass@g.o> wrote:
3 >>
4 >> On 06/10/2018 04:34 PM, Ulrich Mueller wrote:
5 >>
6 >>> Copyright Attribution
7 >>> ---------------------
8 >>>
9 >>> All files included in Gentoo projects must contain an appropriate
10 >>> copyright notice, as defined by this policy.
11 >>>
12 >>> A proper copyright notice appears near the top of the file, and reads::
13 >>>
14 >>> Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others
15 >>>
16 >>> The largest contributor is whatever entity owns copyright to some
17 >>> portion of the largest number of lines in the file. Additional
18 >>> contributors can be listed, but this is neither required nor
19 >>> recommended. The "and others" text may be omitted if the explicitly
20 >>> listed contributors hold copyright to the entire file.
21 >>
22 >> Why is this not recommended?
23 >
24 > So, I came up with this to try to keep it as simple as possible.
25 >
26 > My concern was basically analogous to the BSD advertising clause
27 > problem. If you start accumulating authors on this line then it gets
28 > unwieldy. How do you draw the line?
29 >
30 > I suggested drawing the line at whoever touched the most lines, mainly
31 > because it is simple.
32 >
33 > IMO ANY solution is going to be imperfect, so simple trumps all.
34 >
35 > But, it certainly isn't the only possible solution to this problem.
36 >
37 > Keep in mind that notice is not the same as
38 > authorship/copyright/credit/etc. The "and others" is important.
39 > Being #2 doesn't in any way diminish your rights under the law. The
40 > law simply requires a notice, so we need to come up with one. It
41 > shouldn't be viewed as "this is the only important contributor to this
42 > file." If we could not have any notice at all legally then that would
43 > be simpler still. Git already tracks who did what, and should always
44 > be the place to go for this info.
45 >
46 >> If developer A writes 51% of the lines of an ebuild and developer B
47 >> writes 49%, should B not be listed?
48 >
49 > Under the policy, no.
50 >
51 >> What if all the metadata lines defining variables consists of 75% of the
52 >> file and was written by A, but the core functionality of the ebuild (25%
53 >> by size) was written by B?
54 >
55 > Under the policy, "A and others" is listed.
56 >
57 >> If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,
58 >> should B remove A from attribution?
59 >
60 > Under the policy, yes, assuming this is noticed. The policy does not
61 > require checking on every commit, but only when the issue is
62 > escalated. That is actually a change from the wording which tried to
63 > keep things more strict.
64 >
65 >> I think that specifying that substantial (though not necessarily
66 >> specific in defining this) contributions/contributors should included in
67 >> the copyright attribution and that substantial contribution attribution
68 >> *is* recommended.
69 >
70 > So, the issue then becomes whether we have to define "substantial."
71 > The goal is to have something actionable. Anybody can run git blame
72 > easily enough. Figuring out what is "substantial" is harder.
73 >
74 > But, the other change to the policy was to relax this and not worry
75 > about keeping it as up to date. So, in that spirit maybe we can be
76 > more vague and let it be dealt with via escalation.
77 >
78 > That seems to be the approach the Linux Foundation takes. As far as I
79 > can tell they have no policy regarding copyright notice - and the
80 > contents of their files are all over the place. Presumably committers
81 > make their own judgement calls, and if somebody has a problem with it
82 > they point it out to the Linux Foundation.
83 >
84 > That said, the fact that this is basically happened with the eudev
85 > copyright notices didn't prevent it from turning into a bit of a
86 > tempest in a teapot with all kinds of accusations being tossed around.
87 > It was dealt with upon escalation, but people tend to go crazy over
88 > this stuff so some kind of policy that an ordinary dev can understand
89 > wouldn't hurt, so that the issue is prevented. That was the goal of
90 > the policy.
91 >
92 > A big goal here was to keep it simple and understandable but not too
93 > vague. It shouldn't need constant appeals to Trustees/Council/whoever
94 > to apply to individual situations.
95 >
96 > To the extent that the notice doesn't truly give credit to
97 > contributors I'd call it a feature and not a bug. I'd rather have the
98 > notices viewed as useless for that purpose, because then people won't
99 > constantly squabble about how does/doesn't get included on them. The
100 > ideal choices would be listing everybody or nobody, but everybody is
101 > cumbersome, and nobody doesn't seem to be legally valid. So, listing
102 > one by name preserves the nonsensical nature of the notice while still
103 > meeting the legal requirement. Or something like that...
104 >
105
106 Keeping it simple is fine by me. As mentioned in my other reply to Ulm,
107 I think I was conflating contribution attribution and copyright
108 assignment. As long as "and others" (being unnamed) doesn't prevent
109 others from retaining their copyright (in practice as opposed to in
110 principle), SGTM.
111
112
113 --
114 NP-Hardass

Attachments

File name MIME type
signature.asc application/pgp-signature