Approxidate licensing

Approxidate licensing

[Daniel Barkalow]

I'm working on an LGPL project (for my company; it's obscure enough and 
we're lazy enough that we're not really distributing it in general in 
either source or binary form), and I'm running into the usual date parsing 
issue (i.e., all the standard functions are broken in various ways). My 
plan has been to write my own, but it's hard to get the motivation when 
approxidate exists, works well, and is open source.

Would the three of you agree to license date.c under the LGPL or BSD? It 
looks like you're the only authors of non-trivial changes [1]. And it seems 
reasonable to want the date parsing thing under non-GPL terms outside of 
git.

	-Daniel
*This .sig left intentionally blank*

[1] git log and git blame are pretty impressive, but they don't quite 
catch that most of date.c was written by David as part of commit-tree.c, 
then Tony replaced it with a version that uses curl, then Edgar separated 
it out into a date.c and simultaneously reverted Tony's changes. On the 
other hand, the commit messages do say this, and you can use git log and 
git blame to verify that they're true. The only thing they don't let 
you verify is what the differences are between the date.c added in 
ecee9d9e and the similar part of commit-tree.c in 812666c8. If someone 
wants to make git blame *really* magic, date.c would be a good test case.

Re: Approxidate licensing

[Linus Torvalds]

On Tue, 10 Oct 2006, Daniel Barkalow wrote:
> 
> Would the three of you agree to license date.c under the LGPL or BSD? It 
> looks like you're the only authors of non-trivial changes [1]. And it seems 
> reasonable to want the date parsing thing under non-GPL terms outside of 
> git.

I'm not a huge fan of the LGPL, especially with the recent issues of 
GPLv3. The reason? The LGPL is expressly designed to be compatible with 
the GPL, but it's designed to be compatible with any version (and you 
can't limit it, the way you can the real GPL).

So you can take LGPL 2.1 code, and relicense it under GPLv3, and make 
changes to it, and those changes won't be available to a GPLv2 project.

That said, I don't think the date.c code is all that important, and I 
don't see why anybody would do something nasty like that anyway, so I 
guess I don't actually care. A lot of the approxidate code was actually 
written as a joke, and it will parse just about anything without any 
error, and without telling you that it returned a date that may not make 
any sense at all.

For example, currently

	./test-date "$(cat date.c)"

returns

	Tue Nov 30 11:58:59 1937

for me, but don't ask me why. It's just put together the random numbers 
and month-names embedded in the source and made some insane decision that 
it must be a date (since you told it so). And it never returned an error.

Some other things are just silly and not even correct

	./test-date "One year ago yesterday at tea-time"

which doesn't even give the right answer (because it will go _backwards_ 
to tea-time on Oct 8th, even though it obviously _should_ return "Oct 9, 
17:00". I don't have the energy to try to fix it.

It also needs this important patch to be complete. I don't know how this 
could ever have fallen through the cracks!

		Linus
---
diff --git a/date.c b/date.c
index 1825922..0b06994 100644
--- a/date.c
+++ b/date.c
@@ -657,6 +657,7 @@ static const struct typelen {
 	{ "hours", 60*60 },
 	{ "days", 24*60*60 },
 	{ "weeks", 7*24*60*60 },
+	{ "fortnights", 2*7*24*60*60 },
 	{ NULL }
 };	
 

Re: Approxidate licensing

[Edesio Costa e Silva]

Try the TCL modules that parse date and time (tclGetDate.y and
tclClock.c). They are licensed BSD style.

Edésio

> From: Daniel Barkalow <barkalow@iabervon.org>
> Date: Oct 10, 2006 2:39 PM
> Subject: Approxidate licensing
> To: Linus Torvalds <torvalds@osdl.org>, Junio C Hamano
> <junkio@cox.net>, dwmw2@infradead.org
> Cc: git@vger.kernel.org
> 
> 
> I'm working on an LGPL project (for my company; it's obscure enough and
> we're lazy enough that we're not really distributing it in general in
> either source or binary form), and I'm running into the usual date parsing
> issue (i.e., all the standard functions are broken in various ways). My
> plan has been to write my own, but it's hard to get the motivation when
> approxidate exists, works well, and is open source.
> 
> Would the three of you agree to license date.c under the LGPL or BSD? It
> looks like you're the only authors of non-trivial changes [1]. And it seems
> reasonable to want the date parsing thing under non-GPL terms outside of
> git.
> 
>        -Daniel
> *This .sig left intentionally blank*
> 
> [1] git log and git blame are pretty impressive, but they don't quite
> catch that most of date.c was written by David as part of commit-tree.c,
> then Tony replaced it with a version that uses curl, then Edgar separated
> it out into a date.c and simultaneously reverted Tony's changes. On the
> other hand, the commit messages do say this, and you can use git log and
> git blame to verify that they're true. The only thing they don't let
> you verify is what the differences are between the date.c added in
> ecee9d9e and the similar part of commit-tree.c in 812666c8. If someone
> wants to make git blame *really* magic, date.c would be a good test case.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Approxidate licensing

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Would the three of you agree to license date.c under the LGPL or BSD? It 
> looks like you're the only authors of non-trivial changes [1]. And it seems 
> reasonable to want the date parsing thing under non-GPL terms outside of 
> git.

I do not think I have enough code in there to influence the
license of that file, so what I say below does not matter on
this particular issue.

The project as a whole is GPLv2 and GPLv2 only, but date.c is
isolated enough that I think there are valid form of using it in
your program without making your program a derived work.  In
other words, I do not think I have (even if I had written
significant part of it, which I didn't) right to demand to see
the rest of your program if you used date.c.  I do not think I
even have rights to ask about what kind of program it is.

My wishes about the code I write for this project is very
simple:

     If you improve my code that had helped you to make it help
     you even better, I would like to have that change back, so
     that your change would help me the same way as it helped
     you.

The readers may have noticed that I have slight problem with
GPLv2; in my wish it does not matter if you distribute the
result or not.  And I am selfish.  It is not about helping my
users, but about helping me ;-).

Junio's wishes [Was: Re: Approxidate licensing]

[Horst H. von Brand]

Junio C Hamano <junkio@cox.net> wrote:
> My wishes about the code I write for this project is very
> simple:
> 
>      If you improve my code that had helped you to make it help
>      you even better, I would like to have that change back, so
>      that your change would help me the same way as it helped
>      you.
> 
> The readers may have noticed that I have slight problem with
> GPLv2; in my wish it does not matter if you distribute the
> result or not.  And I am selfish.  It is not about helping my
> users, but about helping me ;-).

There is a small practical problem with that: How would you find out I'm
using a modified version of your code internally? Also, the "distribution"
part of GPLv2 is a useful filter: Only such modifications that are
worthwhile to distribute get back, not each and every corner I paint myself
into while playing around.

All in all, a nice balance, IMVHO.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Re: Junio's wishes [Was: Re: Approxidate licensing]

[Linus Torvalds]

On Tue, 10 Oct 2006, Horst H. von Brand wrote:
>
> There is a small practical problem with that: How would you find out I'm
> using a modified version of your code internally? Also, the "distribution"
> part of GPLv2 is a useful filter: Only such modifications that are
> worthwhile to distribute get back, not each and every corner I paint myself
> into while playing around.

Hey, I obviously agree that the GPLv2 is a good license, but at the same 
time, I think too many people tend to think _just_ about legal issues.

Sometimes the wishes of an author should matter, regardless of whether 
there is any law that forces you to do so. So I personally think a license 
that says: "if you improve this, give out the improvements regardless of 
whether you distribute things further or not" is a nice sentiment, and 
should be honored, regardless of whether you can legally enforce any such 
private tinkering or not.

			Linus

Re: Approxidate licensing

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> [1] git log and git blame are pretty impressive, but they don't quite 
> catch that most of date.c was written by David as part of commit-tree.c, 
> then Tony replaced it with a version that uses curl, then Edgar separated 
> it out into a date.c and simultaneously reverted Tony's changes. On the 
> other hand, the commit messages do say this, and you can use git log and 
> git blame to verify that they're true. The only thing they don't let 
> you verify is what the differences are between the date.c added in 
> ecee9d9e and the similar part of commit-tree.c in 812666c8. If someone 
> wants to make git blame *really* magic, date.c would be a good test case.

That's good to know.  I have in my head a super-duper blame that
I outlined in my obituary for git-annotate, but that is still a
vaporware and will continue to be for some time.

Re: Approxidate licensing

[David Woodhouse]

On Tue, 2006-10-10 at 13:39 -0400, Daniel Barkalow wrote:
> Would the three of you agree to license date.c under the LGPL or BSD? It 
> looks like you're the only authors of non-trivial changes [1]. And it seems 
> reasonable to want the date parsing thing under non-GPL terms outside of 
> git.

Yeah, LGPL and BSD are both fine by me -- although I don't actually
recognise much of my own code in there. 

Btw, why isn't the meaning of 'tea-time' properly modified according to
the locale?

-- 
dwmw2