Re: Git GSoC 2014

[Thomas Rast <tr@thomasrast.ch>]

David Kastrup <dak@gnu.org> writes:

> Thomas Rast <tr@thomasrast.ch> writes:
>
>> Motivation: I believe that migrating to libgit2 is the better approach,
>> medium term, than rewriting everything ourselves to be nice, clean and
>> thread-safe.  I took a shot a while ago at making the pack reading code
>> thread-safe, but it's adding mess when we could simply replace it all by
>> the already thread-safe libgit2 calls.  It also helps shake out
>> incompatibilities in libgit2.
>
> That would either require forking libgit2 for Git use or stop dead any
> contributions to that rather central part of the git codebase from
> contributors not wanting their contributions to get reused in binary
> proprietary software.
>
> It would also mean that no serious forward-going work (like developing
> new packing formats or network protocols) can be done on a pure GPLv2
> codebase any more.  So anybody insisting on contributing work under the
> current Git license only would be locked out from working on significant
> parts of Git and could no longer propose changes in central parts.
>
> Now this can all be repealed by the "developing the atomic bomb does not
> mean that one has to use it" argument but even if one does not use it,
> the world with and without it are different worlds and occupy mindshare
> and suggest "solutions" and "diplomacy" involving it.
>
> So this is definitely a large step towards a situation where erosion of
> the existing license and related parts of the community becomes more
> attractive.
>
> There is the rationale "we can always say "no" at the end".  How do you
> explain this "no" to the student who invested significant amounts of
> work into this, in a project proposed by the Git developers?
>
> This definitely should not be "we'll think about it if and when that
> project is finished" material.

Yes, all of this is true.  However, you are painting a big devil on the
wall.

First, one very plausible outcome of such a project is that there is a
more narrowly defined interface to the object-reading component of the
git codebase, and that libgit2 can be "plugged in" at that interface
instead of the existing routines.  This would help both clean up our
code, and test libgit2 against existing git tests.

Your scenario above mostly applies if and when we really go the way of
my dream and scrap the code that is in git.  (I have similar long-term
dreams for other git components like ref storage and diffs, but that's
just me.)

Second, how many contributions would actually have been prevented by
GPLv2+LE licensing?

The only data I have on this is libgit2/git.git-authors, which records
who has consented for their _existing_ code to be relicensed.  I
consider this to be a higher barrier than contributing new code, since
there's no clear gain for the author in the relicensing.

That file is a sizeable list, and covers most contributions to
sha1_file.c lately:

  [git shortlog -sn --since=2.year.ago sha1_file.c, edited in the answer
  from git.git-authors]

   ok     15  Jeff King
   ok     11  Michael Haggerty
           6  Nguyễn Thái Ngọc Duy
   ok      5  Christian Couder
   ask     5  Thomas Rast
   ok      2  Brandon Casey
           2  Heiko Voigt
           2  Pete Wyckoff
           1  Felipe Contreras
           1  Joachim Schmitz
           1  Johan Herland
   ask     1  Jonathan Nieder
           1  Ramsay Allan Jones
           1  Steven Walter
           1  Vicent Marti

  (My "ask" is because of $DAYJOB legal reasons, and in fact the
  contributions above fall under the "ok before Oct 7, 2013" remark in
  git.git-authors.)

It also includes an "ok" from Nicolas Pitre, who has been the driving
force behind packv5 development.  The only thing that makes me uneasy is
that Duy is not in the list (Duy, have you been asked by libgit2 about
possible relicensing?).  Other than that, I do not see a cause for
concern.


Conversely, contributions to clean up that corner of code have not
exactly been forthcoming at a great rate in the first place.  The recent
work I can recall off hand was bug fixing and the introduction of pack
bitmaps.  The only work that I know is within reach is the packv5 drafts
that Nicolas and Duy tossed around.

(It is an odd coincidence that this thread runs in parallel with [1].
If that gains some traction, more power to them.)


So you may disagree, and other contributors should probably comment on
their stance.  But taking the above together, I think we stand to gain
more than we would lose.


[1] http://thread.gmane.org/gmane.comp.version-control.git/241965

-- 
Thomas Rast
tr@thomasrast.ch