1 |
On Wed, Dec 16, 2015 at 6:43 AM, Alexander Berntsen <bernalex@g.o> wrote: |
2 |
> |
3 |
> I agree with Mike that this isn't kosher. It just isn't honest. |
4 |
> |
5 |
|
6 |
I don't really have a horse in this race, but I don't see how this is |
7 |
dishonest. What is being proposed is moving from attribution |
8 |
scattered all over the place to attribution in a single place. Nobody |
9 |
who is credited in a file today wouldn't still be credited in the |
10 |
proposed system. They'll just be credited side-by-side with everybody |
11 |
else in once place. |
12 |
|
13 |
I'm sure you'll be able to find somebody who will be offended if we |
14 |
move their name from /src/a/b/randomfile to /AUTHORS but finding |
15 |
people offended by things that happen with FOSS is pretty easy to do. |
16 |
|
17 |
> On 15/12/15 20:37, William Hubbs wrote: |
18 |
>> Multiple entries are what I want to get away from; it is a |
19 |
>> nightmare to maintain, and the vcs shows far better than you or I |
20 |
>> ever could which code belongs to who (see git blame). That is what |
21 |
>> the site I linked talks about. |
22 |
> Using a VCS to track attribution is what's a nightmare. Using git |
23 |
> blame on a source file will usually just tell you who last reindented |
24 |
> the file for stylistic preference. Actually finding out something |
25 |
> worth knowing is a lot more work. |
26 |
|
27 |
Git blame is simplistic, but attribution is a nightmare no matter how |
28 |
you look at it, unless you just define it as a list of anybody who |
29 |
committed to a file, in which case git can answer that question for |
30 |
you rather easily. This is part of why we still haven't come up with |
31 |
a better copyright policy for the main tree - when you try to make |
32 |
things more rigorous the effort to maintain things can go up really |
33 |
quickly (patch authors, people who have assigned/licensed their |
34 |
contributions to Gentoo, borrowed/forked code from other projects, |
35 |
etc). |
36 |
|
37 |
I think part of the problem is that we're looking for perfect |
38 |
solutions, and holding onto bad solutions until one is found, which |
39 |
will probably never happen. |
40 |
|
41 |
There seems to be also a tendency to give advice like "talk to a |
42 |
lawyer or so-and-so" with the perhaps well-intended meaning of only |
43 |
moving forward if there is no risk of problems. It needs to be kept |
44 |
in mind that there are often problems with keeping things as they are, |
45 |
and there are often problems with change. In the area of copyright in |
46 |
the US there are rarely any approaches that are free of risk, and the |
47 |
ones with the least risk may also be the ones which are the most |
48 |
rigorous or inconvenient to implement. No lawyer can tell you what |
49 |
the right level of risk acceptance is, but they can tell you a list of |
50 |
all the bad things that can happen to you with any option. |
51 |
|
52 |
Most companies accept legal risk every day, often intentionally. It |
53 |
has to be balanced against the mission of the organization. That |
54 |
doesn't mean that we should be doing things that are wrong, of course. |
55 |
|
56 |
So, we should of course be talking to a lawyer anytime we add a |
57 |
package with a new license to the tree, or change our copyright |
58 |
policy, or make big changes to attribution like these. However, you |
59 |
need to go into such things with a balanced view, or all you'll end up |
60 |
doing is pursing the most conservative possible approach every time, |
61 |
or maintaining the status quo. I suspect there are MANY accepted |
62 |
practices in Gentoo that a lawyer would advise caution regarding |
63 |
(libdvdcss, just about anything involving -bindist, half of the |
64 |
oddball-license packages in the tree, anything with |
65 |
RESTRICT=mirror/fetch, kernel fat32 support, and so on). |
66 |
|
67 |
So, by all means talk to a lawyer/etc. However, I'd tend to advocate |
68 |
a balanced approach, and not necessarily a zero-risk approach. On the |
69 |
list of risks to Gentoo I'm not sure the way OpenRC authors are |
70 |
tracked really ranks super-high. |
71 |
|
72 |
-- |
73 |
Rich |