Gentoo Archives: gentoo-project

From: Ian Stakenvicius <axs@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] rfc: copyright attribution clarifications
Date: Thu, 15 Nov 2018 15:52:40
Message-Id: aba29339-d20b-7787-8455-7dde033876c5@gentoo.org
In Reply to: Re: [gentoo-project] rfc: copyright attribution clarifications by Rich Freeman
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?

Attachments

File name MIME type
signature.asc application/pgp-signature