# Approxidate licensing 6 messages from 2006-10-10 to 2006-10-11. Participants: Daniel Barkalow, Linus Torvalds, Edesio Costa e Silva, Junio C Hamano, David Woodhouse. Thread: https://gitlist.dev/t/5873 ## Daniel Barkalow, 2006-10-10 17:39 Subject: Approxidate licensing Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0610101246241.9789%40iabervon.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. ``` ## Linus Torvalds, 2006-10-10 18:17 Subject: Re: Approxidate licensing Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0610101102560.3952%40g5.osdl.org In-Reply-To: ``` 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 } }; ``` ## Edesio Costa e Silva, 2006-10-10 18:33 Subject: Re: Approxidate licensing Message-ID: <20061010183325.GC12993@softaplic.com.br> URL: https://gitlist.dev/e/20061010183325.GC12993%40softaplic.com.br In-Reply-To: <1073a5540610101128q3fb9f68fsf3a28fbda20927d1@mail.gmail.com> ``` Try the TCL modules that parse date and time (tclGetDate.y and tclClock.c). They are licensed BSD style. Edésio > From: Daniel Barkalow > Date: Oct 10, 2006 2:39 PM > Subject: Approxidate licensing > To: Linus Torvalds , Junio C Hamano > , 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 ``` ## Junio C Hamano, 2006-10-10 19:23 Subject: Re: Approxidate licensing Message-ID: <7v64es0ycq.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v64es0ycq.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Daniel Barkalow 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 C Hamano, 2006-10-11 07:55 Subject: Re: Approxidate licensing Message-ID: <7viriruw16.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7viriruw16.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Daniel Barkalow 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. ``` ## David Woodhouse, 2006-10-11 07:57 Subject: Re: Approxidate licensing Message-ID: <1160553423.7920.60.camel@pmac.infradead.org> URL: https://gitlist.dev/e/1160553423.7920.60.camel%40pmac.infradead.org In-Reply-To: ``` 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 ```