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

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
--

Fine with me.
Thanks,

René

--

I'm fine with it for all my code.
	-Daniel

*This .sig left intentionally blank*

--

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

--

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

--

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)

--

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

--

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

--

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)

--

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
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

--

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.

--

Ok, I'm fine with this. 
			Linus

--

On Fri, Nov 14, 2008 at 03:46:58PM -0800, "Shawn O. Pearce" <spearce@spearc=
IANAL - what is the difference between this and the LGPL?
Thanks.

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

--

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.

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.
--=20

=C2=B7O=C2=B7  Pierre Habouzit

=C2=B7=C2=B7O                                                madcoder@debia=

n.org

OOO                                                http://www.madism.org

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

--

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.

--

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

--

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

--

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
--

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
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
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

--

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 shoul...
[ message continues ]

On Fri, Nov 14, 2008 at 22:33, Martin Koegler
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

--

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

--