bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Paul Smith <psmith@gnu.org>
To: Gnulib bugs <bug-gnulib@gnu.org>
Subject: Re: Seeking input from developers: glibc copyright assignment policy.
Date: Tue, 15 Jun 2021 12:32:35 -0400	[thread overview]
Message-ID: <5ac569a3c976caf3658e652fea843dc9dc69f76a.camel@gnu.org> (raw)
In-Reply-To: <20210615120307.uob7puryy2z3yqjp@redhat.com>

On Tue, 2021-06-15 at 07:03 -0500, Eric Blake wrote:
> 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.

This is what concerns me (not necessarily in Eric's case per se but in
general).  I worry that people think that a DCO is a hassle-free
replacement for an employer's copyright assignment.  Maybe, in some
jurisdictions, it even can be.

But as far as I'm aware in the U.S. (and other countries) you can't
just declare that your employer doesn't have any copyright to work you
do, even on your own time.  Most employment contracts make this clear
and even when they don't spell it out I think there's a presumption
that it is the case, certainly for salaried employees.

So, I just worry people will simply sign the DCO and call it good when
they don't actually have legal rights to do that.  Sure, that may
reduce liability for copyright infringement on the project: an employer
would have to go after the individual instead, but that wouldn't
prevent the project from having to remove the infringing code and all
code that could be considered derivative from it, which could be an
enormous hassle.

Maybe I'm wrong about how the DCO works but it greatly concerns me that
we would lose this safety net: rather than doing the work up-front
directed by people who understand the law, we're distributing this work
to random individuals and relying on each of them to fully understand
the legal questions and get it right for their situation... and leave
the project holding the bag if they don't.

Have there been any opinions or whitepapers published by FOSS
organizations regarding DCOs vs. assignments, discussing their benefits
and risks?



  reply	other threads:[~2021-06-15 16:32 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 [this message]
2021-06-15 17:14     ` Bruno Haible
2021-06-16 11:31     ` Eli Zaretskii
2021-06-15 21:08   ` Pádraig Brady
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=5ac569a3c976caf3658e652fea843dc9dc69f76a.camel@gnu.org \
    --to=psmith@gnu.org \
    --cc=bug-gnulib@gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).