A few contributor's questions

A few contributor's questions

[David Kastrup]

I'm still in the process of finishing the rewrite of the builtin/blame.c
internals.  Now there are various questions regarding the final patch
proposals and commit messages.

Point 1) signing off implies that I'm fine with the licensing of the
file. builtin/blame.c merely states

/*
 * Blame
 *
 * Copyright (c) 2006, Junio C Hamano
 */

which obviously will not match the authorship of my contributions.
Since Junio has given blanket permission to reuse his Git contributions
under other licenses (see
<URL:https://github.com/libgit2/libgit2/blob/development/git.git-authors#L58>)
that I am not going to license my work under, the first commit in the
respective series would replace this header with

/*
 * Blame
 *
 * Copyright (c) 2006--2014, Junio C Hamano and others
 * Licensed under GPLv2.  See Git's COPYING file for details.
 */

That should be reasonably accurate boilerplate, I think, and should
avoid code from multiple authors to be erroneously assumed subjected to
agreements other than the default Git project licensing.

Which brings us to further nitty-gritty details.

Personally, I'm fine with permitting licensing contributions of mine
under GPLv2 or later.  Is there any clearing house where I can have this
sentiment recorded in a manner where potential heirs (which according to
copyright law will retain control over my works even when born after my
demise, so I cannot in good conscience vouch for their common sense)
cannot contest it?  Like putting

Permissable-Licenses: GPL Version 2 or later

in the commit message?


And finally, the ugly: I don't have any income apart from volunteers
paying me for writing Free Software, so a contribution like this one,
having taken substantial time, will make for a rather tepid report of my
GNU LilyPond activities in January and a corresponding slackening of
volunteer payments for what I could have been doing instead.

It's not the first performance shortcoming of Git I have worked on.  In
contrast to most other contributors, I won't be able to afford following
a whim for addressing such deficiencies in future without a chance for
recouping my losses.

My experience with GNU LilyPond has led me to conclude that the best
chance of getting voluntary payments is to appeal to those who are most
invested in the well-being of the software.  It's a sad reality that
they tend to be identical to those who are already investing substantial
amounts of time and effort into the project themselves.  So I'll put the
respective begging notice into the cover letter of the patch series:
I don't think it belongs in the commit messages, and it's not likely to
be effective anyway.

While I could put a "Prepaid-by:" footer into the commit messages, the
main effect would likely be to trigger the "somebody else's problem"
effect.  My experience with this kind of polite notice is that it's good
for the equivalent of a case of beer every ten years.

If the performance enhancements are mentioned in a release announcement,
adding a notice along the line "The performance of git blame has been
significantly improved by David Kastrup <dak@gnu.org>.  If this affects
you, consider contributing to his reimbursement."  would of course also
be welcome.

Ok, this should be about covering the bad and the ugly.  I'm still
working on the -C and -M replacements given the new code.  Hopefully
finished this weekend.

All the best

-- 
David Kastrup

Re: A few contributor's questions

[Jonathan Nieder]

Hi,

David Kastrup wrote:

>       builtin/blame.c merely states
>
> /*
>  * Blame
>  *
>  * Copyright (c) 2006, Junio C Hamano
>  */

I think you planned to make substantial changes, so

> /*
>  * Blame
>  *
>  * Copyright (c) 2006--2014, Junio C Hamano and others
>  * Licensed under GPLv2.  See Git's COPYING file for details.
>  */

towards the end of the series (or squashed into some patch that makes
significant changes) looks fine to me.

Also keep in mind that you don't need a copyright notice to own
copyright, that it would be crazy for someone to claim you've assigned
copyright on your changes without an explicit reassignment, and that
libgit2's git.git-authors file that keeps coming up includes a comment
with a heuristic for delving into the history to find the authors of
some code.

[...]
> Permissable-Licenses: GPL Version 2 or later

Wouldn't a signed message on your website or some other public place
(e.g., the mailing list) do the trick?

Or a sentence in a commit message saying

 "I'd be happy to have these changes relicensed under the GPL version 2
 or later."

sounds fine to me, at least.

Thanks and hope that helps,
Jonathan

Re: A few contributor's questions

[David Kastrup]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Also keep in mind that you don't need a copyright notice to own
> copyright, that it would be crazy for someone to claim you've assigned
> copyright on your changes without an explicit reassignment,

Not at all crazy: Documentation/SubmittingPatches states that adding a
"Signed-off-by:" footer to a commit among other things constitutes
agreement to

        Developer's Certificate of Origin 1.1

        By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

The only relevant notice to licensing "indicated in the file" currently
is "Copyright (c) 2006 by Junio Hamano".

Also whether or not this implies an assignment of copyright, it is a
reasonable assumption for people working with a copy of Git distributed
by tar file or otherwise that a file with such a copyright notice only
contains material copyrighted by Junio Hamano.  So if I want to assert
my copyright in the case of licensing breaches, the party in breach may
claim estoppel by me "hiding" material copyrighted by myself in a file
with such a notice.

> and that libgit2's git.git-authors file that keeps coming up includes
> a comment with a heuristic for delving into the history to find the
> authors of some code.

Sure.  But that does not mean that this is the only means to "reasonably
infer" the authorship of a file.

> [...]
>> Permissable-Licenses: GPL Version 2 or later
>
> Wouldn't a signed message on your website or some other public place
> (e.g., the mailing list) do the trick?

Legally?  Sure.  The whole point of such a notice in the commit message
(or in some central file in the Git repository) is to save people the
hassle of second-guessing or sleuthing for every single contribution.

> Or a sentence in a commit message saying
>
>  "I'd be happy to have these changes relicensed under the GPL version
>  2 or later."
>
> sounds fine to me, at least.

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.  If it's going to be
per-commit, a footer line would be less obtrusive than a whole sentence.

But it would seem that there's no rule/standard here.

Thanks

-- 
David Kastrup

Re: A few contributor's questions

[Jonathan Nieder]

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

Re: A few contributor's questions

[David Kastrup]

Jonathan Nieder <jrnieder@gmail.com> writes:

> I assume the problem you're trying to solve is that files don't have
> clear enough notices of their licensing.

No, just the file that I'm contributing to.  It has a single copyright
attribution that arguably is already less than accurate _unless_ the
respective authors can be considered to have been acting with the intent
of letting Junio do whatever he wants to do with their contribution.

> 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.

In that case, it is reasonably to revert to the general license.

> 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").

If the existing notice is "(c) Junio Hamano" that means that Junio is
fully able to license at his will.  And in the case of his work on Git,
this includes his expressive permission to relicense under the
conditions of libgit2, including a no-modification binary-only licensing
option.

So my problem is not as much that people might get the idea they might
not use/copy my work at all (which would be silly), but rather that they
have reasonable expectation to use it under the licensing scheme of
libgit2 without getting back to me.

>  * the code is copyright by the authors and we try not to waste fuss
>    on maintaining a comprehensive list in notices.

That's fine, but we are talking not about a list but a single named
copyright holder.  I was proposing adding "and others" to clarify that
the list is not exhaustive.

>  * relicensing, when needed, happens by contacting all the copyright
>    holders and getting their consent
>
> I don't see anything weird about that.

Neither do I.

> But people using the code might like clearer notices, so I personally
> would not mind an extra line in most files stating the license.

I was more concerned about amending the copyright attribution, though a
single line pointing out GPLv2 and referring the reader to the general
COPYING file does not seem excessive, either.

>> 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.

Well, that stops working once they are dead.  And it's probably rather
tricky to locate their heirs even in case they have placed instructions
concerning their copyrights into their last will.  While I am not in a
rush here, I am still likely to turn decomposing into a fulltime
occupation earlier than most other contributors: I started working with
computers at a time when the single most imminent danger to long-term
data archival were mice.

> 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.

Maybe, maybe not.  There is a big hole in the indexing of the Google
News history that was taken over from what once was Dejanews.  Putting
the information regarding prospective licensing close to the actual
source seems like a smart move.

At any rate, if there is no stock procedure for that, that's it.

-- 
David Kastrup

Re: A few contributor's questions

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4480 bytes --]

when relicensing, people use git blame, not header copyright notices to track 
down the authors.

if you are bothered by the copyright notice at the top, modify it as part of 
your patchset, it's very unlikely that anyone will care enough to object.

But copyright assignment has very strict requirements, it can't just be implicit 
or in e-mail, it requires a signed document, so unless you sign a document 
stating that you are transferring copyright, you don't have to worry about that.

David Lang


  On Fri, 31 Jan 2014, David Kastrup wrote:

> Date: Fri, 31 Jan 2014 22:06:16 +0100
> From: David Kastrup <dak@gnu.org>
> To: Jonathan Nieder <jrnieder@gmail.com>
> Cc: git@vger.kernel.org
> Subject: Re: A few contributor's questions
> 
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> I assume the problem you're trying to solve is that files don't have
>> clear enough notices of their licensing.
>
> No, just the file that I'm contributing to.  It has a single copyright
> attribution that arguably is already less than accurate _unless_ the
> respective authors can be considered to have been acting with the intent
> of letting Junio do whatever he wants to do with their contribution.
>
>> 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.
>
> In that case, it is reasonably to revert to the general license.
>
>> 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").
>
> If the existing notice is "(c) Junio Hamano" that means that Junio is
> fully able to license at his will.  And in the case of his work on Git,
> this includes his expressive permission to relicense under the
> conditions of libgit2, including a no-modification binary-only licensing
> option.
>
> So my problem is not as much that people might get the idea they might
> not use/copy my work at all (which would be silly), but rather that they
> have reasonable expectation to use it under the licensing scheme of
> libgit2 without getting back to me.
>
>>  * the code is copyright by the authors and we try not to waste fuss
>>    on maintaining a comprehensive list in notices.
>
> That's fine, but we are talking not about a list but a single named
> copyright holder.  I was proposing adding "and others" to clarify that
> the list is not exhaustive.
>
>>  * relicensing, when needed, happens by contacting all the copyright
>>    holders and getting their consent
>>
>> I don't see anything weird about that.
>
> Neither do I.
>
>> But people using the code might like clearer notices, so I personally
>> would not mind an extra line in most files stating the license.
>
> I was more concerned about amending the copyright attribution, though a
> single line pointing out GPLv2 and referring the reader to the general
> COPYING file does not seem excessive, either.
>
>>> 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.
>
> Well, that stops working once they are dead.  And it's probably rather
> tricky to locate their heirs even in case they have placed instructions
> concerning their copyrights into their last will.  While I am not in a
> rush here, I am still likely to turn decomposing into a fulltime
> occupation earlier than most other contributors: I started working with
> computers at a time when the single most imminent danger to long-term
> data archival were mice.
>
>> 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.
>
> Maybe, maybe not.  There is a big hole in the indexing of the Google
> News history that was taken over from what once was Dejanews.  Putting
> the information regarding prospective licensing close to the actual
> source seems like a smart move.
>
> At any rate, if there is no stock procedure for that, that's it.
>
>

Re: A few contributor's questions

[Andreas Ericsson]

On 2014-01-31 14:04, David Kastrup wrote:
> 
> I'm still in the process of finishing the rewrite of the builtin/blame.c
> internals.  Now there are various questions regarding the final patch
> proposals and commit messages.
> 
> Point 1) signing off implies that I'm fine with the licensing of the
> file. builtin/blame.c merely states
> 
> /*
>  * Blame
>  *
>  * Copyright (c) 2006, Junio C Hamano
>  */
> 
> which obviously will not match the authorship of my contributions.
> Since Junio has given blanket permission to reuse his Git contributions
> under other licenses (see
> <URL:https://github.com/libgit2/libgit2/blob/development/git.git-authors#L58>)
> that I am not going to license my work under, the first commit in the
> respective series would replace this header with
> 

It's a long time since I wrote that document.

Does this mean you're not willing to relicense your contributions with
the license used by libgit2? That's what the document is supposed to
mean and it's what I asked on the mailing list when requesting
permission.

The libgit2 license used as of today is still the license that people
agreed to relicense their contributions under. It can be found here:
https://github.com/libgit2/libgit2/blob/development/.HEADER

I'm mostly adding it here for the sake of clarity in case people find
this in the future and wonder what all the fuzz was about.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: A few contributor's questions

[David Kastrup]

Andreas Ericsson <ae@op5.se> writes:

> On 2014-01-31 14:04, David Kastrup wrote:
>> 
>> I'm still in the process of finishing the rewrite of the builtin/blame.c
>> internals.  Now there are various questions regarding the final patch
>> proposals and commit messages.
>> 
>> Point 1) signing off implies that I'm fine with the licensing of the
>> file. builtin/blame.c merely states
>> 
>> /*
>>  * Blame
>>  *
>>  * Copyright (c) 2006, Junio C Hamano
>>  */
>> 
>> which obviously will not match the authorship of my contributions.
>> Since Junio has given blanket permission to reuse his Git contributions
>> under other licenses (see
>> <URL:https://github.com/libgit2/libgit2/blob/development/git.git-authors#L58>)
>> that I am not going to license my work under, the first commit in the
>> respective series would replace this header with
>
> It's a long time since I wrote that document.
>
> Does this mean you're not willing to relicense your contributions with
> the license used by libgit2? That's what the document is supposed to
> mean and it's what I asked on the mailing list when requesting
> permission.

I make a living from writing Free Software.  It should hardly come as a
surprise that I will not hand libgit2 users like Microsoft or GitHub
software for unrestricted use in proprietary products without getting
recompensated.  They make money from their products without sharing
their code back.

So I'm not going to relicense my work under the libgit2 license
_without_ _recompensation_, for use by companies that don't license
their work without recompensation.  It would be grossly unfair towards
those people who actually pay me for writing GPLed software (mostly GNU
LilyPond).  Of course I regularly report what I worked on, and I expect
a temporary drop in my funding corresponding to the lack of
LilyPond-related activities.  So there is an actual cost for me to bear,
and I will not bear it myself in order to support proprietary
derivatives.

So the price tag for letting the finished git-blame work (I've found a
few more optimizations making it more worthwhile) get relicensed under
the libgit2 licensing scheme would be in the order of €10000.  It would
take a rather good salaried programmer to reproduce what I'm doing right
now for the same price tag, and since my work will be available in Git
proper under the GPLv2 before anybody has to make any decision, there is
no uncertainty about exactly what people will be getting.

If there is going to be significant use of the git-blame functionality
by libgit2, I claim that the gain in efficiency (and programming time)
would more than offset the cost.

And if there isn't going to be significant use of that functionality,
it's not important whether it's in libgit2 or not.

> The libgit2 license used as of today is still the license that people
> agreed to relicense their contributions under. It can be found here:
> https://github.com/libgit2/libgit2/blob/development/.HEADER

That's actually the license on some files.  The overall license
statement in
<URL:https://github.com/libgit2/libgit2/blob/development/COPYING>
suggests that the libgit2 code base encompasses quite more components.
Some of those are mentioned as being licensed under the Apache 2.0
license, incompatible to GPLv2 according to
<URL:https://www.apache.org/licenses/GPL-compatibility.html>.  Since the
GPL requires licensing of a work _as_ _a_ _whole_, it's not really all
too obvious to me whether any part but the linking/unmodified-binary
exception will actually be effective.

But that's pure speculation on my part (I am obviously not a lawyer) and
no skin off my nose if somebody wants to invest the price for releasing
under whatever licensing scheme libgit2 happens to use.  If libgit2 or a
variant of it reverts to unmodified GPLv2 (or later) at any point of
time, they are free to just take what is there without having to
negotiate with me (or anybody else), anyway.

And of course, calling the git executable and letting it do the work
will also remain an option.  That's likely what the simple git web
services do anyway.  "git blame" is usually disabled in web interfaces
for performance reasons, and I'm afraid that even a factor of 3--4 in
speed (which is what I'm getting with uglier real-world cases) is not
going to change that.

> I'm mostly adding it here for the sake of clarity in case people find
> this in the future and wonder what all the fuzz was about.

It's probably easy to notice that I can make a lot of fuzz about small
things.  It's probably less annoying when I do it in code rather than in
prose...

-- 
David Kastrup