GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Linus Torvalds]

Btw, does anybody have strong opinions on the license? I didn't put in a 
COPYING file exactly because I was torn between GPLv2 and OSL2.1.

I'm inclined to go with GPLv2 just because it's the most common one, but I 
was wondering if anybody really had strong opinions. For example, I'd 
really make it "v2 by default" like the kernel, since I'm sure v3 will be 
fine, but regardless of how sure I am, I'm _not_ a gambling man.

		Linus

Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Petr Baudis]

Dear diary, on Mon, Apr 11, 2005 at 02:20:52AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> Btw, does anybody have strong opinions on the license? I didn't put in a 
> COPYING file exactly because I was torn between GPLv2 and OSL2.1.
> 
> I'm inclined to go with GPLv2 just because it's the most common one, but I 
> was wondering if anybody really had strong opinions. For example, I'd 
> really make it "v2 by default" like the kernel, since I'm sure v3 will be 
> fine, but regardless of how sure I am, I'm _not_ a gambling man.

Oh, I wanted to ask about this too. I'd mostly prefer GPLv2 (I have no
problem with the version restriction, I usually do it too), it's the one
I'm mostly familiar with and OSL appears to be incompatible with GPL (at
least FSF says so about OSL1.0), which might create various annoying
issues. I hate when licenses get in my way and prevent me to possibly
include some useful code.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.

Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Nur Hussein]

> Btw, does anybody have strong opinions on the license? I didn't put in a 
> COPYING file exactly because I was torn between GPLv2 and OSL2.1.

I think GPLv2 would create the least amount of objection in the
community, so I'd probably want to go with that.

		Nur Hussein

Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Ingo Molnar]

* Linus Torvalds <torvalds@osdl.org> wrote:

> Btw, does anybody have strong opinions on the license? I didn't put in 
> a COPYING file exactly because I was torn between GPLv2 and OSL2.1.
> 
> I'm inclined to go with GPLv2 just because it's the most common one, 
> but I was wondering if anybody really had strong opinions. For 
> example, I'd really make it "v2 by default" like the kernel, since I'm 
> sure v3 will be fine, but regardless of how sure I am, I'm _not_ a 
> gambling man.

is there any fundamental problem with going with v2 right now, and then 
once v3 is out and assuming it looks ok, all newly copyrightable bits 
(new files, rewrites, substantial contributions, etc.) get a v3 
copyright? (and the collection itself would be v3 too) That method 
wouldnt make it fully v3 automatically once v3 is out, but with time 
there would be enough v3 bits in it to make it essentially v3. This way 
we wouldnt have to blanket trust v3 before having seen it, and wouldnt 
be stuck at v2 either.

	Ingo

Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Florian Weimer]

* Ingo Molnar:

> is there any fundamental problem with going with v2 right now, and then 
> once v3 is out and assuming it looks ok, all newly copyrightable bits 
> (new files, rewrites, substantial contributions, etc.) get a v3 
> copyright? (and the collection itself would be v3 too) That method 
> wouldnt make it fully v3 automatically once v3 is out, but with time 
> there would be enough v3 bits in it to make it essentially v3.

Almost certainly, v3 will be incompatible with v2 because it adds
further restrictions.  This means that your proposal would result in
software which is not redistributable by third parties.

Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Adam J. Richter]

On 2005-04-11, Linus Torvalds wrote:
>I'm inclined to go with GPLv2 just because it's the most common one [...]

	You may want to use a file from GPL'ed monotone that
implements a substantial diff optimization described in the August
1989 paper by Sun Wu, Udi Manber and Gene Myers ("An O(NP) Sequence
Comparison Algorithm").  According to th file, that implementation
was a port of some Scheme code written by Aubrey Jaffer to C++ by
Graydon Hoare.  (By the way, I would prefer that git just punt to
user level programs for diff and merge when all of the versions
involved are different or at least have a very thin interface
for extending the facility, because I would like to do some character
based merge stuff.)

	It looks to me like the anti-patent provisions of OSLv2.1
could be circumvented by an offender creating a separate company
to do patent litigation.  So, I think you'll find that the software
reuse benefits (both to GIT and to other software projects) of the
more widely used GPL ougtweigh the anti-patent benefits of OSLv2.1.

	Although I like the idea of anti-patent provisions, such
as those in OSLv2.1, I think mutual compatability of free
software is probably more consequential, even from a purely
political perspective.

	Perhaps you might want to consider offering the code
under the distributor's choice of either license if you want
to offer the very minor benefits of slightly easier compliance
to those who do not litigate software patents, or, perhaps more
importantly, the ability of the software to be copied into
OSLv2.1 projects (if there are any).

                    __     ______________ 
Adam J. Richter        \ /
adam@yggdrasil.com      | g g d r a s i l

Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Florian Weimer]

* Petr Baudis:

>> Almost certainly, v3 will be incompatible with v2 because it adds
>> further restrictions.  This means that your proposal would result in
>> software which is not redistributable by third parties.
>
> Hmm, what would be actually the point in introducing further
> restrictions? Anyone who then wants to get around them will just
> distribute the software with the "any later version" provision under
> GPLv2, and GPLv3 will have no impact expect for new software with "v3 or
> any later version" provision. What am I missing?

Software continues to evolve.  The copyright owners can relicense the
code base under v3, and use v3 for all subsequent changes to the
software.  The trouble with relicensing is that you have to contact
all copyright holders (or remove their code).  This tends to be
impossible in long-running projects without contractual agreements
between the developers.

Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Adam J. Richter]

On Mon, 11 Apr 2005 20:45:38 +0200, Peter Baudis wrote:
>  Hello,

>  please do not trim the cc list so agressively.

Sorry.  I read the list from a web site that does not show the
cc lists.  I'll try to cc more people from the relevant discussions
though.  On the other hand, I've dropped Linus from this message,
as it just points to something he previously said.

>Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter
>where "Adam J. Richter" <adam@yggdrasil.com> told me that...
>..snip..
>> Graydon Hoare.  (By the way, I would prefer that git just punt to
>> user level programs for diff and merge when all of the versions
>> involved are different or at least have a very thin interface
>> for extending the facility, because I would like to do some character
>> based merge stuff.)
>..snip..

>But this is what git already does. I agree it could do it even better,
>by checking environment variables for the appropriate tools (then you
>could use that to pass diff e.g. -p etc.).

This message from Linus seemed to imply that git was going to get
its own 3-way merge code:

| Then the bad news: the merge algorithm is going to suck. It's going to be
| just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
| understanding of renames etc. I'll try to find the best parent to base the
| merge off of, although early testers may have to tell the piece of crud
| what the most recent common parent was.

( from http://marc.theaimsgroup.com/?l=linux-kernel&m=111320013100822&w=2 )


                    __     ______________
Adam J. Richter        \ /
adam@yggdrasil.com      | g g d r a s i l

Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Petr Baudis]

Dear diary, on Tue, Apr 12, 2005 at 03:20:18AM CEST, I got a letter
where "Adam J. Richter" <adam@yggdrasil.com> told me that...
> >Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter
> >where "Adam J. Richter" <adam@yggdrasil.com> told me that...
> >..snip..
> >> Graydon Hoare.  (By the way, I would prefer that git just punt to
> >> user level programs for diff and merge when all of the versions
> >> involved are different or at least have a very thin interface
> >> for extending the facility, because I would like to do some character
> >> based merge stuff.)
> >..snip..
> 
> >But this is what git already does. I agree it could do it even better,
> >by checking environment variables for the appropriate tools (then you
> >could use that to pass diff e.g. -p etc.).
> 
> This message from Linus seemed to imply that git was going to get
> its own 3-way merge code:
> 
> | Then the bad news: the merge algorithm is going to suck. It's going to be
> | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
> | understanding of renames etc. I'll try to find the best parent to base the
> | merge off of, although early testers may have to tell the piece of crud
> | what the most recent common parent was.

Well, from what I can read it says "just plain 3-way merge, the same
RCS/CVS thing you've seen before". :-)

Basically, when you look at merge(1) :

SYNOPSIS
       merge [ options ] file1 file2 file3
DESCRIPTION
       merge  incorporates  all  changes that lead from file2 to file3
into file1.

The only big problem is how to guess the best file2 when you give it
file3 and file1.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.

Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Geert Uytterhoeven]

On Tue, 12 Apr 2005, Petr Baudis wrote:
> Dear diary, on Tue, Apr 12, 2005 at 03:20:18AM CEST, I got a letter
> where "Adam J. Richter" <adam@yggdrasil.com> told me that...
> > >Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter
> > >where "Adam J. Richter" <adam@yggdrasil.com> told me that...
> > >..snip..
> > >> Graydon Hoare.  (By the way, I would prefer that git just punt to
> > >> user level programs for diff and merge when all of the versions
> > >> involved are different or at least have a very thin interface
> > >> for extending the facility, because I would like to do some character
> > >> based merge stuff.)
> > >..snip..
> > 
> > >But this is what git already does. I agree it could do it even better,
> > >by checking environment variables for the appropriate tools (then you
> > >could use that to pass diff e.g. -p etc.).
> > 
> > This message from Linus seemed to imply that git was going to get
> > its own 3-way merge code:
> > 
> > | Then the bad news: the merge algorithm is going to suck. It's going to be
> > | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
> > | understanding of renames etc. I'll try to find the best parent to base the
> > | merge off of, although early testers may have to tell the piece of crud
> > | what the most recent common parent was.
> 
> Well, from what I can read it says "just plain 3-way merge, the same
> RCS/CVS thing you've seen before". :-)
> 
> Basically, when you look at merge(1) :
> 
> SYNOPSIS
>        merge [ options ] file1 file2 file3
> DESCRIPTION
>        merge  incorporates  all  changes that lead from file2 to file3
> into file1.
> 
> The only big problem is how to guess the best file2 when you give it
> file3 and file1.

That's either the point just before you started modifying the file, or your
last merge point. Sounds simple, but if your SCM system doesn't track merges,
your SOL...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Petr Baudis]

Dear diary, on Tue, Apr 12, 2005 at 10:39:40AM CEST, I got a letter
where Geert Uytterhoeven <geert@linux-m68k.org> told me that...
> On Tue, 12 Apr 2005, Petr Baudis wrote:
..snip..
> > Basically, when you look at merge(1) :
> > 
> > SYNOPSIS
> >        merge [ options ] file1 file2 file3
> > DESCRIPTION
> >        merge  incorporates  all  changes that lead from file2 to file3
> > into file1.
> > 
> > The only big problem is how to guess the best file2 when you give it
> > file3 and file1.
> 
> That's either the point just before you started modifying the file, or your
> last merge point. Sounds simple, but if your SCM system doesn't track merges,
> your SOL...

Well, yes, but the last merge point search may not be so simple:

A --1---2----6---7
B    \   `-4-.  /
C     `-3-----5'

Now, when at 7, your last merge point is not 1, but 2.

What I have proposed at the git mailing list was to have simple merging
tracking - merges/branch1/branch2 directory structure which would store
merges from branch2 to branch1. Then, when merging say to branch3, you
traverse all of them and if any of the branch1/* commits is newer than
branch3/*, you update it.

The disadvantage is that you now need to strictly use gitmerge.sh to do
the merges - Linus' revtree solution is nicer in the regard that it
works without any explicit bookkeeping, and tracks any merges properly
recorded with commit-file; it is more complex and more expensive,
though.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.

Re: Re: Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Petr Baudis]

Dear diary, on Tue, Apr 12, 2005 at 11:50:48AM CEST, I got a letter
where Petr Baudis <pasky@ucw.cz> told me that...
> Dear diary, on Tue, Apr 12, 2005 at 10:39:40AM CEST, I got a letter
> where Geert Uytterhoeven <geert@linux-m68k.org> told me that...
> > On Tue, 12 Apr 2005, Petr Baudis wrote:
> ..snip..
> > > Basically, when you look at merge(1) :
> > > 
> > > SYNOPSIS
> > >        merge [ options ] file1 file2 file3
> > > DESCRIPTION
> > >        merge  incorporates  all  changes that lead from file2 to file3
> > > into file1.
> > > 
> > > The only big problem is how to guess the best file2 when you give it
> > > file3 and file1.
> > 
> > That's either the point just before you started modifying the file, or your
> > last merge point. Sounds simple, but if your SCM system doesn't track merges,
> > your SOL...
> 
> Well, yes, but the last merge point search may not be so simple:
> 
> A --1---2----6---7
> B    \   `-4-.  /
> C     `-3-----5'
> 
> Now, when at 7, your last merge point is not 1, but 2.

...and this is obviously wrong, sorry. You would lose 3 this way.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.

Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Chris Friesen]

Petr Baudis wrote:
> Dear diary, on Tue, Apr 12, 2005 at 11:50:48AM CEST, I got a letter

>>Well, yes, but the last merge point search may not be so simple:
>>
>>A --1---2----6---7
>>B    \   `-4-.  /
>>C     `-3-----5'
>>
>>Now, when at 7, your last merge point is not 1, but 2.
> 
> 
> ...and this is obviously wrong, sorry. You would lose 3 this way.

Wouldn't the delta betweeen 2 and 5 include any contribution from 3?

Chris