Re: libgit2 - a true git library

[Nicolas Pitre <nico@cam.org>]

On Fri, 31 Oct 2008, david@lang.hm wrote:

> On Fri, 31 Oct 2008, Nicolas Pitre wrote:
> 
> > On Fri, 31 Oct 2008, Pierre Habouzit wrote:
> > 
> > > Last but not least, I believe parts of git-core are currently easy to
> > > just take. For example, any code *I* wrote, I hereby give permission to
> > > relicense it in any of the following licenses: BSD-like, MIT-like,
> > > WTFPL.
> > 
> > First........... is there really a need to re-license it?
> > If so then the choice of license is IMHO rather important.
> 
> at the very least you should go from GPLv2 to LGPLv2 for the library.

Sure.

> while it can be argued that this really shouldn't be nessasary, the water is
> muddy enough that it would be a very good thing to do this.
> 
> I don't see any need to switch to a BSD/MIT/etc license for a library, the
> LGPL lets it get linked with those licenses anyway.

Right.

> > My favorite license for a library is the GPL with the gcc exception,
> > i.e. what libraries coming with gcc are using.  They're GPL but with an
> > exception allowing them to be linked with anything.  And because
> > everything on a Linux system, including proprietary applications, is
> > likely linked against those gcc libs, then there is nothing that would
> > prevent libgit to be linked against anything as well.  But the library
> > code itself has GPL protection.
> > 
> > For reference, here's the exception text:
> > 
> >   In addition to the permissions in the GNU General Public License, the
> >   Free Software Foundation gives you unlimited permission to link the
> >   compiled version of this file into combinations with other programs,
> >   and to distribute those combinations without any restriction coming
> >   from the use of this file.  (The General Public License restrictions
> >   do apply in other respects; for example, they cover modification of
> >   the file, and distribution when not linked into a combine
> >   executable.)
> 
> <shrug>, I don't see why this is needed with the LGPL, but I'm not a lawyer.

The LGPL also asks that proprietary applications provides necessary 
object files so you can link it against an alternative implementation of 
the LGPL library if you so wish.  With dynamic libraries this is rather 
moot but I think that's the main difference.


Nicolas