Hi Dmitry and all, First of all, please accept my apologies for failing to find the time to participate in the licensing issues discussion in December. It is a topic that I would like to discuss and arrive at a conclusion as I often happen to write code that I'd like to release to the public under the most relaxed terms possible. I thought that not claiming copyright (or even disclaiming copyright) and placing the code into the public domain would be it, but apparently in many (most? all?) jurisdictions there's no explicitly specified way for someone to place their works into the public domain (although the concept of public domain does exist - and stuff "falls" there as old copyrights expire) and now it has also been mentioned that some jurisdictions don't even recognize public domain at all (I have not yet seen/heard a lawyer state that, though).
A possible solution could be to simultaneously try to place stuff in the public domain with a statement to that extent and license it to the public under very liberal terms. One issue with it is that I have to not claim or disclaim copyright in order to place a work of mine into the public domain, yet I have to be the copyright holder in order to license that work. Maybe this can be taken care of with a severability clause, making either the public domain or the license work in any given jurisdiction. But I'd rather see/hear a lawyer comment on that before I possibly go that route. That said, a lot of software that we use has been placed in the public domain by its authors. This includes some software by D. J. Bernstein, perhaps best known as the author of qmail, who is also known for the Bernstein vs. United States litigation - http://cr.yp.to/export.html - so perhaps he should know the law. Then, public domain is officially recognized as being compatible with GNU GPL by the FSF - http://www.fsf.org/licensing/licenses/ - and is apparently recognized by the OSI - http://opensource.org/node/239 On Tue, Feb 05, 2008 at 02:34:40PM +0300, Dmitry Stogov wrote: > We are going to include your md5() implementation into php-5.3.0. Great! > I confirm at least 25% md5() speedup on my Core2 3GHz, however license > issues are not clear. > We are going to distribute files under standard PHP license including > your original copyright notes. > The files which are going to be committed are attached. > > Please confirm your agreement. Confirmed. Please note, however, that there were no "copyright notes" on my original files; instead, there was an authorship note and a public domain statement. I also have some comments on the modified files: > | Copyright (c) 1997-2008 The PHP Group | ... > | Author: Solar Designer <solar at openwall.com> | So you claim copyright to a modified version of my code, that I had placed in the public domain. This is fine by me. I do not formally require it (in fact, I can't), but maybe the "Author" line could be changed to either: | Original author: Solar Designer <solar at openwall.com> | or: | Authors: Solar Designer <solar at openwall.com> with further | | modifications by others. | (or you can make it more explicit, e.g. "... by The PHP Group" if that is appropriate - or whatever). > /* MD5 context. */ > typedef struct { > php_uint32 lo, hi; > php_uint32 a, b, c, d; > unsigned char buffer[64]; > php_uint32 block[16]; > } PHP_MD5_CTX; Maybe it would be better to do: typedef php_uint32 MD5_u32plus; and use the latter type. This would reduce the number of changes between my version of the code and yours, making it easier for you to sync to any newer versions of the code that I might make. > | Author: Solar Designer <solar at openwall.com> | If you do choose to change this in the .h file, then do the same in the .c, obviously. > #if (defined(__APPLE__) || defined(__APPLE_CC__)) && (defined(__BIG_ENDIAN__) > || defined(__LITTLE_ENDIAN__)) > # if defined(__LITTLE_ENDIAN__) > # undef WORDS_BIGENDIAN > # else > # if defined(__BIG_ENDIAN__) > # define WORDS_BIGENDIAN > # endif > # endif > #endif This looks wrong to me. One of the specific properties of my implementation is that it does not strictly depend on the endianness being correctly specified at compile-time (and at all, for that matter). However, if you do happen to use the (little-endian and unaligned-OK) optimized code on a system that is not in fact little-endian or does not in fact tolerate unaligned accesses, then problems will arise! So any #if's you use must assume (might-be-big-endian and might-disallow-unaligned) by default. In fact, I am only aware of three widespread and general-purpose architectures that satisfy the criteria for the optimized code: #if defined(__i386__) || defined(__x86_64__) || defined(__vax__) Thus, I suggest that you leave the above #if intact, the way it was in the patch that I submitted. Do not explicitly check for any endianness macros - this is bound to cause problems. > /* > * * SET reads 4 input bytes in little-endian byte order and stores them > * * in a properly aligned word in host byte order. > * * > * * The check for little-endian architectures that tolerate unaligned > * * memory accesses is just an optimization. Nothing will break if it > * * doesn't work. > * */ > #ifndef WORDS_BIGENDIAN > # define SET(n) \ > (*(php_uint32 *)&ptr[(n) * 4]) > # define GET(n) \ > SET(n) > #else ... As explained above, I strongly recommend that you revert your "#ifndef WORDS_BIGENDIAN" to my "#if ..." What if an architecture is big-endian, but WORDS_BIGENDIAN just happens to not be specified? You'll have incorrect results (not MD5), whereas with my version of the code, everything will be just fine. Similarly, regardless of endianness, if WORDS_BIGENDIAN is not specified (maybe because the architecture is in fact little-endian), but the architecture does not tolerate unaligned accesses (at all or supports them with kernel emulation), things will go wrong (SIGBUS or very poor performance and a flood of kernel messages). This issue can't occur with my original #if that only lists specific known-safe architectures. > data = body(ctx, data, size & ~(unsigned long)0x3f); If you change all of my unsigned long's to size_t, you should change this one as well. When on a 64-bit system (userland pointer size), your size_t better be 64-bit as well (I have not checked whether this is necessarily the case; I hope so). > PHPAPI void PHP_MD5Final(unsigned char *result, PHP_MD5_CTX *ctx) > { > unsigned long used, free; Here's another one. Thanks, Alexander Peslyak <solar at openwall.com> GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
