Subject: Re: A few contributor's questions

From: David Kastrup <[email-masked]>
Date: Mon, 03 Feb 2014 18:35:22 +0100

Andreas Ericsson <[email-masked]> 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