public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy
Date: Sun, 17 Jun 2018 09:00:54 +0200	[thread overview]
Message-ID: <23334.1830.170885.630788@a1i15.kph.uni-mainz.de> (raw)
In-Reply-To: <20180617123737.122ef070@katipo2.lan>

[-- Attachment #1: Type: text/plain, Size: 4737 bytes --]

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

> On Sun, 10 Jun 2018 22:34:45 +0200
> Ulrich Mueller <ulm@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

  parent reply	other threads:[~2018-06-17  7:01 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-10 20:34 [gentoo-project] [RFC] GLEP 76: Copyright Policy Ulrich Mueller
2018-06-10 20:49 ` Michał Górny
2018-06-11 16:20 ` Brian Evans
2018-06-11 16:25 ` NP-Hardass
2018-06-11 17:07   ` Rich Freeman
2018-06-11 18:08     ` NP-Hardass
2018-06-11 17:27   ` Ulrich Mueller
2018-06-11 17:57     ` NP-Hardass
2018-06-13 20:35     ` Ulrich Mueller
2018-06-13 20:44       ` William Hubbs
2018-06-17  2:18         ` Kent Fredric
2018-06-11 17:45   ` Michał Górny
2018-06-12  6:01   ` Matt Turner
2018-06-17  1:03 ` Kent Fredric
2018-06-17  1:39   ` Rich Freeman
2018-06-17  2:14     ` Kent Fredric
2018-06-17  2:34       ` Rich Freeman
2018-06-17  2:17     ` Aaron Bauman
2018-06-17  2:39       ` Rich Freeman
2018-06-17  2:52         ` Aaron Bauman
2018-06-17  3:30         ` Kent Fredric
2018-06-17  7:09           ` Ulrich Mueller
2018-06-17  7:00   ` Ulrich Mueller [this message]
2018-06-17  7:15     ` Kent Fredric
2018-06-17  7:38     ` Kent Fredric
2018-06-17  8:45       ` Ulrich Mueller
2018-06-17 20:12         ` Kristian Fiskerstrand
2018-06-17 20:37           ` Ulrich Mueller
2018-06-17 20:41             ` Kristian Fiskerstrand
2018-06-17 23:19               ` Kent Fredric
2018-06-19 17:30 ` [gentoo-project] [RFC] GLEP 76: Copyright Policy [v2] Ulrich Mueller
2018-06-23 19:39   ` Andreas K. Huettel
2018-06-23 21:57     ` Ulrich Mueller
2018-08-31 15:18   ` [gentoo-project] [RFC] GLEP 76: Copyright Policy [v3] Ulrich Mueller
2018-09-03 17:40     ` Ulrich Mueller
2018-09-08 11:43       ` Andrew Savchenko
2018-09-08 13:35         ` Ulrich Mueller
2018-09-08 18:17           ` Andrew Savchenko
2018-09-08 18:55             ` Ulrich Mueller
2018-09-08 19:20               ` Justin Lecher
2018-09-08 23:38               ` Andrew Savchenko
2018-09-09  6:15                 ` Ulrich Mueller
2018-09-08 14:25       ` Michael Orlitzky
2018-09-08 17:09         ` Michał Górny
2018-09-08 17:36         ` Ulrich Mueller
2018-09-26 19:25     ` [gentoo-project] [RFC] GLEP 76: Copyright Policy [v4] Ulrich Mueller
2018-09-27  5:00       ` kuzetsa
2018-09-27 12:00       ` NP-Hardass
2018-09-27 12:42         ` Rich Freeman
2018-09-27 13:08           ` kuzetsa
2018-09-27 13:43             ` Rich Freeman
2018-09-27 14:14               ` kuzetsa
2018-09-27 13:52           ` NP-Hardass
2018-09-27 14:13             ` Rich Freeman
2018-09-27 14:24               ` NP-Hardass
2018-09-27 14:32               ` kuzetsa
2018-09-29  3:15               ` desultory
2018-09-29  7:08               ` Kent Fredric
2018-09-29  9:13                 ` Ulrich Mueller
2018-09-27 14:32             ` Michał Górny
2018-09-27 14:40               ` kuzetsa
2018-09-28  9:39       ` kuzetsa
2018-09-29  7:46         ` Ulrich Mueller
2018-10-02 20:29           ` NP-Hardass
2018-10-02 21:23             ` Michał Górny
2018-10-03 15:48             ` Ulrich Mueller
2018-10-03 19:16               ` Andrew Savchenko
2018-10-03 19:28                 ` Rich Freeman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=23334.1830.170885.630788@a1i15.kph.uni-mainz.de \
    --to=ulm@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox