Re: libgit2 - a true git library

From: Shawn O. Pearce <spearce@spearce.org>
Date: Nov 1, 2008, 01:00 UTC
Message-ID: <20081101010011.GG14786@spearce.org>
In-Reply-To: <alpine.DEB.1.10.0810311738100.5851@asgard.lang.hm>

david@lang.hm wrote:

Show 18 quoted lines

> On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
>> Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> I.e. use the supplied custom function to do proprietary magic, such as
>>> reading the object lazily from elsewhere over the network.  And we will
>>> never get that magic bit back.
>>
>> Maybe I just think too highly of the other guy, but I'd hope that
>> anyone patching libgit2 like above would try to avoid it, because
>> they'd face merge issues in the future.
>
> the issue that I see is that libgit2 will be (on most systems) a shared  
> library.
>
> what's to stop someone from taking the libgit2 code, adding the magic  
> proprietary piece, and selling a new libgit2 library binary 'just replace 
> your existing shared library with this new one and all your git related  
> programs gain this feature'

True. The only thing that prevents that is the normal GPL. The LGPL and GPL+"gcc exception" allow this sort of mean behavior. I doubt there's enough of a market for that; replacing a library is something of a pain and if the feature really is interesting or useful someone will write a clean-room re-implementation and submit patches to do the same thing.

> they would only face merge issues if they need to keep up to date with  
> you, and git makes it pretty easy to maintain a fork if you only have to  
> do one-way merging (rere)

In other words, we're too good for our own good.  ;-)

-- 
Shawn.