1 |
On 2018-11-15 10:03 a.m., Rich Freeman wrote: |
2 |
> On Wed, Nov 14, 2018 at 4:00 PM Patrick McLean <chutzpah@g.o> wrote: |
3 |
>> |
4 |
>> I don't object to adding the copyright notice to the commit message |
5 |
>> rather than the ebuild, the only caveat is that the copyright should be |
6 |
>> propigated to the rsync tree as well (since most users use rsync rather |
7 |
>> than git). Perhaps the "fattening" step could do it, even just a |
8 |
>> top-level file listing packages and copyright owners, should not be |
9 |
>> overly hard to generate, maybe with a post-push hook that updates it |
10 |
>> when a copyright tag is detected in the push. |
11 |
> |
12 |
> IMO documenting copyright data in git would be a value-add, and could |
13 |
> potentially be assisted by repoman just as signed-off-by tags are. |
14 |
> |
15 |
> Whether it gets propagated to rsync I'll leave to others who care |
16 |
> more. Personally I don't get why we propagate anything other than the |
17 |
> ebuilds to rsync, but if rsync users want to punish themselves who am |
18 |
> I to argue with them? :) |
19 |
> |
20 |
>> |
21 |
>> IANAL nor do I pretend to be one. A lawyer did instruct me to add the |
22 |
>> copyright notices to ebuilds that I work on during work hours. |
23 |
> |
24 |
> In my experience corporate lawyers have a lot of incentive to do this |
25 |
> sort of thing. |
26 |
> |
27 |
> First, it costs them nothing to direct people to do this. It doesn't |
28 |
> really cost the company much either, so there won't be push-back |
29 |
> internally. |
30 |
> |
31 |
> It is also easy to explain a policy like this to a pointy-haired boss |
32 |
> type. It gets seen as "doing something" to protect the company as |
33 |
> well. Whether it actually is making a difference is another matter, |
34 |
> but it isn't like anybody is going to ever look into that. It isn't |
35 |
> adding any risk. |
36 |
> |
37 |
> At work I've seen far more costly policies than this established by |
38 |
> lawyers that are of dubious value to the company, but since the lawyer |
39 |
> doesn't get paid less if the policy is expensive, but they might lose |
40 |
> their job if anything bad happens, they have a lot of incentive to |
41 |
> enact every possible rule so that they can be seen as being innocent |
42 |
> if anything goes wrong. |
43 |
> |
44 |
> I think a lot of it just happens without any malicious intent. Lawyer |
45 |
> is asked for opinion, lawyer gives opinion. Everybody is happy. :) |
46 |
> |
47 |
>> |
48 |
>> AFAIK no one on this list/thread is a lawyer, so much if this is not |
49 |
>> particularly valuable. |
50 |
> |
51 |
> Well, if somebody who is a lawyer wants to add perspective I'm all |
52 |
> ears, but this is a community-based FOSS projects and decisions are |
53 |
> generally made based on arguments debated in public, and not "a friend |
54 |
> of a friend talked to a lawyer and got some free advice so we better |
55 |
> follow it." A lot of pros and cons have been presented for this |
56 |
> change, and those in charge can weigh them, but I've never really been |
57 |
> a fan of arguments that deference must be made to arguments that |
58 |
> aren't even presented simply due to somebody holding a credential. |
59 |
> |
60 |
>> Personally, I don't see why there is a strong objection to a practice that is quite common in open source code. |
61 |
> |
62 |
> I suspect that some of this is due to the nature of ebuilds themselves |
63 |
> and our workflow. |
64 |
> |
65 |
> If you have some file full of 2000 lines of source code, you're going |
66 |
> to spend all your time buried in whatever function you're refactoring |
67 |
> and you're not really looking at the boilerplate at the start of the |
68 |
> file. You might spend days looking at the file and your editor |
69 |
> remembers where you left off. You never even look at the copyright |
70 |
> notices and a few more lines isn't a big deal. You don't even look at |
71 |
> the other functions in the file you're editing but trust them to honor |
72 |
> their APIs. |
73 |
> |
74 |
> On the other hand Gentoo ebuilds might only be 10-20 lines long, and a |
75 |
> lot of the stuff that people are often looking at (keywords, iuse, |
76 |
> my_foo, etc) are right at the top. Often this stuff is "above the |
77 |
> fold" as they say. Sticking another half a dozen lines of cruft at |
78 |
> the top means that you're hunting more to find the stuff you care |
79 |
> about, and the copyright boilerplate could become half the file |
80 |
> contents in a file that is mostly boilerplate already. |
81 |
> |
82 |
> Maybe a compromise would be to stick all the copyright cruft at the |
83 |
> end of the file, but IMO it is better stored in git, preferably in |
84 |
> some standardized format that could be parsed by tools. |
85 |
> |
86 |
|
87 |
|
88 |
Quoting everything because I'm not sure exactly how to trim it, sorry. |
89 |
|
90 |
So it's still rather important to differentiate I think authorship and |
91 |
copyright notice; a big deal with the simplified copyright attribution |
92 |
is the fact that authorship (and therefore each author's individual |
93 |
copyright) *is* to be stored and accessed in git, or via an AUTHORS |
94 |
file if no VCS is present to store and track it (iirc). Therefore, |
95 |
yes, if an author's work submitted to git is copyright their employer |
96 |
it makes sense to me they should absolutely flag that in the commit |
97 |
itself. Is there a Copyright: tag in git to do that with? I don't |
98 |
think overriding 'Author:' to i.e. SIE would be a good idea... |
99 |
|
100 |
Similarly, robbat2's comment 31 in bug 670702 about needing an AUTHORS |
101 |
export from VCS will help with this as well -- rsync'ers could |
102 |
absolutely mask away that file (same as most did for the ChangeLog of |
103 |
old) but at least it'd be there as reference for legal purposes as |
104 |
necessary. |
105 |
|
106 |
----- |
107 |
|
108 |
As to SIE specifically, first off it doesn't matter what they were ok |
109 |
with in the past nor what reasons they have for requiring what they |
110 |
are right now -- the fact is their legal department right now DOES |
111 |
require this. It would be great if someone from the Foundation could |
112 |
talk to someone at SIE legal and work out a compromise on this |
113 |
copyright-notice issue so we can make it go away (ie convince them the |
114 |
notice is entirely not needed and their copyright is fully intact and |
115 |
enforced without it), but right now this is the world we live in so we |
116 |
gotta deal with it. Also there's no telling what another corporate |
117 |
entity might decide to do tomorrow, so one way or another I think we |
118 |
do have to set a hard policy and stick with it and accept said |
119 |
consequences (whichever way that goes). All of that to say, I don't |
120 |
think this is a futile bikeshed but we need to make it productively |
121 |
create something. |
122 |
|
123 |
---- |
124 |
|
125 |
This is a bit of a tangent but I think it's an important one in |
126 |
general to talk about. Also, it's possible a copyright lawyer might |
127 |
need to chime in on this stuff: |
128 |
|
129 |
How does i.e. SIE's copyright-notice rule work for patches contributed |
130 |
to b.g.o? And how does a copyright notice on a patch relate to the |
131 |
work that the patch will be applied to? I can see the patch itself |
132 |
carrying a copyright notice since that patch is the actual work that |
133 |
was authored, but when that patch is applied the *copyright notice* on |
134 |
that patch doesn't automatically get transferred, does it? |
135 |
|
136 |
By extension, technically, a commit that modifies lines in an existing |
137 |
file is equivalent to a patch that's submitted by other means and then |
138 |
applied, right? And that's technically what git does except that |
139 |
entire process internal and automatic,correct? |