public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-project <gentoo-project@lists.gentoo.org>
Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy
Date: Sat, 16 Jun 2018 21:39:49 -0400	[thread overview]
Message-ID: <CAGfcS_kJNud8s4qaKiEWeRT2089YgnSD0UcDoMShhUvM25ZZ=Q@mail.gmail.com> (raw)
In-Reply-To: <20180617123737.122ef070@katipo2.lan>

On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric <kentnl@gentoo.org> wrote:
>
> This idea to me is just asking for trouble, given the aformentioned
> factors.
>

What kind of, "trouble?"

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

Why does this have to be reliable?

> So given that, as it stands, automating this is either:
>
> a) hard
> b) impossible
>
> And subsequently, manually doing it will tend towards those entries
> quickly becoming wrong.

How is that a problem?  Also, this assumes that the main copyright
holder on something we distribute actually changes often.

There really isn't any negative consequence to the person listed on a
copyright notice being "wrong" as far as I can tell.  I use quotes
because as long as the person listed contributed SOMETHING to the file
the statement is still accurate, even if non-ideal.  I doubt a court
is going to decide a case differently because the person listed on the
copyright notice wrote 20% of a file vs somebody else who wrote 40%.
As far as I'm aware the name listed on a copyright notice isn't
binding at all on a court - the court is free to determine who
actually owns the copyright based on the facts of the situation.  The
notice simply serves to inform the recipient of a work that it IS
copyrighted, so that they can't claim innocent infringement.  The work
remains copyrighted all the same if the notice is not present, and
future infringement after receiving notice would not be innocent
regardless.

> And to add insult to injury, changing these entries via either
> mechanism produces source of commit churn and conflicts

Only if you try to constantly adjust things.

If you just wait until somebody points out an inaccuracy (which is all
the policy requires), then these commits will be rare.

> And around about here you ask "what's the point?". A lot of work, for
> negligible benefit.

The policy doesn't require much work.  The parts that suggested that
it needed to be maintained in realtime were removed, for exactly the
reasons you have elaborated on.

The intent here is not to have devs constantly checking the copyright
notices on every commit.  It simply states what they are intended to
contain.

>
> 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.
>

Well, one of the main benefits is that people won't feel like they
have to replace all the copyright notices with ones that reference
Gentoo when they put these files on Gentoo infra (such as what
happened with eudev).

As far as real problems go, just don't touch the copyright lines
except to add "and others" and there won't be many issues.

If somebody makes a huge rewrite they can always add themselves to the
notice as the main contributor if they wish.

I definitely don't think automating the notices is a good idea.  For
example, in the eudev repository the file src/scsi_id/scsi_id.c has
IBM/SUSE copyright notices on it, and that isn't what your git log
command would output.  That was just the first random file in that
repository I checked.

Overall the intent of the policy (after the various rewrites) was to
try to give reasonable instructions as to how the notice should be
written, but not to suggest that developers need to put a great deal
of effort into making it precise.

-- 
Rich


  reply	other threads:[~2018-06-17  1:40 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 [this message]
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
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='CAGfcS_kJNud8s4qaKiEWeRT2089YgnSD0UcDoMShhUvM25ZZ=Q@mail.gmail.com' \
    --to=rich0@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