1 |
On Sat, 16 Jun 2018 21:39:49 -0400 |
2 |
Rich Freeman <rich0@g.o> wrote: |
3 |
|
4 |
> On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric <kentnl@g.o> wrote: |
5 |
> |
6 |
> There really isn't any negative consequence to the person listed on a |
7 |
> copyright notice being "wrong" as far as I can tell. I use quotes |
8 |
> because as long as the person listed contributed SOMETHING to the file |
9 |
> the statement is still accurate, even if non-ideal. I doubt a court |
10 |
> is going to decide a case differently because the person listed on the |
11 |
> copyright notice wrote 20% of a file vs somebody else who wrote 40%. |
12 |
> As far as I'm aware the name listed on a copyright notice isn't |
13 |
> binding at all on a court - the court is free to determine who |
14 |
> actually owns the copyright based on the facts of the situation. The |
15 |
> notice simply serves to inform the recipient of a work that it IS |
16 |
> copyrighted, so that they can't claim innocent infringement. The work |
17 |
> remains copyrighted all the same if the notice is not present, and |
18 |
> future infringement after receiving notice would not be innocent |
19 |
> regardless. |
20 |
|
21 |
Surely then, the most effective and usefully correct copyright notice |
22 |
(for portage trees at least), would be: |
23 |
|
24 |
"Copyright Gentoo Foundation and Contributors" |
25 |
|
26 |
Or similar, instead of abandoning the Gentoo Foundation Copyright and using |
27 |
a random persons name? |
28 |
|
29 |
Otherwise most of the proposal in regards to portage trees, is mostly a |
30 |
waste of time. |
31 |
|
32 |
> (So the "Copyright Gentoo Foundation" lines will be |
33 |
> phased out.) |
34 |
|
35 |
Because otherwise, the objective of putting a humans name there is |
36 |
misleading at best, and serves no objective purpose. |
37 |
|
38 |
If the objective is to simply denote the file has a copyright, that |
39 |
format should do the job. |
40 |
|
41 |
( Additionally, I have no opposition to generating a package-wide |
42 |
file that notates contributors, such an approach is routinely |
43 |
satisfactory for debian with regards to marking up which files have |
44 |
which licenses without needing to inject the license in the file, and |
45 |
has the benefit of exposing that metadata to consumers who only access |
46 |
via rsync or tarballs, its just in-band in-git data that I find most |
47 |
obnoxious due to being functionally redundant ) |