Re: Git GSoC 2014

[David Kastrup <dak@gnu.org>]

Thomas Rast <tr@thomasrast.ch> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> 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.

[...]

> Your scenario above mostly applies if and when we really go the way of
> my dream and scrap the code that is in git.

So it's not "a big devil" I am painting but rather the consequences if
everything goes according to plan.

> (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?

That's not as much the question as to how many will be prevented in
future by such a step.

The libgit2 community is different from that of Git and with a different
focus.  If you take a look at its front page, you'll see statements like
"Link with open and proprietary software.  No strings attached." and
"Trusted and used in production by GitHub, Microsoft, [...]".

A fusion with this project and its aims and licensing will have
consequences regarding which developers and users are attracted to Git.

The "act first, think later" approach is not really doing anybody
favors, and I don't consider it fair to GSoC students to employ them for
making this proposal gain leverage: one should first think this through
on behalf of the project before putting students to work on this so that
they know reasonably well what will happen with their work.

The kind of "Now that we made $x do $y, we are obliged to do $z."
scenario is easy to avoid by _first_ contemplating whether or not $z is
where one wants to go.

That's not "painting a devil" but common sense.  I'm not saying that the
answer is in any way self-evident.  Merely that the best time to answer
it is _before_ getting invested.

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

I consider it a lower barrier since the work is already done, and the
authors did not when doing it think about proprietary spinoffs.

But that's a minor point.  All I am saying is that there are different
opinions possible, and picking a particular path for future development
will in either way influence who wants to be part of the respective
communities.

-- 
David Kastrup