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
Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy [v4]
Date: Thu, 27 Sep 2018 10:24:59 -0400	[thread overview]
Message-ID: <f91fc6ba-acb7-121b-5af2-b4d48c3e04a4@gentoo.org> (raw)
In-Reply-To: <CAGfcS_kTAAxmvW8LSLa0qaBe=hUaM-5no1oUASqNV8dyFJh2mg@mail.gmail.com>


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

On 09/27/2018 10:13 AM, Rich Freeman wrote:
> On Thu, Sep 27, 2018 at 9:52 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>
>> But that's really besides the point... The current status quo (as is the
>> case with me) is that a committer may be pseudonymous under the
>> condition that the Foundation have that individual's name in the event
>> of a copyright issue. So, I still don't understand how forcing everyone
>> to publicly use a real name achieves something that we aren't currently
>> achieving...  Is that incorrect?
> 
> Interesting point.
> 
> If we were going to go down this road I'd still suggest that the
> Foundation have a policy on when the real names of contributors can be
> disclosed, either privately or publicly.  If we were to use the
> defense that we have a statement from a contributor that they checked
> the copyright and it was ok, the first question somebody will respond
> with is, "who?"  An answer of "we know who it is but can't tell
> anybody, even a court" probably isn't going to work.
> 
> I think there are other arguments to be made against anonymity.
> You're hardly a list troll, but anonymity can breed this sort of
> thing.  From a strictly copyright standpoint I don't see why the
> identity of contributors needs to be publicly disclosed, as long as it
> can be disclosed where legally necessary.  Of course, if that is a
> court then depending on the jurisdiction it may become public anyway.
> Also, if we were going to go down this route then we also need to have
> better archives of such things, as trying to dig up some trustee email
> from 10 years ago is not the right solution.  A secured repository of
> identities/etc would be better (the Foundation already has a place to
> store stuff like bank account details).
> 
> Another practical argument against anonymity.  If everybody agrees
> everything is public, then we don't have any personal information we
> need to protect under various privacy laws.  As soon as we agree to
> keep some info private, then we potentially have obligations under
> such laws.  Also, legally the Foundation is a US organization - so I'm
> not sure if things like the US-EU Safe Harbor provisions start to
> apply if we want to collect this sort of info from EU citizens.  It is
> just a can of worms you can avoid simply by not hanging onto this kind
> of information.  I believe that many of these privacy protections
> cannot be simply waived - we can't get some EU citizen to agree that
> they don't apply to us.  If the laws apply then we need to follow
> them.  Now, we're obviously not a big fish, so enforcement may never
> happen.  Maybe compliance isn't burdensome - I only know enough about
> such things to know that I'd want to know more before going down that
> road...
> 

But enforcing committers only to be named doesn't really avoid the
issues you are espousing wrt copyright issues... All it does is give you
someone to blame (who isn't the perpetrator of the copyright violation).
 Any random person can submit code under the new proposed copyright
policy, and as long as they aren't making a commit, there is no force
for using a real name.

So, unless we are outlawing all anonymous and pseudonymous contributions
of any sort (authorship, not just a commit), there is really no point in
forcing committers to be publicly named.

-- 
NP-Hardass


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

  reply	other threads:[~2018-09-27 14:25 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
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 [this message]
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=f91fc6ba-acb7-121b-5af2-b4d48c3e04a4@gentoo.org \
    --to=np-hardass@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