[gentoo-dev-announce] Forming Gentoo Policy - Copyright Assignment and Attribution

[gentoo-dev-announce] Forming Gentoo Policy - Copyright Assignment and Attribution

[Rich Freeman]

I'm CCing this to gentoo-dev-announce since this has been a something
high-profile topic, but all replies should stay on gentoo-nfp.

In a previous thread there was discussion around the pros/cons of
requiring copyright assignment to the Foundation.  In general this was
not well-supported, and we're increasingly finding ourselves in a
position where we want to accept contributions from those who are
unable/unwilling to assign copyrights, or where a work started outside
of Gentoo but we wish to incorporate it.

At recent Trustee meetings the consensus has been that we will not
move in this direction.  In order to avoid completely undirected
bikeshedding we're tossing out a strawman for how we might move
forward.  This isn't policy - just a proposal for policy, and
decisiveness shouldn't be confused for any unwillingness to discuss
alternatives.

With Regard to Copyright Assignment
We'd like to propose that we create an agreement similar to the FSFe
FLA and what is used by KDE to allow for VOLUNTARY assignment of
copyright to the Gentoo Foundation.  The more we can do this the
simpler everything else below gets, and the more power the Foundation
has to go after offenders.  However, it will not be required that this
be signed off on in order for anything to make its way into a Gentoo
project (the tree, docs, associated software, etc).  We'd come up with
some mechanism for doing this electronically (details TBD) - nobody
would be mailing around paper.  It could be done retroactively as
well.

A list of those who have signed would be published, which may be
helpful with teams that need to work out who owns what when
attributing copyright (see below).


With Regard to Licensing
Per our social contract:
We will release our contributions to Gentoo as free software, metadata
or documentation, under the GNU General Public License version 2 (or
later, at our discretion) or the Creative Commons - Attribution /
Share Alike version 2 (or later, at our discretion).

If we're not going to own copyright then the whole "at our discretion"
bit doesn't really apply cleanly.  We'd like to have a table (likely
in xml and published on the website like various other similar tables)
that lists Gentoo projects and their licensing requirements.  Our
policy should be to require those to be either GPL v2+ or CC BY-SA
v2+, except as approved by the Trustees (generally this would be used
to make exceptions for v2-only, or if somebody wants to request that a
project be BSD).  The intent with the 2+ bit isn't to exclude
contributions so much as to at least not make v2-only a default, as it
would be best for us to retain some flexibility to upgrade.

With a list of required licenses there will be a requirement that
anybody committing to Gentoo acknowledge that the work they commit is
certified by them to be usable under the documented license.  This
declaration would accompany each commit.  This will NOT be an
assignment - just a declaration that the committer has done their
homework.  Implementation details TBD.  Linux does it with the
signed-off-by commit comments (specifically Developer Certificate of
Origin, DCO [1]), and this could be used regardless of VCS, it just
gets much easier with Git. Again, details are TBD and likely need to
go by counsel.

Note that a DCO would likely require the use of a real name when signing.


With Regard to Copyright Attribution
This is where all of this can get really messy.  The existing policies
around ebuilds/etc all starting out with the copyright <year> Gentoo
Foundation would be replaced.  We've yet to find much in the way of
published policy for other FOSS projects around how much of a work
needs to be covered by these attributions.  We did find GNU mailing
list traffic to suggest that they set the mark at 50%.  It seems that
our options are to either always list anybody who contributed so much
as a character, or have some kind of threshold.  Our initial
suggestion is to start with the largest contributor and cover AT LEAST
60% of the lines inside a file. No policy will prevent anybody from
listing as many significant contributors as can be found, but to be
compliant we'd require attribution for 60% of the lines.

We propose that the copyright notice at the top of the file read:
"Copyright <year> <Largest Contributor> and others (see below)."  Then
somewhere within the file there would be a list, or a reference to a
closely-associated file containing a list, of contributors for no less
than 60% of the lines of code in the file (again, this is a minimum
only to allow us some wiggle room - best practice will be to list as
many as can be found).  The one-line notice must appear near the top,
and the rest can appear anywhere - if just a reference to an external
file the recommendation would be to put that near the top as well. The
Changelog could be used for this purpose as long as it acknowledges
the actual copyright holder of the code (acknowledging contributions
is recommended in any case).

Our ability to police this is going to be near-zero - we'll really be
depending on devs to get it right, and we would of course respond to
complaints.  Git will make this easier, but since committer != owner
that isn't perfect either. Repoman at best could look for the notice,
but not ensure that the name is correct.

We propose for grandfathering purposes that modifications may be made
to existing files without any need to retroactively bring them into
full compliance.  New copyright owners should be added to the list,
but for the purpose of this policy existing code is considered to
count towards the 60% rule.  This also applies to bumps/etc.  As code
is updated/replaced the goal is to slowly phase in the new policy and
improve our overall legal clarity without burdening maintainers with
having to go through a large exercise just to do a bump or change a
few lines of code.

There are a bunch of details TBD of course.  Definitions around what
constitutes a line and such should favor simplicity.


So, please comment away.  This isn't a detailed policy, but rather
another step towards forming such a policy.  We expect based on
comments that the next thread on this topic will actually contain a
detailed policy with review by counsel. To cut down on churn here your
comments on overall direction will be important.

Rich
(For the Trustees)

1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches#l298

Re: [gentoo-dev-announce] Forming Gentoo Policy - Copyright Assignment and Attribution

[Robin H. Johnson]

Please note that the original message missed the Reply-To header.
Please direct all replies to gentoo-nfp or gentoo-dev. Do not reply to
gentoo-dev-announce directly.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev-announce] Re: Forming Gentoo Policy - Copyright Assignment and Attribution

[Rich Freeman]

On Mon, Feb 25, 2013 at 5:29 PM, Rich Freeman <rich0@gentoo.org> wrote:
> I'm CCing this to gentoo-dev-announce since this has been a something
> high-profile topic, but all replies should stay on gentoo-nfp.
>
> In order to avoid completely undirected
> bikeshedding we're tossing out a strawman for how we might move
> forward.  This isn't policy - just a proposal for policy, and
> decisiveness shouldn't be confused for any unwillingness to discuss
> alternatives.

To date there have been no responses.  If none are received this week
the Trustees are likely to move forward with enacting a policy similar
to what was described.  This might entail enlisting legal counsel.
(The final policy will be circulated for comment first, with the
caveat below.)

If you have any concerns/objections to the policy which was outlined,
which includes a mandatory requirement to sign a contributor license
agreement and an option to also sign an assignment-like document based
on the FSFe FLA, please speak up this week.  While we will of course
entertain comments on the final wording of the policy we do not want
to have any further debate on the overall direction once we start
bringing in lawyers.  This is not a good use of our volunteer's time,
and possibly even a modest amount of the Foundation's money (obviously
we will make every attempt to use the former before the latter).  Now
is the best time to make any big changes in our approach.

In short, speak now (on -nfp) or forever hold your peace...

Rich