Re: libgit2 - a true git library

["Shawn O. Pearce" <spearce@spearce.org>]

Nicolas Pitre <nico@cam.org> wrote:
> 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.

Some people want to be able to link the library into an application
that they redistribute binaries of, but not sources to.  Those folks
have also volunteered to help write the library.  If they put their
code where their mouth is, then I think they should be able to use
their code the way they want to.

That said, I think the license choice that makes the most sense
here is probably LGPL or GPL+gcc exception, like you note below.
BSD and MIT are probably not serious contenders.

> > at the very least you should go from GPLv2 to LGPLv2 for the library.
> 
> Sure.

Well, we cannot do a GPL->LGPL switch on code without author
permission for that sort of re-licensing.

That said, I think many authors of git.git code would be more
comfortable with a GPL->LGPL change, where they wouldn't be OK with
a GPL->BSD/MIT change.  There may be some folks though who still
wouldn't accept a GPL->LGPL move.

> > > My favorite license for a library is the GPL with the gcc exception,
...
> > > 
> > > 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.

I'm happy with either the LGPL or the GPL+exception above.  If I
read these correctly the GPL+exception allows one to distribute
static executables without source or object files, so long as the
library source wasn't modified.  I'd almost prefer just using the
standard LGPL then, static linking isn't very common anymore.

-- 
Shawn.