Re: libgit2 - a true git library
- From
- david@lang.hm <david@lang.hm>
- Date
- Nov 1, 2008, 01:04 UTC
- Message-ID
- <alpine.DEB.1.10.0810311802360.5851@asgard.lang.hm>
- In-Reply-To
- <20081101010011.GG14786@spearce.org>
On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
Show 26 quoted lines
> david@lang.hm wrote: >> 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.
how would the LGPL of GPL+gcc extention allow this? if they modify the code in the library and then distribute the modified library wouldn't they be required to distribute the changes to that library?
they could use the LGPL or GPL+exception library with their propriatary program, but I don't see how they could get away with modifying the library.
David Lang