git to libgit2 code relicensing

git to libgit2 code relicensing

[Andreas Ericsson]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

I've been working quite a lot on git -> libgit2 code moving,
but the licensing stuff is a bit depressing, as I can't know
if the work I'm doing is for nothing or not.

The license decided for libgit2 is "GPL with gcc exception".
Those who are OK with relicensing their contributions under
that license for the purpose of libgit2, can you please say
so?

I'm planning on writing a tool for this that will have "ok",
"not ok" and "ask-each-patch" as options.

The list of people whose position I know is rather short.
Please correct me if you're on it and would like not to be.
Junio C. Hamano		ask
Johannes Schindelin	ok
Shawn O. Pearce		ok
Andreas Ericsson	ok
Pierre Habouzit		ok
Brian Gernhardt		ok


I've put everyone who "owns" more than 500 lines of code
on the bcc list, figuring your permission is important
but that you don't want the hundreds (well, one can hope)
of emails from people saying "ok". The list of major owners
was generated with "git showners *.c" in a worktree from
the next branch of git.git.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

[-- Attachment #2: git-showners --]
[-- Type: text/plain, Size: 673 bytes --]

#!/bin/sh

test "$#" -gt 0 || { echo "Usage: $0 <file>"; exit 1; }
combined=t
while test "$#" -gt 0
do
	case "$1" in
	-c|--combined)
		combined=t
	;;
	-i|--individual)
		combined=
	;;
	--)
		shift
		break
	;;
	*)
		break
	;;
	esac
	shift
done

sort_enumerate ()
{
	sed -e 's/[^(]*(\([^0-9]*\).*/\1/' -e 's/[\t ]*$//' \
		| sort | uniq -c | sort -nr
}

show_owners ()
{
	for f in "$@"; do
		test -d "$f" && { show_owners "$f"/*; continue; }

		git blame -C -C -M "$f"
	done
}

if test "$combined" = t; then
	echo "$@"
	show_owners "$@" | sort_enumerate
else
	echo "Showing one-at-a-time ownership"
	for f in "$@"; do
		echo "$f"
		show_owners "$f" | sort_enumerate
	done
fi

Re: git to libgit2 code relicensing

[Martin Koegler]

On Fri, Nov 14, 2008 at 09:59:56PM +0100, Andreas Ericsson wrote:
> I've put everyone who "owns" more than 500 lines of code
> on the bcc list, figuring your permission is important
> but that you don't want the hundreds (well, one can hope)
> of emails from people saying "ok". The list of major owners
> was generated with "git showners *.c" in a worktree from
> the next branch of git.git.

I don't think, that your way for relicensing is bullet proof:

I consider many of my GIT patches as derived work from other parts of
GIT, even if git blame is stating me as author. I can gurantee you,
that I comply with the "Developer's Certificate of Origin 1.1" point
b, as its based on code out of git.git. But I can't tell you, from
which files I reused code anymore.

Probably other people did the same.

Your method is ignoring such derived code.

mfg Martin Kögler

Re: git to libgit2 code relicensing

[Sverre Rabbelier]

On Fri, Nov 14, 2008 at 22:33, Martin Koegler
<mkoegler@auto.tuwien.ac.at> wrote:
> On Fri, Nov 14, 2008 at 09:59:56PM +0100, Andreas Ericsson wrote:
>> I've put everyone who "owns" more than 500 lines of code
>> on the bcc list, figuring your permission is important
>> but that you don't want the hundreds (well, one can hope)
>> of emails from people saying "ok". The list of major owners
>> was generated with "git showners *.c" in a worktree from
>> the next branch of git.git.
>
> I don't think, that your way for relicensing is bullet proof:
>
> I consider many of my GIT patches as derived work from other parts of
> GIT, even if git blame is stating me as author. I can gurantee you,
> that I comply with the "Developer's Certificate of Origin 1.1" point
> b, as its based on code out of git.git. But I can't tell you, from
> which files I reused code anymore.
>
> Probably other people did the same.
>
> Your method is ignoring such derived code.

Perhaps git stats can be of assistance here, it can summarize how much
lines a person changed (per file, or in total), that should be a
better metric (at least for code reused from within git.git, ofcourse
GPL-ed code taken from somewhere else is not covered).

-- 
Cheers,

Sverre Rabbelier

Re: git to libgit2 code relicensing

[Andreas Ericsson]

Sverre Rabbelier wrote:
> On Fri, Nov 14, 2008 at 22:33, Martin Koegler
> <mkoegler@auto.tuwien.ac.at> wrote:
>> On Fri, Nov 14, 2008 at 09:59:56PM +0100, Andreas Ericsson wrote:
>>> I've put everyone who "owns" more than 500 lines of code
>>> on the bcc list, figuring your permission is important
>>> but that you don't want the hundreds (well, one can hope)
>>> of emails from people saying "ok". The list of major owners
>>> was generated with "git showners *.c" in a worktree from
>>> the next branch of git.git.
>> I don't think, that your way for relicensing is bullet proof:
>>
>> I consider many of my GIT patches as derived work from other parts of
>> GIT, even if git blame is stating me as author. I can gurantee you,
>> that I comply with the "Developer's Certificate of Origin 1.1" point
>> b, as its based on code out of git.git. But I can't tell you, from
>> which files I reused code anymore.
>>
>> Probably other people did the same.
>>
>> Your method is ignoring such derived code.
> 
> Perhaps git stats can be of assistance here, it can summarize how much
> lines a person changed (per file, or in total), that should be a
> better metric (at least for code reused from within git.git, ofcourse
> GPL-ed code taken from somewhere else is not covered).
> 

That will almost certainly not be a problem. I'm working on reading stuff
into git-specific structures and then updating those structures. I doubt
any such code exists outside git. If it does, it's more likely derived
from git than the other way around.

It's also worth noting that I'm aiming for the really low-level core
stuff at first. It would be beneficial to get such simple things going
as updating the index (with an entire file) and then creating a commit
from that index. Such a thing would definitely be enough for (very basic)
IDE integration, and then we can build further on that but utilizing
developers from other projects than the git developer community.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git to libgit2 code relicensing

[Andreas Ericsson]

Martin Koegler wrote:
> On Fri, Nov 14, 2008 at 09:59:56PM +0100, Andreas Ericsson wrote:
>> I've put everyone who "owns" more than 500 lines of code
>> on the bcc list, figuring your permission is important
>> but that you don't want the hundreds (well, one can hope)
>> of emails from people saying "ok". The list of major owners
>> was generated with "git showners *.c" in a worktree from
>> the next branch of git.git.
> 
> I don't think, that your way for relicensing is bullet proof:
> 

I know that it's not, which is why I'm doing research to take care
of the pieces interesting for libgit2 that could possibly have
been derived from elsewhere. Reading and filling structures specific
to git is something I'd be surprised if they originated outside of
git though.

> I consider many of my GIT patches as derived work from other parts of
> GIT, even if git blame is stating me as author. I can gurantee you,
> that I comply with the "Developer's Certificate of Origin 1.1" point
> b, as its based on code out of git.git.

Right, but if we can never re-use code from git.git, libgit will never
fly. It's unfortunately as simple as that. So perhaps we're left with
the option of writing a GPL'd library or just go hang.

> But I can't tell you, from which files I reused code anymore.
> 

To a certain point, "git blame" can.

> Probably other people did the same.
> 
> Your method is ignoring such derived code.
> 

Right. If possible, I'd still like an OK from you though. If nothing
else, it'll make it possible to re-use code that originated from
someone else and that you changed, assuming that "someone else" also
agree to relicensing their code. With 100% of the authors agreeing
to that, we could have a libified git flying in a matter of months
instead of never.

It's unfortunate if the letter of the law pertaining to a particular
license should prevent the copyright owners from doing whatever
they want with the code, but perhaps that's the world we live in.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git to libgit2 code relicensing

[Martin Koegler]

Andreas Ericsson wrote:
> Shawn posted the exact text. The spirit of that license is that anyone can
> use an unmodified version of the library for whatever they want, but it's
> illegal to link non-GPL software to an altered version of the library. That
> is, the git community will get all changes back while other projects can
> use the official version of the library without having to worry about
> licensing issues. EvilCompany cannot make changes to the library and then
> link non-GPL'd software to their changed version. They can do that if they
> send their library changes upstream and then only use them once they're
> considered "official" though.

I would not interpret the license this way. Lets look at the text:

|  In addition to the permissions in the GNU General Public License,
|  the authors give 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 combined executable.)

It's an additional permission, which allows linking into binaries and
distributing them. 

Modification is still covered by the GPL text, 2b:

|  You must cause any work that you distribute or publish, that in
|  whole or in part contains or is derived from the Program or any
|  part thereof, to be licensed as a whole at no charge to all third
|  parties under the terms of this License.

So a patched version must be available unter the "this" license. In my
option, this must be GPLv2+addition permission. GPLv3 explicitly talks
about additional terms, so its clear, that they propagate. GPLv2
doesn't do this, but additional terms, like OpenSSL linkage exceptions
are usually propagated.

So EvilCompany can create their own, modified GPL+GCC exception
libgit2 version behind their doors.

Then they link it into their non-GPL software and can distribute the
resulting binary without any GPL restriction. As the exception states,
that the binary can be distributed without any restrictions coming
from the GPL+GCC exception code, this COULD mean, that clause 3 of the
GPL does not apply too (ship binary without source code).

I'm only a programmer, so you should ask people with better
understanding of legal things.

Your interpretation of the GCC exception would render it useless for
the Debian probject [and probably other projects too], which means,
that they can use/distribute libgit2 only the GPL. If you don't want
that, you should consider posting to Debian Legal
(http://lists.debian.org/debian-legal/) for advice.

mfg Martin Kögler
PS: 
Have you looked at the Classpath exception:

|  Linking this library statically or dynamically with other modules is
|  making a combined work based on this library.  Thus, the terms and
|  conditions of the GNU General Public License cover the whole
|  combination.
|  
|  As a special exception, the copyright holders of this library give you
|  permission to link this library with independent modules to produce an
|  executable, regardless of the license terms of these independent
|  modules, and to copy and distribute the resulting executable under
|  terms of your choice, provided that you also meet, for each linked
|  independent module, the terms and conditions of the license of that
|  module.  An independent module is a module which is not derived from
|  or based on this library.  If you modify this library, you may extend
|  this exception to your version of the library, but you are not
|  obligated to do so.  If you do not wish to do so, delete this
|  exception statement from your version. 

Re: git to libgit2 code relicensing

[Linus Torvalds]

On Fri, 14 Nov 2008, Andreas Ericsson wrote:
> 
> The license decided for libgit2 is "GPL with gcc exception".

What's the exact language? 

I'm likely ok with GPLv2 + libgcc-like exception, but I'd like to see the 
exact one. I haven't followed the discussions much..

		Linus

Re: git to libgit2 code relicensing

[Shawn O. Pearce]

Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, 14 Nov 2008, Andreas Ericsson wrote:
> > 
> > The license decided for libgit2 is "GPL with gcc exception".
> 
> What's the exact language? 
> 
> I'm likely ok with GPLv2 + libgcc-like exception, but I'd like to see the 
> exact one. I haven't followed the discussions much..

The language we are using in libgit2 is taken from libgcc, and is
as follows:

--8<--

 Note that the only valid version of the GPL as far as this project
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.

 In addition to the permissions in the GNU General Public License,
 the authors give 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 combined executable.)

----------------------------------------------------------------------

		    GNU GENERAL PUBLIC LICENSE
		       Version 2, June 1991

(... the rest of GPL v2 as it appears in git.git ...)

-- 
Shawn.

Re: git to libgit2 code relicensing

[David Brown]

On Fri, Nov 14, 2008 at 03:46:58PM -0800, Shawn O. Pearce wrote:

> In addition to the permissions in the GNU General Public License,
> the authors give 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 combined executable.)

Is this license intended to allow static linking but forbid dynamic
linking into a non-GPL program?  It depends on how you interpret
"linked into a combined executable", but that sounds like it
intentionally excludes the dynamic case.

David

Re: git to libgit2 code relicensing

[Shawn O. Pearce]

David Brown <git@davidb.org> wrote:
> On Fri, Nov 14, 2008 at 03:46:58PM -0800, Shawn O. Pearce wrote:
>
>> In addition to the permissions in the GNU General Public License,
>> the authors give 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 combined executable.)
>
> Is this license intended to allow static linking but forbid dynamic
> linking into a non-GPL program?  It depends on how you interpret
> "linked into a combined executable", but that sounds like it
> intentionally excludes the dynamic case.

I don't know.  When I read it myself I assumed dynamic linking
would also be OK.  This is why I prefer programs; I don't read
legalese so I can't quite figure out what the statement means.
At least with C its a little less vague.  ;-)

-- 
Shawn.

Re: git to libgit2 code relicensing

[Nicolas Pitre]

On Fri, 14 Nov 2008, Shawn O. Pearce wrote:

> David Brown <git@davidb.org> wrote:
> > On Fri, Nov 14, 2008 at 03:46:58PM -0800, Shawn O. Pearce wrote:
> >
> >> In addition to the permissions in the GNU General Public License,
> >> the authors give 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 combined executable.)
> >
> > Is this license intended to allow static linking but forbid dynamic
> > linking into a non-GPL program?  It depends on how you interpret
> > "linked into a combined executable", but that sounds like it
> > intentionally excludes the dynamic case.
> 
> I don't know.  When I read it myself I assumed dynamic linking
> would also be OK.

libgcc is a dynamic library on most modern systems these days. Yet they 
routinely execute non-GPL programs. If that text intentionally excluded 
the dynamic case then every non-GPL applications on such systems would 
have been breaking the license for a long time.  So I don't think anyone 
could have substance for such a claim.


Nicolas

Re: git to libgit2 code relicensing

[David Brown]

On Sat, Nov 15, 2008 at 03:04:29AM -0500, Nicolas Pitre wrote:

>libgcc is a dynamic library on most modern systems these days. Yet they 
>routinely execute non-GPL programs. If that text intentionally excluded 
>the dynamic case then every non-GPL applications on such systems would 
>have been breaking the license for a long time.  So I don't think anyone 
>could have substance for such a claim.

Sure they can.  Lack of enforcement doesn't dilute copyright like it
does trademark.

It may be that the gcc authors intend for it to be allowed for dynamic
libraries, and therefore wouldn't sue for that usage, but that's not
what they're saying in their license.

What I'm saying is that if I was in a position to review the license
and determine what was permitted, this license with exception does not
appear to allow dynamic linking against the library.  It doesn't
explicitly forbid this, but it is ambiguous about it.

David

Re: git to libgit2 code relicensing

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

On Fri, Nov 14, 2008 at 03:46:58PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
>  Note that the only valid version of the GPL as far as this project
>  is concerned is _this_ particular version of the license (ie v2, not
>  v2.2 or v3.x or whatever), unless explicitly otherwise stated.
> 
>  In addition to the permissions in the GNU General Public License,
>  the authors give 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 combined executable.)

IANAL - what is the difference between this and the LGPL?

Thanks.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git to libgit2 code relicensing

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Fri, Nov 14, 2008 at 03:46:58PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
>>  Note that the only valid version of the GPL as far as this project
>>  is concerned is _this_ particular version of the license (ie v2, not
>>  v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>> 
>>  In addition to the permissions in the GNU General Public License,
>>  the authors give 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 combined executable.)
>
> IANAL - what is the difference between this and the LGPL?

Under LGPL, you must provide linkable object files to your (possibly
closed source) program, so that people who made changes to (or obtained an
updated version of) a LGPL'ed library can re-link your program and use the
updated library.  The above does not ask you to do so.

The way I read LGPL is that "We deeply care about our LGPL library and any
improvements to it.  Although we do not care at all about how your crappy
closed source program is written, we want to make sure that the users can
keep using your program after improvements are made to our library.".  I
do not think it makes a practical difference when your program uses the
LGPL library as a shard library from that point of view.

Re: git to libgit2 code relicensing

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Sat, Nov 15, 2008 at 05:00:52AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Under LGPL, you must provide linkable object files to your (possibly
> closed source) program, so that people who made changes to (or obtained an
> updated version of) a LGPL'ed library can re-link your program and use the
> updated library.  The above does not ask you to do so.
> 
> The way I read LGPL is that "We deeply care about our LGPL library and any
> improvements to it.  Although we do not care at all about how your crappy
> closed source program is written, we want to make sure that the users can
> keep using your program after improvements are made to our library.".  I
> do not think it makes a practical difference when your program uses the
> LGPL library as a shard library from that point of view.

Ah, I see - so this is a "Lesser LGPL". :)

Thank you both Junio and David.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git to libgit2 code relicensing

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

On Sat, Nov 15, 2008 at 07:33:27PM +0000, Miklos Vajna wrote:
> On Sat, Nov 15, 2008 at 05:00:52AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > Under LGPL, you must provide linkable object files to your (possibly
> > closed source) program, so that people who made changes to (or obtained an
> > updated version of) a LGPL'ed library can re-link your program and use the
> > updated library.  The above does not ask you to do so.
> > 
> > The way I read LGPL is that "We deeply care about our LGPL library and any
> > improvements to it.  Although we do not care at all about how your crappy
> > closed source program is written, we want to make sure that the users can
> > keep using your program after improvements are made to our library.".  I
> > do not think it makes a practical difference when your program uses the
> > LGPL library as a shard library from that point of view.
> 
> Ah, I see - so this is a "Lesser LGPL". :)

LGPL also has a clause that allow the user to make it become GPLv2 or
later, even if you chose LGPL v2.1 *only* (as in not LGPL v2.1 or later).

Seeing how the FSF has just decided to use those upgrade clauses with
the GFDL, I'm not really likely to fancy the use of any license that
forces me to accept an "or later" clause. I would be _really_ against
the LGPL FWIW.


-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git to libgit2 code relicensing

[David Brown]

On Sat, Nov 15, 2008 at 01:39:16PM +0100, Miklos Vajna wrote:
>On Fri, Nov 14, 2008 at 03:46:58PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
>>  Note that the only valid version of the GPL as far as this project
>>  is concerned is _this_ particular version of the license (ie v2, not
>>  v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>> 
>>  In addition to the permissions in the GNU General Public License,
>>  the authors give 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 combined executable.)
>
>IANAL - what is the difference between this and the LGPL?

This clause allows static linking, and distribution of only the final
binary.  The LGPL always requires source to be made available to the
libaray.  This clause does not require that source to be distributed.

In other words, it allows libgit2 to be linked into a proprietary
program and the distributor of that program to _not_ include the
source of libgit2.  It is not clear if they have to provide source to
modifications that they have made, or if making those modifications
under the exception is even allowed.

There are numerous other versions of this exception, some of which
might be better worded than this.

David

Re: git to libgit2 code relicensing

[Linus Torvalds]

On Fri, 14 Nov 2008, Shawn O. Pearce wrote:
> 
> The language we are using in libgit2 is taken from libgcc, and is
> as follows:

Ok, I'm fine with this. 

			Linus

Re: git to libgit2 code relicensing

[Andreas Ericsson]

Linus Torvalds wrote:
> 
> On Fri, 14 Nov 2008, Andreas Ericsson wrote:
>> The license decided for libgit2 is "GPL with gcc exception".
> 
> What's the exact language? 
> 
> I'm likely ok with GPLv2 + libgcc-like exception, but I'd like to see the 
> exact one. I haven't followed the discussions much..
> 

Shawn posted the exact text. The spirit of that license is that anyone can
use an unmodified version of the library for whatever they want, but it's
illegal to link non-GPL software to an altered version of the library. That
is, the git community will get all changes back while other projects can
use the official version of the library without having to worry about
licensing issues. EvilCompany cannot make changes to the library and then
link non-GPL'd software to their changed version. They can do that if they
send their library changes upstream and then only use them once they're
considered "official" though.

As the original author, you sort of have veto here since everything core-ish
is derived from what you wrote. Iow, if you say nay, libgit2 with a non-GPL
license will only fly if index, tree, commit, ref, etc... manipulation is
rewritten from scratch. That will be hard, given that it can fairly easily
be claimed that the people most likely to do it are so heavily influenced by
the current code that it's impossible for them not to make a derivative work.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git to libgit2 code relicensing

[Pau Garcia i Quiles]

> Shawn posted the exact text. The spirit of that license is that anyone can
> use an unmodified version of the library for whatever they want, but it's
> illegal to link non-GPL software to an altered version of the library. That
> is, the git community will get all changes back while other projects can
> use the official version of the library without having to worry about
> licensing issues. EvilCompany cannot make changes to the library and then
> link non-GPL'd software to their changed version. They can do that if they
> send their library changes upstream and then only use them once they're
> considered "official" though.

Do you mean if I write a patch to libgit2, send it upstream and make
it public on my website but it is not accepted upstream, I cannot link
my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
software? It looks insane to me: I wrote the patch and made it public
but you guys did not accept it!

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: git to libgit2 code relicensing

[Andreas Ericsson]

Pau Garcia i Quiles wrote:
>> Shawn posted the exact text. The spirit of that license is that anyone can
>> use an unmodified version of the library for whatever they want, but it's
>> illegal to link non-GPL software to an altered version of the library. That
>> is, the git community will get all changes back while other projects can
>> use the official version of the library without having to worry about
>> licensing issues. EvilCompany cannot make changes to the library and then
>> link non-GPL'd software to their changed version. They can do that if they
>> send their library changes upstream and then only use them once they're
>> considered "official" though.
> 
> Do you mean if I write a patch to libgit2, send it upstream and make
> it public on my website but it is not accepted upstream, I cannot link
> my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
> software?

I think that's the case, yes.

> It looks insane to me: I wrote the patch and made it public
> but you guys did not accept it!
> 

Well, if you wrote a patch that uses a closed-source database library
to store git objects in, how would that benefit the community even if
you published the patch?

You could ofcourse fork the library, but then you'd have to take care
of namespace conflicts and such things. The fork would naturally have
to be licensed GPL + gcc-exception too, since it's a derivative work.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git to libgit2 code relicensing

[Pau Garcia i Quiles]

On Sat, Nov 15, 2008 at 12:05 PM, Andreas Ericsson <ae@op5.se> wrote:

>> Do you mean if I write a patch to libgit2, send it upstream and make
>> it public on my website but it is not accepted upstream, I cannot link
>> my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
>> software?
>
> I think that's the case, yes.
>
>> It looks insane to me: I wrote the patch and made it public
>> but you guys did not accept it!
>>
>
> Well, if you wrote a patch that uses a closed-source database library
> to store git objects in, how would that benefit the community even if
> you published the patch?

The case I had in mind is not that but this: say I write a patch which
is totally open-source and uses only open-source software to add some
feature to libgit2 but I want to link that libgit2 + mypatch to a
closed source application (say, for instance, software for military
use, which I'm not allowed to open source). To state it clearly:
- My contribution is 100% open source
- My contribution is 100% towards libgit2
- In fact, I could add that very feature to my application instead of
libgit2 but as I'm open-source-friendly, I decide to contribute that
patch to libgit2.

For some reason, that patch:
- Is not accepted for some time (for instance, I'm thinking in that
tcl/tk limitation which is preventing Junio from merging a patch, it's
been in the "what's cooking" for some weeks now)
- Or is not accepted at all

According to what you said, I only have two options:
- Either I fork libgit2, or
- I keep my feature in my application and do not contribute my feature
to libgit2

It looks even more insane now!

What about rephrasing the libgcc exception to something like: "if you
have a patch, and sent us that patch, but we put the patch in stand-by
or declided the patch, you are still allowed to combine libgit2 with
your closed-source application". After all, the fault is not in the
closed-source part (I contributed the patch, it is 100% open-source
and only uses 100% open-source) but in the libgit2 part (patch is on
hold or not accepted at all).

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: git to libgit2 code relicensing

[Andreas Ericsson]

Pau Garcia i Quiles wrote:
> On Sat, Nov 15, 2008 at 12:05 PM, Andreas Ericsson <ae@op5.se> wrote:
> 
>>> Do you mean if I write a patch to libgit2, send it upstream and make
>>> it public on my website but it is not accepted upstream, I cannot link
>>> my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
>>> software?
>> I think that's the case, yes.
>>
>>> It looks insane to me: I wrote the patch and made it public
>>> but you guys did not accept it!
>>>
>> Well, if you wrote a patch that uses a closed-source database library
>> to store git objects in, how would that benefit the community even if
>> you published the patch?
> 
> The case I had in mind is not that but this: say I write a patch which
> is totally open-source and uses only open-source software to add some
> feature to libgit2 but I want to link that libgit2 + mypatch to a
> closed source application (say, for instance, software for military
> use, which I'm not allowed to open source). To state it clearly:
> - My contribution is 100% open source
> - My contribution is 100% towards libgit2
> - In fact, I could add that very feature to my application instead of
> libgit2 but as I'm open-source-friendly, I decide to contribute that
> patch to libgit2.
> 
> For some reason, that patch:
> - Is not accepted for some time (for instance, I'm thinking in that
> tcl/tk limitation which is preventing Junio from merging a patch, it's
> been in the "what's cooking" for some weeks now)
> - Or is not accepted at all
> 
> According to what you said, I only have two options:
> - Either I fork libgit2, or
> - I keep my feature in my application and do not contribute my feature
> to libgit2
> 
> It looks even more insane now!
> 

No, it's still sane. You can keep the code in your application until
that patch is applied upstream. Besides, given the nature of shared
libraries you'd probably have to fall back to the version in your
app for quite some time anyways.

> What about rephrasing the libgcc exception to something like: "if you
> have a patch, and sent us that patch, but we put the patch in stand-by
> or declided the patch, you are still allowed to combine libgit2 with
> your closed-source application". After all, the fault is not in the
> closed-source part (I contributed the patch, it is 100% open-source
> and only uses 100% open-source) but in the libgit2 part (patch is on
> hold or not accepted at all).
> 

Rephrasing an existing license is really, really stupid, as it means
companies that want to build stuff on top of it will have to do the
legal procedure all over again.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git to libgit2 code relicensing

[David Brown]

On Sat, Nov 15, 2008 at 11:28:39AM +0100, Pau Garcia i Quiles wrote:
>> Shawn posted the exact text. The spirit of that license is that anyone can
>> use an unmodified version of the library for whatever they want, but it's
>> illegal to link non-GPL software to an altered version of the library. That
>> is, the git community will get all changes back while other projects can
>> use the official version of the library without having to worry about
>> licensing issues. EvilCompany cannot make changes to the library and then
>> link non-GPL'd software to their changed version. They can do that if they
>> send their library changes upstream and then only use them once they're
>> considered "official" though.
>
>Do you mean if I write a patch to libgit2, send it upstream and make
>it public on my website but it is not accepted upstream, I cannot link
>my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
>software? It looks insane to me: I wrote the patch and made it public
>but you guys did not accept it!

The license is not clear on this, at all.  Since under the GPLv2, you
are allowed to make a derivative work, and distribute that, you are
then basing your binary off of your particular distribution.  The
license does not have a notion of an "official" version.  So, it might
be satisfied as long as you base it off of something that is
distributed.

But, yes, it is vaguely worded and unclear in it's intent.

David

Re: git to libgit2 code relicensing

[Daniel Barkalow]

On Fri, 14 Nov 2008, Andreas Ericsson wrote:

> I've been working quite a lot on git -> libgit2 code moving,
> but the licensing stuff is a bit depressing, as I can't know
> if the work I'm doing is for nothing or not.
> 
> The license decided for libgit2 is "GPL with gcc exception".
> Those who are OK with relicensing their contributions under
> that license for the purpose of libgit2, can you please say
> so?

I'm fine with it for all my code.

	-Daniel
*This .sig left intentionally blank*

Re: git to libgit2 code relicensing

[Andreas Ericsson]

Christian Couder wrote:
> Hi Andreas,
> 
> Le vendredi 14 novembre 2008, Andreas Ericsson a écrit :
>> I've been working quite a lot on git -> libgit2 code moving,
> 
> It would be nice if there was somewhere on the web where your work could be 
> seen. If there is already, could you send (or resend) the URL? This way 
> people might have look and perhaps even help you. (Though I don't promise 
> anything as I have already a lot of things on my TODO list.) Thanks in 
> advance.
> 

When I was about to, I realized these licensing issues actually made it
illegal to do so without getting the permissions from the involved authors.
Now that Linus and a lot of other core contributors have given their consent,
I'll be able to start re-ordering the commits so I can publish those parts
originating from consenting authors while holding off on those that I can't
tell for sure are ok with it. Legal issues are no fun what so ever.

>> but the licensing stuff is a bit depressing, as I can't know
>> if the work I'm doing is for nothing or not.
>>
>> The license decided for libgit2 is "GPL with gcc exception".
>> Those who are OK with relicensing their contributions under
>> that license for the purpose of libgit2, can you please say
>> so?
> 
> It's ok to relicense my git related work under the "GPL with gcc exception" 
> license.
> 

Thank you. With the current list of ok's 73.09% of the code in git.git
seems to be relicenseable for the purpose of libgit2. That will provide
quite a kickstart.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git to libgit2 code relicensing

[Johannes Schindelin]

Hi,

On Sun, 16 Nov 2008, Andreas Ericsson wrote:

> With the current list of ok's 73.09% of the code in git.git seems to be 
> relicenseable for the purpose of libgit2. That will provide quite a 
> kickstart.

I doubt it.  Most of that code was written with the execute-once 
mentality.  And with the we-have-posix mentality.

Two things we do not _want_ in libgit2.

Ciao,
Dscho

Re: git to libgit2 code relicensing

[Sverre Rabbelier]

On Sun, Nov 16, 2008 at 22:00, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> I doubt it.  Most of that code was written with the execute-once
> mentality.  And with the we-have-posix mentality.
>
> Two things we do not _want_ in libgit2.

But at least with permission from the authors we're allowed to look at
the original code without preventing us from licensing the new code as
GPL+exception ;).

-- 
Cheers,

Sverre Rabbelier

Re: git to libgit2 code relicensing

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Sun, 16 Nov 2008, Andreas Ericsson wrote:
> 
>> With the current list of ok's 73.09% of the code in git.git seems to be 
>> relicenseable for the purpose of libgit2. That will provide quite a 
>> kickstart.
> 
> I doubt it.  Most of that code was written with the execute-once 
> mentality.  And with the we-have-posix mentality.
> 

"Copy-rewrite", naturally. Being able to lift much of the data-munging code
is a great benefit. It's basically just the revision traversal (which is
heavy on state-dependant code) that I haven't quite figured out how to do
yet, but I believe Shawn's idea of using revision pools is most likely the
way to go. Each application has to make sure a pool isn't modified by more
than one thread, but each application can have as many pools as it likes.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git to libgit2 code relicensing

[Shawn O. Pearce]

Andreas Ericsson <ae@op5.se> wrote:
>
> "Copy-rewrite", naturally. Being able to lift much of the data-munging code
> is a great benefit. It's basically just the revision traversal (which is
> heavy on state-dependant code) that I haven't quite figured out how to do
> yet, but I believe Shawn's idea of using revision pools is most likely the
> way to go. Each application has to make sure a pool isn't modified by more
> than one thread, but each application can have as many pools as it likes.

I also like Pierre's idea of using annotation data in different
annotation pools, and storing the rewritten parents in such a pool.
Then an application can more easily reuse a revision pool, by just
tossing the rewritten parent pool, or any other annotations it
wants to recompute.

It may still be important to have revision pools and make them
not thread-safe, so we can void fine-grained locking costs in
the library during the tight revision traversal loops.

-- 
Shawn.

Re: git to libgit2 code relicensing

[Andreas Ericsson]

Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> "Copy-rewrite", naturally. Being able to lift much of the data-munging code
>> is a great benefit. It's basically just the revision traversal (which is
>> heavy on state-dependant code) that I haven't quite figured out how to do
>> yet, but I believe Shawn's idea of using revision pools is most likely the
>> way to go. Each application has to make sure a pool isn't modified by more
>> than one thread, but each application can have as many pools as it likes.
> 
> I also like Pierre's idea of using annotation data in different
> annotation pools, and storing the rewritten parents in such a pool.
> Then an application can more easily reuse a revision pool, by just
> tossing the rewritten parent pool, or any other annotations it
> wants to recompute.
> 
> It may still be important to have revision pools and make them
> not thread-safe, so we can void fine-grained locking costs in
> the library during the tight revision traversal loops.
> 

Well, since git_revpool (I've renamed it in my tree, as I had a hard
time not pronouncing it "rev pointer" in my head) is a variable the
user gets back from us, it's about as thread-safe as the various IO
interfaces. That is, if several threads try to write at once, weird
things happen. That's just something the application writer has to
take care of though, and we should make sure to mark the revpool as
"const" in functions that will only read from it without modifying
it.

Speaking of threads though; I think I've solved the thread-local
storage problem for libgit. At least for pretty much all compilers
we care about (gcc, Intel C, MSVC, MSVC++) and a slew of others,
which means we can probably use a saner error-handling now. Personally
I think that's something we can benefit greatly from, as many functions
return "int" where they should return a pointer, only to accommodate
error handling.

I'll get those commits reordered and publish what I've got right now.
http://git.op5.org/git/?p=git/libgit2.git;a=summary will have most of
the stuff in an hour or so.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git to libgit2 code relicensing

[René Scharfe]

Andreas Ericsson schrieb:
> The license decided for libgit2 is "GPL with gcc exception".
> Those who are OK with relicensing their contributions under
> that license for the purpose of libgit2, can you please say
> so?

Fine with me.

Thanks,
René

Re: git to libgit2 code relicensing

[Kristian Høgsberg]

On Fri, 2008-11-14 at 21:59 +0100, Andreas Ericsson wrote:
> I've been working quite a lot on git -> libgit2 code moving,
> but the licensing stuff is a bit depressing, as I can't know
> if the work I'm doing is for nothing or not.
> 
> The license decided for libgit2 is "GPL with gcc exception".
> Those who are OK with relicensing their contributions under
> that license for the purpose of libgit2, can you please say
> so?
> 
> I'm planning on writing a tool for this that will have "ok",
> "not ok" and "ask-each-patch" as options.
> 
> The list of people whose position I know is rather short.
> Please correct me if you're on it and would like not to be.
> Junio C. Hamano		ask
> Johannes Schindelin	ok
> Shawn O. Pearce		ok
> Andreas Ericsson	ok
> Pierre Habouzit		ok
> Brian Gernhardt		ok
> 
> 
> I've put everyone who "owns" more than 500 lines of code
> on the bcc list, figuring your permission is important
> but that you don't want the hundreds (well, one can hope)
> of emails from people saying "ok". The list of major owners
> was generated with "git showners *.c" in a worktree from
> the next branch of git.git.

You're welcome to use any of the code I've written under the GPL +
exception license, though most of it is probably not that useful, as
it's mostly porting shell commands to builtins.  I'm very happy to see
this effort start up, as I've been tempted to do something similar
myself :)

cheers,
Kristian