All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: David Kastrup <dak@gnu.org>
Cc: git@vger.kernel.org
Subject: Re: A few contributor's questions
Date: Fri, 31 Jan 2014 10:48:42 -0800	[thread overview]
Message-ID: <20140131184842.GA30398@google.com> (raw)
In-Reply-To: <87mwic2ijo.fsf@fencepost.gnu.org>

Hi,

David Kastrup wrote:

> Also whether or not this implies an assignment of copyright, it is a
> reasonable assumption for
[...]

Since I think we've completely gone off the rails:

I assume the problem you're trying to solve is that files don't have
clear enough notices of their licensing.  That could be a real problem
for people using the code, since if you no one gave you a license then
you don't have a license at all.  It's also a problem in that it makes
it harder to interpret the phrase "under the same open source license"
(though I have no idea how that could be read as "I give up my
copyright completely").

The way git currently works in that area is the same as the Linux
kernel:

 * the code is copyright by the authors and we try not to waste fuss
   on maintaining a comprehensive list in notices.  If you want to
   find the authors to negotiate special licensing, you get to do the
   work.

 * license is GPLv2-only where not otherwise specified

 * relicensing, when needed, happens by contacting all the copyright
   holders and getting their consent

I don't see anything weird about that.  But people using the code
might like clearer notices, so I personally would not mind an extra
line in most files stating the license.  (More than that and it
becomes absurd.)  That's all just my opinion --- Junio might think
differently, etc.

[...]
> It's verbose and cumbersome enough that I would not have been surprised
> if there'd be an established way of getting this information on record,
> preferably per-project rather than per-commit.

For relicensing the existing practice is to just contact people.  That
has the advantage that I can make a decision about whether to allow
relicensing code I've written in the context of how I expect it to be
used.  I expect that if you had a stance on GPLv2+ licensing of
contributions to git published in some place easily found by search
engines (for example a message on the mailing list), interested people
would not have too much trouble finding it when the time comes.

Hope that helps,
Jonathan

  reply	other threads:[~2014-01-31 18:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-31 13:04 A few contributor's questions David Kastrup
2014-01-31 16:19 ` Jonathan Nieder
2014-01-31 17:00   ` David Kastrup
2014-01-31 18:48     ` Jonathan Nieder [this message]
2014-01-31 21:06       ` David Kastrup
2014-01-31 23:58         ` David Lang
2014-02-03 16:35 ` Andreas Ericsson
2014-02-03 17:35   ` David Kastrup

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=20140131184842.GA30398@google.com \
    --to=jrnieder@gmail.com \
    --cc=dak@gnu.org \
    --cc=git@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.