Gentoo Archives: gentoo-project

From: Alec Warner <antarus@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] rfc: copyright attribution clarifications
Date: Sat, 24 Nov 2018 20:32:42
Message-Id: CAAr7Pr_=hdn3vvF4xvs3NMN-d7ZQ7hf704qN+8XgfBnKqsbzDg@mail.gmail.com
In Reply to: Re: [gentoo-project] rfc: copyright attribution clarifications by Rich Freeman
1 On Sat, Nov 24, 2018 at 3:12 PM Rich Freeman <rich0@g.o> wrote:
2
3 > On Sat, Nov 24, 2018 at 2:41 PM Alec Warner <antarus@g.o> wrote:
4 > >
5 > > On Sat, Nov 24, 2018 at 12:47 PM William Hubbs <williamh@g.o>
6 > wrote:
7 > >>
8 > >> This is what concerns me as well. All of the folks in this thread who
9 > >> want to forbid multiline copyright notices have yet to convince me that
10 > >> there is a technical argument for doing so.
11 > >
12 > > I don't believe the technical arguments have much basis; instead the
13 > argument is about community and humanpower.
14 >
15 > I've yet to see any technical arguments. I certainly haven't made any.
16 >
17
18 There were definitely some made earlier in the discussion.
19
20
21 >
22 > There is no technical reason to allow multi-line notices, and there is
23 > no technical reason to forbid them. This is entirely a non-technical
24 > issue.
25 >
26 > I think they should be forbidden for a number of non-technical reasons:
27 >
28 > 1. They add clutter to ebuilds. At the very least they should be put
29 > at the bottom of ebuilds and not at the top, and anybody editing an
30 > ebuild should be free to move a multiline notice to the bottom if they
31 > see it at the top.
32 >
33
34 So now you don't if the notices exist, as long as they are at the bottom of
35 the file? It seems inconsistent with the rest of your position ;)
36
37
38 >
39 > 2. It strikes me as being fairly anti-community. Basically the
40 > companies that give us the most trouble get to stick their names all
41 > over ebuilds, while freely benefitting from hundreds of other ebuilds
42 > that others have contributed without any care for sticking their names
43 > on stuff. Sony should be contributing because they want to
44 > contribute, not to stick their names on things. Or if they want to
45 > sponsor us they should do so under the normal terms for doing so,
46 > which generally involve more than contributing a couple of lines of
47 > ebuild boilerplate.
48 >
49
50 So this argument is basically; we don't understand why Sony wants to put
51 their name on the notice. In lieu of any facts, we will tell our own
52 narrative; anyone that causes trouble is a baddie; Sony is causing trouble,
53 therefore, Sony is 'anti-community', or 'name-grabbing' or whatever.
54
55
56 > 3. It opens up a slippery slope. Once you say one person can stick
57 > their names on something, how long until everybody and their uncle
58 > starts doing it and an ebuild with a long history like glibc has three
59 > pages of contributor names at the top (and IMO glibc is one of those
60 > few ebuilds that actually seems non-trival)?
61 >
62
63 I think you can easily look at other projects that let anyone stick their
64 name on anything to see what happens...I'm not sure this is a strong
65 argument against. These other projects seem fine and are not overflowing
66 with copyright notices.
67
68
69 >
70 > 4. The people digging in to try to force this policy have no interest
71 > in participating in the Gentoo community, or actually advocating for
72 > their position. It seems that they simply consider their position
73 > undebatable and expect us to just accept it because heaven forbid one
74 > developer not be allowed to contribute during business hours, despite
75 > many others having no issues with this at all since their employers
76 > are more reasonable.
77 >
78
79 I assert that you don't know anything about their reasons, their rationale,
80 their reasonableness or anything really. "People who have conflicts are
81 unreasonable" is really what I hear from this kind of speech and its not
82 really a great message to send.
83
84
85 >
86 > IMO Gentoo (and the members of its community) should be using this as
87 > an opportunity to tarnish Sony's reputation, not bend over backwards
88 > to cater to a random request of a company lawyer who seemingly isn't
89 > interested in actually discussing their policy. This isn't Sony
90 > contributing to open source, this is Sony interfering with what has
91 > basically been routine practice in the community for 15-20 years.
92 >
93
94 I'm going to tell you the same thing I told Whissi on #-council
95
96 I think it is an entirely reasonable position to do the following:
97 - Not accept the SEI notices because we do not understand the grounds on
98 which they are added.
99 - Ask SEI for a rationale for what the notices are meant to convey, so we
100 can decide if we can support whatever that use case is; maybe its something
101 we didn't consider in the GLEP.
102
103 I don't think its reasonable to say they are mean shitheads; because the
104 fact is we don't know what they want to accomplish with the notices. My
105 concern is that they may later provide a reasonable use case for the
106 notices and the council will just say 'well that use case is stupid because
107 Sony is stupid'; because that is the message many members of the council
108 are currently communicating. Why would Sony even bother if the narrative is
109 the Council won't listen anyway? It looks like a waste of their time.
110
111 I think the above proposal puts the ball clearly in SEI's court; if they
112 want the notices accepted they can provide a memo detailing why. If they
113 don't care, they can drop the notices or stop committing.
114
115 -A
116
117
118 > --
119 > Rich
120 >
121 >

Replies