1 |
I'm CCing this to gentoo-dev-announce since this has been a something |
2 |
high-profile topic, but all replies should stay on gentoo-nfp. |
3 |
|
4 |
In a previous thread there was discussion around the pros/cons of |
5 |
requiring copyright assignment to the Foundation. In general this was |
6 |
not well-supported, and we're increasingly finding ourselves in a |
7 |
position where we want to accept contributions from those who are |
8 |
unable/unwilling to assign copyrights, or where a work started outside |
9 |
of Gentoo but we wish to incorporate it. |
10 |
|
11 |
At recent Trustee meetings the consensus has been that we will not |
12 |
move in this direction. In order to avoid completely undirected |
13 |
bikeshedding we're tossing out a strawman for how we might move |
14 |
forward. This isn't policy - just a proposal for policy, and |
15 |
decisiveness shouldn't be confused for any unwillingness to discuss |
16 |
alternatives. |
17 |
|
18 |
With Regard to Copyright Assignment |
19 |
We'd like to propose that we create an agreement similar to the FSFe |
20 |
FLA and what is used by KDE to allow for VOLUNTARY assignment of |
21 |
copyright to the Gentoo Foundation. The more we can do this the |
22 |
simpler everything else below gets, and the more power the Foundation |
23 |
has to go after offenders. However, it will not be required that this |
24 |
be signed off on in order for anything to make its way into a Gentoo |
25 |
project (the tree, docs, associated software, etc). We'd come up with |
26 |
some mechanism for doing this electronically (details TBD) - nobody |
27 |
would be mailing around paper. It could be done retroactively as |
28 |
well. |
29 |
|
30 |
A list of those who have signed would be published, which may be |
31 |
helpful with teams that need to work out who owns what when |
32 |
attributing copyright (see below). |
33 |
|
34 |
|
35 |
With Regard to Licensing |
36 |
Per our social contract: |
37 |
We will release our contributions to Gentoo as free software, metadata |
38 |
or documentation, under the GNU General Public License version 2 (or |
39 |
later, at our discretion) or the Creative Commons - Attribution / |
40 |
Share Alike version 2 (or later, at our discretion). |
41 |
|
42 |
If we're not going to own copyright then the whole "at our discretion" |
43 |
bit doesn't really apply cleanly. We'd like to have a table (likely |
44 |
in xml and published on the website like various other similar tables) |
45 |
that lists Gentoo projects and their licensing requirements. Our |
46 |
policy should be to require those to be either GPL v2+ or CC BY-SA |
47 |
v2+, except as approved by the Trustees (generally this would be used |
48 |
to make exceptions for v2-only, or if somebody wants to request that a |
49 |
project be BSD). The intent with the 2+ bit isn't to exclude |
50 |
contributions so much as to at least not make v2-only a default, as it |
51 |
would be best for us to retain some flexibility to upgrade. |
52 |
|
53 |
With a list of required licenses there will be a requirement that |
54 |
anybody committing to Gentoo acknowledge that the work they commit is |
55 |
certified by them to be usable under the documented license. This |
56 |
declaration would accompany each commit. This will NOT be an |
57 |
assignment - just a declaration that the committer has done their |
58 |
homework. Implementation details TBD. Linux does it with the |
59 |
signed-off-by commit comments (specifically Developer Certificate of |
60 |
Origin, DCO [1]), and this could be used regardless of VCS, it just |
61 |
gets much easier with Git. Again, details are TBD and likely need to |
62 |
go by counsel. |
63 |
|
64 |
Note that a DCO would likely require the use of a real name when signing. |
65 |
|
66 |
|
67 |
With Regard to Copyright Attribution |
68 |
This is where all of this can get really messy. The existing policies |
69 |
around ebuilds/etc all starting out with the copyright <year> Gentoo |
70 |
Foundation would be replaced. We've yet to find much in the way of |
71 |
published policy for other FOSS projects around how much of a work |
72 |
needs to be covered by these attributions. We did find GNU mailing |
73 |
list traffic to suggest that they set the mark at 50%. It seems that |
74 |
our options are to either always list anybody who contributed so much |
75 |
as a character, or have some kind of threshold. Our initial |
76 |
suggestion is to start with the largest contributor and cover AT LEAST |
77 |
60% of the lines inside a file. No policy will prevent anybody from |
78 |
listing as many significant contributors as can be found, but to be |
79 |
compliant we'd require attribution for 60% of the lines. |
80 |
|
81 |
We propose that the copyright notice at the top of the file read: |
82 |
"Copyright <year> <Largest Contributor> and others (see below)." Then |
83 |
somewhere within the file there would be a list, or a reference to a |
84 |
closely-associated file containing a list, of contributors for no less |
85 |
than 60% of the lines of code in the file (again, this is a minimum |
86 |
only to allow us some wiggle room - best practice will be to list as |
87 |
many as can be found). The one-line notice must appear near the top, |
88 |
and the rest can appear anywhere - if just a reference to an external |
89 |
file the recommendation would be to put that near the top as well. The |
90 |
Changelog could be used for this purpose as long as it acknowledges |
91 |
the actual copyright holder of the code (acknowledging contributions |
92 |
is recommended in any case). |
93 |
|
94 |
Our ability to police this is going to be near-zero - we'll really be |
95 |
depending on devs to get it right, and we would of course respond to |
96 |
complaints. Git will make this easier, but since committer != owner |
97 |
that isn't perfect either. Repoman at best could look for the notice, |
98 |
but not ensure that the name is correct. |
99 |
|
100 |
We propose for grandfathering purposes that modifications may be made |
101 |
to existing files without any need to retroactively bring them into |
102 |
full compliance. New copyright owners should be added to the list, |
103 |
but for the purpose of this policy existing code is considered to |
104 |
count towards the 60% rule. This also applies to bumps/etc. As code |
105 |
is updated/replaced the goal is to slowly phase in the new policy and |
106 |
improve our overall legal clarity without burdening maintainers with |
107 |
having to go through a large exercise just to do a bump or change a |
108 |
few lines of code. |
109 |
|
110 |
There are a bunch of details TBD of course. Definitions around what |
111 |
constitutes a line and such should favor simplicity. |
112 |
|
113 |
|
114 |
So, please comment away. This isn't a detailed policy, but rather |
115 |
another step towards forming such a policy. We expect based on |
116 |
comments that the next thread on this topic will actually contain a |
117 |
detailed policy with review by counsel. To cut down on churn here your |
118 |
comments on overall direction will be important. |
119 |
|
120 |
Rich |
121 |
(For the Trustees) |
122 |
|
123 |
1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches#l298 |