1 |
On 11/24/18 9:22 PM, Rich Freeman wrote: |
2 |
> On Sat, Nov 24, 2018 at 9:04 PM Sarah White <kuzetsa@××××××××××.ovh> wrote: |
3 |
>> |
4 |
>> On 11/24/18 8:37 PM, Rich Freeman wrote: |
5 |
>> |
6 |
>> So if it isn't meant to say that gentoo will be looking |
7 |
>> after the legal aspects of a FOSS/Libre-copyleft licensed |
8 |
>> package or document or tool, then what's the purpose to |
9 |
>> put gentoo's name on it? |
10 |
> |
11 |
> You have to put somebody's name in the notice, and it was felt that |
12 |
> "Gentoo Authors" gets the job done. "Gentoo Authors" is not Gentoo. |
13 |
> They are the authors contributing to the ebuild. |
14 |
> |
15 |
>> There's some innuendo and/or implication that copyright |
16 |
>> holders who have their own name listed in a copyright |
17 |
>> notice are intending to do something other than participate |
18 |
>> in FOSS/Libre work, or perhaps may not truly wish to |
19 |
>> contribute in good faith. |
20 |
> |
21 |
> Not at all. The issue is that accumulating names creates clutter, and |
22 |
> create some sense that people who are named are doing more than people |
23 |
> who aren't named, which may lead to more people wanting to be named. |
24 |
> |
25 |
> This is also why the policy allows for an AUTHORS file or use of a |
26 |
> VCS. The intent isn't to deny people credit. It is to provide credit |
27 |
> in a more reasonable manner vs having it spammed on the first lines of |
28 |
> every file in the tree, and try to create a culture where we don't |
29 |
> equate copyright notice with credit or property. |
30 |
> |
31 |
>> Does gentoo have a legitimate reason |
32 |
>> to substitute a gentoo copyright notice in place of an |
33 |
>> otherwise valid notice? |
34 |
> |
35 |
> The GLEP already allows existing works that have a non-Gentoo notice |
36 |
> to keep their notice and add "and others" if there are further |
37 |
> additions if they are brought into Gentoo from outside. This doesn't |
38 |
> mean that we keep adding names to things. This was intended for |
39 |
> things like eudev where we took an entire mature code body and forked |
40 |
> it. This doesn't make as much sense for somebody contributing a 10 |
41 |
> line ebuild to a repository containing thousands of ebuilds. |
42 |
> |
43 |
>> Is there an intent to create a sort of gatekeeper role |
44 |
>> within the gentoo organization to request documentation |
45 |
>> if a contributor uses a non-gentoo copyright notice? |
46 |
> |
47 |
> As the GLEP stands developers are already gatekeepers by virtue of |
48 |
> being the only ones with commit access, and being required to sign off |
49 |
> on the DCO. This requires them to be aware of the copyright status of |
50 |
> the works they are committing, but we do not require the accumulation |
51 |
> of documentation. However, the GLEP does not provide for multi-line |
52 |
> notices and the intent isn't to keep accumulating them over time. The |
53 |
> intent was to be able to bring outside stuff in as-is as long as the |
54 |
> notices are reasonable and then just freeze them in time with "and |
55 |
> others" or simplify them with Gentoo Authors if appropriate. |
56 |
> |
57 |
|
58 |
|
59 |
Fair point. GLEP 76 even mentions commits in several places. |
60 |
|
61 |
[1] From GLEP 76 itself: |
62 |
|
63 |
["This policy documents how Gentoo contributors comply and |
64 |
document copyright for any contributions made to Gentoo."] |
65 |
|
66 |
Specifically the section: Copyright Attribution |
67 |
|
68 |
["It must list the main copyright holder, who is usually |
69 |
the original author, or the contributor holding copyright |
70 |
to the largest portion of the file."] |
71 |
|
72 |
But then the other section: Simplified Attribution |
73 |
|
74 |
... which contains some guidance for an alternative form: |
75 |
|
76 |
["Alternatively, projects are welcome to use a simplified |
77 |
form of the copyright notice, which reads:"] |
78 |
|
79 |
~ This word "alternatively", strongly implies that the |
80 |
default form should be used unless there is an overly |
81 |
complicated or long list of entities / people who hold |
82 |
copyright ~ at that point I agree with what you said: |
83 |
|
84 |
["... simplify them with Gentoo Authors if appropriate."] |
85 |
|
86 |
From a quick glance at bug #670702, I'm noticing there was |
87 |
some confusion about GLEP 76 layout conventions. [2] |
88 |
|
89 |
I think the confusing may have partly come from people who |
90 |
are experienced working with some of the better-known metadata |
91 |
formatting styles (for copyright, license, etc.) which is used |
92 |
in other organizations. |
93 |
|
94 |
Debian uses some SPDX-styled copyright formatting, along |
95 |
with some other (non-SPDX, possibly in-house) formats. |
96 |
It's an interesting mix, but still well-documented. [3] |
97 |
|
98 |
And as for SPDX itself, the full spec is far more exhaustive |
99 |
than anything gentoo or debian is using. Even the one-page |
100 |
summary for SPDX is well-written. Open standards exist, and |
101 |
I'm a fan of this one in particular. [4] |
102 |
|
103 |
This wording from GLEP 76 seems unambiguous to me: |
104 |
|
105 |
Exceptional circumstances are required for simplified |
106 |
attribution be more appropriate, compared to the default of |
107 |
a proper copyright notice which lists the entity whom held |
108 |
copyright when a contribution was made. |
109 |
|
110 |
-- kuza |
111 |
|
112 |
[1] https://www.gentoo.org/glep/glep-0076.html |
113 |
[2] https://bugs.gentoo.org/670702 |
114 |
[3] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ |
115 |
[4] https://spdx.org/sites/cpstandard/files/pages/files/spdx_onepager.pdf |