Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy

[Ulrich Mueller]

>>>>> On Sun, 17 Jun 2018, Kent Fredric wrote:

> On Sun, 10 Jun 2018 22:34:45 +0200
> Ulrich Mueller <ulm@g.o> wrote:

>> - Gentoo projects must release their work under GPL-compatible free
>> software licenses, preferably under GPL-2 or later. CC-BY-SA-3.0
>> (or 4.0) can be used for documentation.
>>
>> - All commits to Gentoo repositories must be accompanied by a
>> certificate of origin. Typically, this would be declared by adding
>> a "Signed-off-by:" line (or several of them) to every commit.
>> This model is very similar to the one used for development of the
>> Linux kernel.

> Using the Linux kernel as a reference point, while amicable, is somewhat a
> dangerous line of reasoning here. Partly, because we have several
> significant differences in practice from that project, and "we both use
> Git" is insufficient.

> - We don't have the hierarchy of Marshals who process their lowers
>   contributions. The closest we have to this is Gentoo-Proxy-Maint, but
>   besides that, we have a wild west free-for-all where commits are
>   essentially unmonitored, there is no structural/procedural oversight
>   where higher privileges vet the contributions of lower privileges.

> - We cannot rely on copy/move detection in any reasonable fashion, as:
> 	1. File names are significant data which have source-time
> 	consequences.

> 	2. File contents are incredibly regular, having high similarity
> 	to huge volumes of the tree, making a statistical percentage
> 	similarity basis prone to misdetection.

> 	3. We routinely employ "copy the file to increment its version"
> 	logic, which is practically unseen outside Gentoo, partly,
> 	because the reliance on filenames as a versioning system is
> 	"you're too poor to have a real VCS", typically speaking, and
> 	we only really have it as a historical wart from how we
> 	evolved. Such an idea is typically nonsense if you can rely on
> 	a VCS to handle versioning for you.

> These factors basically make our workflow, and the nature of the work
> we do substantially different from the Kernel project, and most other
> projects.

I don't see how any of this would prevent a committer from adding a
Signed-off-by line.

>> - The copyright notice, especially for ebuilds, will contain the
>> name of the largest contributor, plus an "and others" clause when
>> necessary. (So the "Copyright Gentoo Foundation" lines will be
>> phased out.)

> This idea to me is just asking for trouble, given the aformentioned
> factors.

> The need to update copyright year is already a minor burden, smoothed
> over slightly by the fact repoman can reliably fix it on its own.

> Reliably handling contribution factors however seems difficult, given
> the stock output given by "git blame" is routinely wrong due to how or
> workflow operates.

We'll get rid of the line counting in the next iteration of the GLEP
(to be posted soon), and replace the wording by "the original author,
or the contributor holding copyright to the largest portion of the
file." So there will be no need to check the accuracy of the copyright
notice with every update of an ebuild, because it is a derived work of
its previous version. However, the copyright notice can be updated
when the ebuild is rewritten from scratch.

> ( For example, attribution for every virtual/perl-*/*.ebuild should
> trace back to 56bd759df1d0c750a065b8c845e93d5dfa6b549d when robbat2
> committed the first incarnation of those files, as there are many lines
> that haven't changed since then, but my Git Fu doesn't know of a way to
> reliably do this without manually implementing new tools that are
> portage-semantics aware and do log processing, and I say that while
> actively developing tools that scrape git fast-export to attempt to do
> something remotely like this, but its quickly approaching the limits of
> what can be done in a week, let alone regularly )

See above, we won't do line counting which is unreliable in any case.
For example, someone who adds or removes a "|| die" would get
accounted for that line.

> So given that, as it stands, automating this is either:

> a) hard
> b) impossible

This is obvious, but it is not our aim to automate it.

> [...]

> IN SUMMARY:

> The nature of the proposed changes seems strongly in conflict with the
> technology we have to use, and will produce no benefit, at the expense
> of real problems.

It is quite simple, we cannot put the Gentoo Foundation into copyright
notices, when no copyright assignment took place.

Even the requirement that every contributor must sign an FLA would not
help us there. IIUC we still wouldn't be allowed to use Foundation
copyright notices, because the FLA only grants a license but doesn't
assign copyright.

Ulrich