bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: "Pádraig Brady" <P@draigBrady.com>
To: Eric Blake <eblake@redhat.com>, Paul Eggert <eggert@cs.ucla.edu>
Cc: Gnulib bugs <bug-gnulib@gnu.org>
Subject: Re: Seeking input from developers: glibc copyright assignment policy.
Date: Tue, 15 Jun 2021 22:08:25 +0100	[thread overview]
Message-ID: <d142fc38-8398-ebf6-04a7-899b25250601@draigBrady.com> (raw)
In-Reply-To: <20210615120307.uob7puryy2z3yqjp@redhat.com>

On 15/06/2021 13:03, Eric Blake wrote:
> On Mon, Jun 14, 2021 at 01:39:26PM -0700, Paul Eggert wrote:
>> A proposal to change the glibc copyright assignment policy is being
>> circulated on libc-alpha. The email thread starts at
>> <https://sourceware.org/pipermail/libc-alpha/2021-June/127581.html>, and the
>> text of the email seeking input is at the end of this message.
>>
>> I'm sending this to bug-gnulib because we copy some files directly from
>> glibc and eventually I expect these files to be affected. The simplest
>> approach I see for Gnulib is to adopt glibc's policy, at least for files or
>> code copied from glibc.
> 
> I would like to make sure the FSF legal department doesn't see any
> holes in the plan, but I'm certainly okay as going on record as being
> in favor of the plan.

I am in favor of the plan also.
I feel copyright assignment is a significant _initial_ hurdle to contributions,
where the potential to deter contribution outweighs any potential advantages.

> I recall how long it took for me to get
> permission to sign assignment papers from my previous employer, for
> work I was doing in my spare time, and being able to use the DCO
> instead would have made my efforts easier at that time.  (My current
> employer already has a blanket copyright assignment on file for all
> employees, but not everyone has a company that willing to promote open
> source involvement.)

Yes the fact that one needs to repeat this process
as one changes employers is very awkward.
(In my case it was the reverse, in going from a company with
blanket copyright assignment, to one where I needed to
navigate the internal processes to get an assignment.)

I do wonder how diligent people are in general in this regard anyway.
I.e. how valid all current assignments are given the
frequency of employer changes and the awkwardness involved.

thanks,
Pádraig


  parent reply	other threads:[~2021-06-15 21:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 20:39 Seeking input from developers: glibc copyright assignment policy Paul Eggert
2021-06-14 22:46 ` Bruno Haible
2021-06-15 12:03 ` Eric Blake
2021-06-15 16:32   ` Paul Smith
2021-06-15 17:14     ` Bruno Haible
2021-06-16 11:31     ` Eli Zaretskii
2021-06-15 21:08   ` Pádraig Brady [this message]
2021-06-16 13:10     ` Paul Smith
2021-06-16 11:47 ` Dmitry V. Levin

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

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

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

  git send-email \
    --in-reply-to=d142fc38-8398-ebf6-04a7-899b25250601@draigBrady.com \
    --to=p@draigbrady.com \
    --cc=bug-gnulib@gnu.org \
    --cc=eblake@redhat.com \
    --cc=eggert@cs.ucla.edu \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).