Git development
 help / color / mirror / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "GitList" <git@vger.kernel.org>,
	"Jonathan Smith" <Jonathan.Smith@fphcare.co.nz>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [RFC/PATCH] Git doc: GPL2 does not apply to repo data
Date: Mon, 1 Feb 2016 10:53:51 -0000	[thread overview]
Message-ID: <82BCD59FE1254625963FF9A6CB98DC51@PhilipOakley> (raw)
In-Reply-To: xmqq8u35xv00.fsf@gitster.mtv.corp.google.com

From: "Junio C Hamano" <gitster@pobox.com>
> Philip Oakley <philipoakley@iee.org> writes:
>
>> diff --git a/Documentation/git.txt b/Documentation/git.txt
>> index bff6302..137c89c 100644
>> --- a/Documentation/git.txt
>> +++ b/Documentation/git.txt
>> @@ -1132,6 +1132,17 @@ of clones and fetches.
>>    - any external helpers are named by their protocol (e.g., use
>>      `hg` to allow the `git-remote-hg` helper)
>>
>> +Licencing: Your data, and the Git tool[[Licencing]]
>> +---------------------------------------------------
>> +
>> +Git is an open source tool provided under GPL2.
>> +Git was designed to be, and is, the version control system
>> +for the Linux codebase.
>> +Your respository data created by Git is not subject to Git's GNU2
>> +licence, see GPL FAQs
>> +http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#TOCGPLOutput).
>> +
>> +User should apply a licence of their own choice to their repository 
>> data.
>>
>>  Discussion[[Discussion]]
>>  ------------------------
>
> While I know you mean well, and I do understand the sentiment behind
> this addition,
It was an RFC for that very sentiment.

>             there are at least two reasons why I do not want to
> (and why we should not) add any "clarification" or "interpretation"
> like this.
>
> One is because such a statement is pointless.  Because we do not do
> copyright assignment to the project, you are not the sole copyright
> owner of Git.  Individual contributors hold copyright to the part
> they wrote.  The above statement you made, even with an endorsement
> by me as the project lead, does not have any power to assure that
> the users will not get sued by one copyright holder, who is not you
> or me, and at that point it is up to the court to interpret GPLv2.
> We can call such a copyright holder crazy or call such a suit
> frivolous, but that does not change the fact that the court is what
> decides the matter, so having that statement does not help the user.
>
> Another is because we are amateurs.  Philip, you may or may not be a
> lawyer yourself,

Correct, but as an Engineer I do get to review terms & conditions and 
specifications quite often..

>    but I know you are not _our_ lawyer.  An amateurish
> "interpretation" or "clarification" does not necessarily clarify the
> text but it muddies it, especially when done carelessly.  Imagine a
> case where a user creates a derived work of Git itself and stored it
> in a Git repository.

>      "Your respository data created by Git is not
> subject to Git's GNU2"--really?  At least the phrasing must say that
> the act of storing something in Git alone would not *MAKE* that
> something governed under GPLv2.

I can see the potential double meaning now you highlight it - I was thinking 
of the 'if it's _your_ data, you can choose'; however if it's not your data, 
the originator's restrictions would apply - that wasn't said.

>     What the user puts in Git may
> already be covered under GPLv2 for other reasons, and a statement
> carelessly written like the above can be twisted to read as if we
> are endorsing use of our code outside GPLv2 as long as they store it
> in Git repository, which is not what you meant to say, but "that is
> not what the copyright holder meant" is another thing the lawyer
> need to argue in court to convince the judge, when we need to go
> after a real copyright violator.
>
> We should leave the lawyering to real lawyers and we should not add
> unnecessary work of interpreting our amateurish loose statement to
> our laywers.

Given Jonathan's question, and your earlier feedback, it did feel that a bit 
of clear blue water would be useful between Git (the DVCS), and /.git/ (the 
repo contents), even if it were only to clarify the issues...

>
> Thanks.
>
--
Philip 

  parent reply	other threads:[~2016-02-01 10:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25  3:08 GPL v2 authoritative answer on stored code as a derived work Jonathan Smith
2016-01-25 19:06 ` Junio C Hamano
2016-01-27 23:58   ` Philip Oakley
2016-01-28  8:16     ` Johannes Schindelin
2016-01-31 20:51       ` Philip Oakley
2016-01-31 21:00       ` [RFC/PATCH] Git doc: GPL2 does not apply to repo data Philip Oakley
2016-01-31 22:08         ` Junio C Hamano
2016-01-31 22:15           ` Jonathan Smith
2016-02-01  7:35             ` Johannes Schindelin
2016-02-01  7:49               ` Matthieu Moy
2016-02-01  8:14                 ` Jeff King
2016-02-01  8:16                   ` Jeff King
2016-02-01 10:57                   ` Philip Oakley
2016-02-01 10:53           ` Philip Oakley [this message]
2016-02-01 11:34             ` Philip Oakley

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=82BCD59FE1254625963FF9A6CB98DC51@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=Jonathan.Smith@fphcare.co.nz \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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