Regarding licensing issues - quoting the New BSD license: "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer." IMO that means that you should just include the copyright, conditions and the disclaimer in a code comment at the top of the include file. Anyway, big +1 from me for such a date.inc in core. Splitting it into two include files, where one has only the most needed functions and the other one is included only if needed, sounds perfect. regards, frando Karen Stevenson schrieb:

<snip> What's worrying me more is two things: - do we really want to maintain two fork off PEAR, as you mention yourself - this means a lot of code to be parsed that won't really be used afterwards in most cases.

selective loading, as in php5's _autoload mechanism, would obviate the second point, but only works out of the box with PHP5 (which would fit nicely with the GoPHP5 thread)... and with classes, not pure functions. </snip>

First of all, both of these are VERY stable modules that are rarely updated, so keeping up with them is not like trying to fork something complicated (like TinyMCE, for instance). The ADODB date library has not been changed in years. The PEAR Date Calc library has had a more recent update, but the change was mostly just re-arranging the code and adding a couple new functions. The PEAR Date Calc library from several years ago still works fine. Anyway, I really don't think maintaining them would be a big problem.

There are advantages to Drupalizing them instead of including them as-is -- PEAR Date Calc comes with a lot of PEAR baggage that is not even needed and half of the ADODB date library is documentation or test code that I would either remove or put into a separate files. Also I've already run into problems with the ADODB date library when more than one module uses it and the same functions get declared from different included files. We need one central, shared location for these kinds of things.

Parsing possibly unneeded code is an issue, but we can find a solution for that. My practice has been to try to find ways to include files only when needed and I would certainly be in favor of that in this instance. We can do it lots of ways -- break the includes down between often and rarely used functions; create a basic include file that only contains wrapper functions that include_once() the necessary file then call the function only when it is needed; break out less common code into optional modules; etc etc. Again, if we Drupalize the code we can make changes like that.

Anyway, the basic question is whether this is something that makes sense for core. If not, I won't push it any further, if so, I'll propose a patch. I definitely plan to include it as a part of Date API if it's not in core, so I'm going to do the work either way (and I plan to add it to the 5x branch of Date API either way).

And my original question -- does anyone know exactly how I should attribute the original authors and licenses in my Drupalized version?

Karen