1 |
All, |
2 |
|
3 |
I need to ask the community a couple of questions about copyright |
4 |
attribution that came up this past couple of weeks around bug 670702 [1]. |
5 |
|
6 |
My first question is about the "Gentoo Authors" string. My understanding |
7 |
of this is that this string is to be only used in the simplified |
8 |
form of attribution and is not a generic catch-all that can be used in |
9 |
the traditional form. Does everyone agree with this? If so, this is |
10 |
somewhat problematic for traditional attribution, but I'll talk about |
11 |
that below. |
12 |
|
13 |
Since we do not do copyright assignment any more and the glep allows for |
14 |
traditional attribution, if some entity |
15 |
(company, person etc) has a desire for a copyright notice in |
16 |
their work, the case for not allowing this is very weak at best, so we will |
17 |
end up with more and more ebuilds that want to use traditional copyright |
18 |
attribution, and once an ebuild is switched over, it is problematic to |
19 |
switch back. |
20 |
|
21 |
Some in the council seem to want a tree policy that requires |
22 |
traditional attribution to be one and only one line at the top of ebuilds, e.g. |
23 |
|
24 |
# Copyright <years> [contributor1,] [contributor2,] [contributor3,] ... [contributorn] and others |
25 |
|
26 |
As you can see from my example, line length will quickly become |
27 |
problematic in this format because all lines in in-tree ebuilds are |
28 |
supposed to be under 80 characters. |
29 |
|
30 |
It is also problematic because the relationship between the years and |
31 |
contributors becomes unclear unless we allow ranges and single years in |
32 |
the copyright notice, which would lead to something like this: |
33 |
|
34 |
# Copyright <years1>, <years2>, <years3>, ... <yearsn+1> [contributor1,] [contributor2,] [contributor3,] ... [contributorn] and others |
35 |
|
36 |
This is going to have the same maintenance issues as traditional multiline |
37 |
attribution, but it is going to be very painful to maintain since it is |
38 |
all on one line. Multiple-lines would be much easier to maintain, and |
39 |
there is no cost performance wise for them. |
40 |
|
41 |
# Copyright <years1> <contributor1> |
42 |
# Copyright <years2> <contributor2> |
43 |
# Copyright <years3> <contributor3> |
44 |
# ... |
45 |
# Copyright <yearsn+1> others (or some catch-all like it) |
46 |
|
47 |
This seems to be a pretty compelling case for multiline traditional |
48 |
attribution. What do folks think? |
49 |
|
50 |
William |
51 |
|
52 |
[1] https://bugs.gentoo.org/670702 |
53 |
[2] https://www.gentoo.org/glep/glep-0076.html |