Re: Git GSoC 2014

From: David Kastrup <dak@gnu.org>
Date: Feb 15, 2014, 13:03 UTC
Message-ID: <87fvnk1q9u.fsf@fencepost.gnu.org>
In-Reply-To: <87fvnk4ljl.fsf@thomasrast.ch>

Thomas Rast <tr@thomasrast.ch> writes:

Show 7 quoted lines

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

Show 5 quoted lines

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