public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: NP-Hardass <NP-Hardass@gentoo.org>
To: gentoo-project@lists.gentoo.org, Rich Freeman <rich0@gentoo.org>
Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy
Date: Mon, 11 Jun 2018 14:08:39 -0400	[thread overview]
Message-ID: <e8eab4d3-2f52-b70f-1b54-fcece76b3f03@gentoo.org> (raw)
In-Reply-To: <CAGfcS_kpW3Q=J-TtSM+dfqPeJh1xWLGAdXNfwdYkdhAYhawhvg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 5206 bytes --]

On 06/11/2018 01:07 PM, Rich Freeman wrote:
> On Mon, Jun 11, 2018 at 12:25 PM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>
>> On 06/10/2018 04:34 PM, Ulrich Mueller wrote:
>>
>>> Copyright Attribution
>>> ---------------------
>>>
>>> All files included in Gentoo projects must contain an appropriate
>>> copyright notice, as defined by this policy.
>>>
>>> A proper copyright notice appears near the top of the file, and reads::
>>>
>>>     Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others
>>>
>>> The largest contributor is whatever entity owns copyright to some
>>> portion of the largest number of lines in the file.  Additional
>>> contributors can be listed, but this is neither required nor
>>> recommended.  The "and others" text may be omitted if the explicitly
>>> listed contributors hold copyright to the entire file.
>>
>> Why is this not recommended?
> 
> So, I came up with this to try to keep it as simple as possible.
> 
> My concern was basically analogous to the BSD advertising clause
> problem.  If you start accumulating authors on this line then it gets
> unwieldy.  How do you draw the line?
> 
> I suggested drawing the line at whoever touched the most lines, mainly
> because it is simple.
> 
> IMO ANY solution is going to be imperfect, so simple trumps all.
> 
> But, it certainly isn't the only possible solution to this problem.
> 
> Keep in mind that notice is not the same as
> authorship/copyright/credit/etc.  The "and others" is important.
> Being #2 doesn't in any way diminish your rights under the law.  The
> law simply requires a notice, so we need to come up with one.  It
> shouldn't be viewed as "this is the only important contributor to this
> file."  If we could not have any notice at all legally then that would
> be simpler still.  Git already tracks who did what, and should always
> be the place to go for this info.
> 
>> If developer A writes 51% of the lines of an ebuild and developer B
>> writes 49%, should B not be listed?
> 
> Under the policy, no.
> 
>> What if all the metadata lines defining variables consists of 75% of the
>> file and was written by A, but the core functionality of the ebuild (25%
>> by size) was written by B?
> 
> Under the policy, "A and others" is listed.
> 
>> If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,
>> should B remove A from attribution?
> 
> Under the policy, yes, assuming this is noticed.  The policy does not
> require checking on every commit, but only when the issue is
> escalated.  That is actually a change from the wording which tried to
> keep things more strict.
> 
>> I think that specifying that substantial (though not necessarily
>> specific in defining this) contributions/contributors should included in
>> the copyright attribution and that substantial contribution attribution
>> *is* recommended.
> 
> So, the issue then becomes whether we have to define "substantial."
> The goal is to have something actionable.  Anybody can run git blame
> easily enough.  Figuring out what is "substantial" is harder.
> 
> But, the other change to the policy was to relax this and not worry
> about keeping it as up to date.  So, in that spirit maybe we can be
> more vague and let it be dealt with via escalation.
> 
> That seems to be the approach the Linux Foundation takes.  As far as I
> can tell they have no policy regarding copyright notice - and the
> contents of their files are all over the place.  Presumably committers
> make their own judgement calls, and if somebody has a problem with it
> they point it out to the Linux Foundation.
> 
> That said, the fact that this is basically happened with the eudev
> copyright notices didn't prevent it from turning into a bit of a
> tempest in a teapot with all kinds of accusations being tossed around.
> It was dealt with upon escalation, but people tend to go crazy over
> this stuff so some kind of policy that an ordinary dev can understand
> wouldn't hurt, so that the issue is prevented.  That was the goal of
> the policy.
> 
> A big goal here was to keep it simple and understandable but not too
> vague.  It shouldn't need constant appeals to Trustees/Council/whoever
> to apply to individual situations.
> 
> To the extent that the notice doesn't truly give credit to
> contributors I'd call it a feature and not a bug.  I'd rather have the
> notices viewed as useless for that purpose, because then people won't
> constantly squabble about how does/doesn't get included on them.  The
> ideal choices would be listing everybody or nobody, but everybody is
> cumbersome, and nobody doesn't seem to be legally valid.  So, listing
> one by name preserves the nonsensical nature of the notice while still
> meeting the legal requirement.  Or something like that...
> 

Keeping it simple is fine by me.  As mentioned in my other reply to Ulm,
I think I was conflating contribution attribution and copyright
assignment.  As long as "and others" (being unnamed) doesn't prevent
others from retaining their copyright (in practice as opposed to in
principle), SGTM.


-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-06-11 18:08 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 [this message]
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
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=e8eab4d3-2f52-b70f-1b54-fcece76b3f03@gentoo.org \
    --to=np-hardass@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    --cc=rich0@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