Approxidate licensing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]