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 |
> |