Gentoo Archives: gentoo-project

From: Patrick McLean <chutzpah@g.o>
To: Ulrich Mueller <ulm@g.o>
Cc: gentoo-project@l.g.o
Subject: Re: [gentoo-project] rfc: copyright attribution clarifications
Date: Wed, 14 Nov 2018 19:47:47
Message-Id: 20181114114739.23491a58@scorpius
In Reply to: Re: [gentoo-project] rfc: copyright attribution clarifications by Ulrich Mueller
1 On Wed, 14 Nov 2018 09:24:08 +0100
2 Ulrich Mueller <ulm@g.o> wrote:
3
4 > >>>>> On Wed, 14 Nov 2018, William Hubbs wrote:
5 >
6 > > On Tue, Nov 13, 2018 at 06:17:17PM -0800, Rich Freeman wrote:
7 > >> So, the purpose of allowing specific copyright holders to be named
8 > >> was to cover cases where we're forking foreign code, not to
9 > >> basically introduce a variant on the BSD advertising clause. IMO
10 > >> people who are only willing to contribute FOSS if their name gets
11 > >> put in a prominent location might do better to contribute
12 > >> elsewhere.
13 >
14 > +1000
15 >
16 > Maybe the policy for the Gentoo repository should just say that,
17 > namely that traditional copyright notices are only allowed for
18 > imported foreign code. Anything committed directly to the repository
19 > and any update of an existing file would be required to carry the
20 > simplified "Gentoo Authors" copyright notice, without any exceptions
21 > allowed.
22
23 So if SIE employees set up an official overlay, publish there first and
24 then "import" them to the tree it would pass that metric. That seems
25 like a silly extra step.
26
27 >
28 > > Do you feel this way about corporations as well? Do you think the
29 > > Linux kernel maintainers should go and rip out all copyright notices
30 > > other than Linus Torvalds and maybe the Linux Foundation?
31 >
32 > Why would corporations be different from individual authors? Under the
33 > legislation here, corporations cannot even hold copyright (or rather,
34 > Urheberrecht) of a work.
35
36 AFAIK that is not common in legal systems, certainly in the US (where
37 the Gentoo Foundation is based) copyrights can be held by any legal
38 entity, including a corporation or a nonprofit.
39
40 > >> The purpose of a copyright notice is to declare that the file is
41 > >> copyrighted, and that is it.
42
43 It is also to declare who owns the copyright, if it is to declare
44 simply that is is copyrighted, then one could add packages with the
45 text "Copyright 1999-2018" without any owner at all.
46
47 > >> It isn't a comprehensive list of everybody who holds a copyright on
48 > >> the file.
49 > >>
50
51 No it's not meant to be, it's a list of entities who hold copyright on
52 a file and want to be listed, this is different. I am not aware of any
53 open source project with a policy against copyright headers, or
54 different headers other than ones with copyright attribution. If you
55 are aware of such a project, please link the policy.
56
57 > >> It isn't a revision history.
58
59 And it is not meant to be.
60
61 > >> But, if you had to have multiple lines, then just wrap the existing
62 > >> notice. Don't turn it into some kind of revision history. Just
63 > >> list one year range and whatever list of entities you feel
64 > >> compelled to list. That is the proper way to do a notice.
65 >
66 > > No sir, it isn't.
67 >
68 > > Look anywhere outside the Gentoo tree. For that matter, take the
69 > > Linux kernel, or even in the systemd source, there are several
70 > > places with multiple copyright notices in them.
71 >
72 > Are these the only arguments you have?
73 >
74 > To say it again, ebuilds have a copyright notice for exactly two
75 > reasons:
76 >
77 > - to protect us against the "innocent infringement" defense under
78 > U.S. law, and
79 >
80 > - because the GPL-2 requires in section 1 to "appropriately publish
81 > on each copy an appropriate copyright notice".
82 >
83 > For both of these, it is irrelevant what the precise contents of the
84 > notice is. If you made a significant contribution to the file, then
85 > you can claim copyright for it, even if there is no copyright notice
86 > at all, of if you aren't mentioned in it.
87 >
88 > IANAL, but I think the case for being listed there explicitly is very
89 > weak.
90
91 Is accepting contributions form entities that require it a good
92 argument? Is this really worth losing valuable contributions over?
93
94 Please explain why this is a major issue worth this level of
95 discussion? Are a few lines at the top of the ebuild that can be easily
96 ignored or hidden by editors such a huge issue that you do not want to
97 accept any contributions that include it? Is this worth losing
98 developers and contributions over?

Replies