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 |