Hello all!
Recently I've discovered Frank (IIRC) telling us that the MD5 unit is, in contrast to all other units (I just double-checked), not licenced under the GNU LGPL, or GPL with library exception clause, but rather plain GPL because it contains code from Ulrich Drepper's glibc imple- mentation of the MD5 algorithm.
I took the time and prepared a new, BSD-licenced, implementation of the code, while preserving the old framework (ie, interface), and having as few diffs against existing code as possible.
On the other hand, since a few of the old functions continue to exist, would please the original author of the md5.pas file stand up and give permission to have the "new" md5.pas, which comes without other GPL-licenced code, under the licence shown in the attached file?
If that's cleared up, I would like to have the md5.pas in the stock distribution replaced, and the md5c.c added. As for md5c.c - it depends on <sys/types.h> to exist (I think that's OK per ANSI/ISO C), and checks for a definition LITTLE_ENDIAN (if it's not defined, big endian is assumed) - that might be a portability problem to be solved. Since you are far better in gcc and non-BSD environments than myself, I'll leave that to you.
But please let's clear up the licence issues first. We need permission from the FSF (who got assigned copyright for the old md5.pas file) or the person who originally wrote all the other routines (starting at MD5Clear, continuing over MD5Compare, MD5Str etc.). By acknowledging this, GPC's runtime environment is fully suitable for being used to compile, link and redistribute any application, not just Free Software.
Thanks in advance, and in the hope to be helpful //Thorsten
Thorsten Glaser wrote:
Recently I've discovered Frank (IIRC) telling us that the MD5 unit is, in contrast to all other units (I just double-checked), not licenced under the GNU LGPL, or GPL with library exception clause, but rather plain GPL because it contains code from Ulrich Drepper's glibc imple- mentation of the MD5 algorithm.
I took the time and prepared a new, BSD-licenced, implementation of the code, while preserving the old framework (ie, interface), and having as few diffs against existing code as possible.
Unfortunately this seems to be the original BSD license with the "obnoxious advertising clause". I don't like it, and it isn't even GPL compatible.
On the other hand, since a few of the old functions continue to exist, would please the original author of the md5.pas file
That would be me (for the new routines, and for the, mostly trivial, Pascal translation of the C code).
As for md5c.c - it depends on <sys/types.h> to exist (I think that's OK per ANSI/ISO C), and checks for a definition LITTLE_ENDIAN (if it's not defined, big endian is assumed) - that might be a portability problem to be solved.
That's one reason why I ported it to Pascal where (in GPC, of course) such things (types of a given size and endianness conditionals such as `__BYTES_LITTLE_ENDIAN__') are readily available.
Since you are far better in gcc and non-BSD environments than myself, I'll leave that to you.
I personally don't have much interest to support non-free programs, so I'm not going to do a substantial amount of work here.
For these three reasons, if you want the license changed, I suggest you find someone (who hasn't studied either the libc or the RSA code closely; possibly yourself if you haven't) to write a new implementation and release it under the LGPL (or a "new BSD style" license), i.e. a "clean room implementation".
You/they can, and should, of course, compare the results of the current and new units, to verify that they match, but not copy any code, directly or "mentally".
For reference you can use RFC 1321 which contains a precise description of the algorithm, *without* looking at the "Reference Implementation" in appendix A which is just that code under the OBSD license.
For such a unit, I'll give permission to include my code from the interface (in fact, I'd ask for using the same interface for compatibility) and the implementation of my new routines `MD5File' .. `MD5Compose'.
(And, BTW, if you want it included in the GPC distribution, please note the GPC Coding Standards. If I'd have to reformat the code or do other significant work with it, I won't do it, see above. Also, please don't change `* $10' to `shl 4' etc., as you did. Write high-level code and leave the low-level optimizations to the compiler.)
Frank
Dixitur illum ih8mj@fjf.gnu.de scribere...
Unfortunately this seems to be the original BSD license with the "obnoxious advertising clause". I don't like it, and it isn't even GPL compatible.
No, it isn't - it says "must be identified as blahblah", not "if you advertise you must say blahblah".
Since these files come from the OpenBSD libc, and OpenBSD ships GNU GPL'd binaries, I'm _pretty_ sure of this.
For such a unit, I'll give permission to include my code from the interface (in fact, I'd ask for using the same interface for compatibility) and the implementation of my new routines `MD5File' .. `MD5Compose'.
That's nice to hear. Maybe if we get the RSA licence thing cleared up (I'll ask the OpenBSD developers about it if that's desired), you could reconsider the thing.
(And, BTW, if you want it included in the GPC distribution, please note the GPC Coding Standards. If I'd have to reformat the code or do other significant work with it, I won't do it, see above. Also,
For this reason, I didn't really change much of the remaining parts of the unit. I'll read the GPC Coding standards when I get back home.
please don't change `* $10' to `shl 4' etc., as you did. Write high-level code and leave the low-level optimizations to the compiler.)
Okay, I'll note that. (I prefer the reverse, but for the same reason, I think submitting code to someone should be in that person's coding style.)
bye, //Thorsten
Thorsten Glaser wrote:
Dixitur illum ih8mj@fjf.gnu.de scribere...
Unfortunately this seems to be the original BSD license with the "obnoxious advertising clause". I don't like it, and it isn't even GPL compatible.
No, it isn't - it says "must be identified as blahblah", not "if you advertise you must say blahblah".
It doesn't use the term "advertising", but it says:
: License is also granted to make and use derivative works provided : that such works are identified as "derived from the RSA Data : Security, Inc. MD5 Message-Digest Algorithm" in all material ^^^^^^^^^^^^^^^ : mentioning or referencing the derived work. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which seems even broader. It means concretely, among other situations, if I write a CGI program that uses this code and use it on a web site (which I do), I have to put this boilerplate on this web site (possibly even on each page that links to it, as in "referencing") which is where most users certainly care very little about it.
This may not be the intention of this license, but lacking a definitive (and liable) legal advice to the contrary, I assume this might be required.
Since these files come from the OpenBSD libc, and OpenBSD ships GNU GPL'd binaries, I'm _pretty_ sure of this.
The GPL contains a special exception for system libraries.
Frank
Dixitur illum ih8mj@fjf.gnu.de scribere...
: Security, Inc. MD5 Message-Digest Algorithm" in all material ^^^^^^^^^^^^^^^ : mentioning or referencing the derived work. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ ... explanation ... ]
definitive (and liable) legal advice to the contrary, I assume this might be required.
You're right.
Since these files come from the OpenBSD libc, and OpenBSD ships GNU GPL'd binaries, I'm _pretty_ sure of this.
The GPL contains a special exception for system libraries.
See what's these 18K licences are good for? :-) I've read the GPLv2 numerous times and still learn new things while working with you guys.
Well, the second try I sent in is RSA DSI free, so would you like to have a look at it?
bye, //Thorsten
Thorsten Glaser wrote:
Well, the second try I sent in is RSA DSI free, so would you like to have a look at it?
I suppose meanwhile you've seen my other mail about the LGPL glib code, so I think it's not necessary anymore. (And I have enough things to do, so I can't study it just out of curiosity.)
Frank
Frank Heckenbach wrote:
(And, BTW, if you want it included in the GPC distribution, please note the GPC Coding Standards. If I'd have to reformat the code or do other significant work with it, I won't do it, see above. Also, please don't change `* $10' to `shl 4' etc., as you did. Write high-level code and leave the low-level optimizations to the compiler.)
AFAIKS intended operation is a shift. So `shl 4' is a high-level specification and `* $10' buys nothing. I can understand that uglyfication to `* 16' gives more portable code, but the unit uses shifts anyway. <rant> I remenber a guy who wanted to use floating point in Linux kernel. He claimed that he have complicated formula very hard to do using integers. It turned out that the formula was turning on/off bits -- floting point was used to do that in BASIC </rant>
So I would say: write what you mean. If it is multiplication, use multiplication, if it is shift, use shift.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
(And, BTW, if you want it included in the GPC distribution, please note the GPC Coding Standards. If I'd have to reformat the code or do other significant work with it, I won't do it, see above. Also, please don't change `* $10' to `shl 4' etc., as you did. Write high-level code and leave the low-level optimizations to the compiler.)
AFAIKS intended operation is a shift. So `shl 4' is a high-level specification and `* $10' buys nothing. I can understand that uglyfication to `* 16' gives more portable code,
Well, since I wrote the code, I may say that my intention was a multiplication, not a shift. The code in question is essentially a base conversion. Integer bases are defined in terms of multiplications. In the case where the base is a power of two, it can be optimized to a shift, but since this optimization does not apply to other bases, multiplication is the more general, and therefore higher-level representation.
but the unit uses shifts anyway.
That doesn't mean anything. The fact that shifts are low-level here doesn't mean they're unappropriate everywhere. (Most obviously, they're useful with a variable right argument, but not only there.)
<rant> I remenber a guy who wanted to use floating point in Linux kernel. He claimed that he have complicated formula very hard to do using integers. It turned out that the formula was turning on/off bits -- floting point was used to do that in BASIC
</rant>
Nice story, even though completely unrelated. (This is about bits, and the natural operations on bits are `and', `or' etc. In our case, we're talking about integers and the natural operations for integers include `*' and `div' much more than they do `shl' and `shr'.)
So I would say: write what you mean. If it is multiplication, use multiplication, if it is shift, use shift.
That's what I did, thanks.
Frank
Waldek Hebisch wrote:
Frank Heckenbach wrote:
(And, BTW, if you want it included in the GPC distribution, please note the GPC Coding Standards. If I'd have to reformat the code or do other significant work with it, I won't do it, see above. Also, please don't change `* $10' to `shl 4' etc., as you did. Write high-level code and leave the low-level optimizations to the compiler.)
AFAIKS intended operation is a shift. So `shl 4' is a high-level specification and `* $10' buys nothing. I can understand that uglyfication to `* 16' gives more portable code, but the unit uses shifts anyway.
Except, if you look at ISO 10206, there is no mention of any operator 'shl'. I don't believe $10 is mentioned either. Which, to my mind, leaves '* 16'.
On Wed, Apr 21, 2004 at 02:30:18AM -0400, CBFalconer wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
(And, BTW, if you want it included in the GPC distribution, please note the GPC Coding Standards. If I'd have to reformat the code or do other significant work with it, I won't do it, see above. Also, please don't change `* $10' to `shl 4' etc., as you did. Write high-level code and leave the low-level optimizations to the compiler.)
AFAIKS intended operation is a shift. So `shl 4' is a high-level specification and `* $10' buys nothing. I can understand that uglyfication to `* 16' gives more portable code, but the unit uses shifts anyway.
Except, if you look at ISO 10206, there is no mention of any operator 'shl'. I don't believe $10 is mentioned either. Which, to my mind, leaves '* 16'.
The ISO 10206 equivalent of $10 is 16#10 (base#digits in general), which is a bit more typing, but IMHO it is much cleaner than the Borland syntax.
Emil
Dixitur illum ejer5183@artax.karlin.mff.cuni.cz scribere...
The ISO 10206 equivalent of $10 is 16#10 (base#digits in general), which is a bit more typing, but IMHO it is much cleaner than the Borland syntax.
It's also ksh syntax.
And I never liked C or TP hex syntax - rather, &h10 or 10h (yes, you guess right on the first one if it starts with gw and ends with ...ic.exe)
//Thorsten
Emil Jerabek wrote:
On Wed, Apr 21, 2004 at 02:30:18AM -0400, CBFalconer wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
(And, BTW, if you want it included in the GPC distribution, please note the GPC Coding Standards. If I'd have to reformat the code or do other significant work with it, I won't do it, see above. Also, please don't change `* $10' to `shl 4' etc., as you did. Write high-level code and leave the low-level optimizations to the compiler.)
AFAIKS intended operation is a shift. So `shl 4' is a high-level specification and `* $10' buys nothing. I can understand that uglyfication to `* 16' gives more portable code, but the unit uses shifts anyway.
Except, if you look at ISO 10206, there is no mention of any operator 'shl'. I don't believe $10 is mentioned either. Which, to my mind, leaves '* 16'.
The ISO 10206 equivalent of $10 is 16#10 (base#digits in general), which is a bit more typing, but IMHO it is much cleaner than the Borland syntax.
Note that I wasn't talking about standard compliance. The unit isn't anyway, because it uses shifts elsewhere (if that's what Waldek meant when pointing this out, that's true), and types of fixed size etc. (*)
I won't object if you replace `$' with `16#' (throughout). (IMHO, it's more general, but not necessarily cleaner (whatever this means) -- at least this BP syntax doesn't conflict with anything, such as the horrific BP `^A' char constants.)
(And while we're at it, I fail to see how `&h10' is preferable -- it introduces a new character just like `$', and it needs another letter. And I don't like suffix specifiers as in `10h' because they make it more difficult to parse the number, both for computers and humans, when reading left to right.)
(*) For a theoretical exercise on whether it's possible to implement MD5 in Classic/Extended Pascal (CP and EP for short):
- Shifts (with variable right argument) are difficult in CP, though possible with a loop or so, but inefficient. In EP you could use `* 2 pow n' etc. which could be as efficient as a shift with a compiler that optimizes this construct better than GPC currently does.
- The macros can, of course, be expanded, leaving the code just a bit longer and perhaps less readable.
- There are no types with fixed sizes. Of course, if you reduce anything to standard operations, it doesn't hurt if the type is bigger than you need. But you need to ensure that `Integer' has at least 32 bits. The standard doesn't guarantee this, but at least allows you verify whether it does (which should fail if MaxInt is smaller):
type Dummy = 2147483647 .. MaxInt;
(Well, actually MD5 uses unsigned types, so we'd need MaxInt >= 2^32 - 1. I didn't check if it could be done with signed type -2^31 .. 2^31 - 1, but since the standards prescribe a symmetrical integer range, we'd require MaxInt >= 2^31. This means, in both cases GPC would fail this check on 32 bit platforms.)
- But the main problem is how to access the buffer (a block of bytes). Of course, you could declare it, say, as a conformant array of `Byte' (assuming that `Byte' has a suitable declaration). This way you might be able to write MD5 in standard Pascal, but in fact you just shift the problem to the user (who, in standard Pascal, could not even declare `Byte' suitably, since `0 .. 255' is not guaranteed to occupy one byte -- nothing of this sort is guaranteed by the standards, of course).
Frank
Dixitur illum ih8mj@fjf.gnu.de scribere...
(And while we're at it, I fail to see how `&h10' is preferable -- it introduces a new character just like `$', and it needs another letter. And I don't like suffix specifiers as in `10h' because they make it more difficult to parse the number, both for computers and humans, when reading left to right.)
That's just kidding; &h10 is BASIC and 10h is (common x86) assembly. Sorry for the confusion I caused.
bye, //Thorsten
Thorsten Glaser wrote:
Dixitur illum ih8mj@fjf.gnu.de scribere...
(And while we're at it, I fail to see how `&h10' is preferable -- it introduces a new character just like `$', and it needs another letter. And I don't like suffix specifiers as in `10h' because they make it more difficult to parse the number, both for computers and humans, when reading left to right.)
That's just kidding; &h10 is BASIC
Not the BASIC versions I've used. But I guess any language feature one can imagine is part of *some* BASIC dialect. (Yeah, from time to time it's good to point at those who are even worse off with their dialects than Pascal is ... ;-)
BTW, who put the `[SPAM]' in the subject? I actually don't like to write spam ...
Frank
On Thu, Apr 22, 2004 at 04:29:06AM +0200, Frank Heckenbach wrote:
Thorsten Glaser wrote:
Dixitur illum ih8mj@fjf.gnu.de scribere...
(And while we're at it, I fail to see how `&h10' is preferable -- it introduces a new character just like `$', and it needs another letter. And I don't like suffix specifiers as in `10h' because they make it more difficult to parse the number, both for computers and humans, when reading left to right.)
That's just kidding; &h10 is BASIC
Not the BASIC versions I've used. But I guess any language feature one can imagine is part of *some* BASIC dialect. (Yeah, from time to time it's good to point at those who are even worse off with their dialects than Pascal is ... ;-)
BTW, who put the `[SPAM]' in the subject? I actually don't like to write spam ...
I'm sorry, it was inserted to the subject of Chuck's post I was replying to by spamassassin on our mail server (we've discussed the problem recently; BTW I tried to whitelist gnu.de, but it apparently didn't work).
Emil
Emil Jerabek wrote:
BTW, who put the `[SPAM]' in the subject? I actually don't like to write spam ...
I'm sorry, it was inserted to the subject of Chuck's post I was replying to by spamassassin on our mail server (we've discussed the problem recently; BTW I tried to whitelist gnu.de, but it apparently didn't work).
If it works on `From:' rather than `Sender:', you'd have to check for `cbfalconer@yahoo.com'. If it works on domains only, there might be a problem ...
Frank
On Thu, Apr 22, 2004 at 06:53:23PM +0200, Frank Heckenbach wrote:
Emil Jerabek wrote:
BTW, who put the `[SPAM]' in the subject? I actually don't like to write spam ...
I'm sorry, it was inserted to the subject of Chuck's post I was replying to by spamassassin on our mail server (we've discussed the problem recently; BTW I tried to whitelist gnu.de, but it apparently didn't work).
If it works on `From:' rather than `Sender:', you'd have to check for `cbfalconer@yahoo.com'. If it works on domains only, there might be a problem ...
There are separate checks on `To:' (which is what I did) and `From:' (I'll try it now).
Emil
Dixitur illum ih8mj@fjf.gnu.de scribere...
For such a unit, I'll give permission to include my code from the interface (in fact, I'd ask for using the same interface for compatibility) and the implementation of my new routines `MD5File' .. `MD5Compose'.
(And, BTW, if you want it included in the GPC distribution, please note the GPC Coding Standards. If I'd have to reformat the code or do other significant work with it, I won't do it, see above. Also, please don't change `* $10' to `shl 4' etc., as you did. Write high-level code and leave the low-level optimizations to the compiler.)
Okay, this is now a second try:
- the md5c.c file is public domain, rewritten by the guys at fourmilab.ch (thanks Todd Miller @openbsd for the hint) - the md5.pas file has as few differences as possible to your code, so (I hope) coding styles are not an issue. (I'll read the standards anyways) - endianness isn't an issue either - if BYTE_ORDER or LITTLE_ENDIAN are not defined, it might still work (unless the preprocessor doesn't play with us), it's just (a bit) slower on i386 then.
I pledge for this being included into GPC.
cu, //Thorsten
Thorsten Glaser wrote:
Okay, this is now a second try:
- the md5c.c file is public domain, rewritten by the guys at fourmilab.ch (thanks Todd Miller @openbsd for the hint)
- endianness isn't an issue either - if BYTE_ORDER or LITTLE_ENDIAN are not defined, it might still work (unless the preprocessor doesn't play with us), it's just (a bit) slower on i386 then.
Seems like a step back to me.
But when I did some research, I found that I had taken the code from gnulib which is released under GPL, but the same code (I compared it) is released under the LGPL in glibc. (Actually, I wasn't aware of the difference until now. It is a bit confusing: There are (at least) four libraries (gnulibc, glibc, gnulib, glib) with similar names and (partly very much) different contents and (partly) different licenses.)
So I now take the LGPL code from glibc, add my changes under LGPL too, and release the combined unit (which is identical to the previous one except for the license statement) under the LGPL.
Frank
-
CBFalconer -
Emil Jerabek -
Frank Heckenbach -
Thorsten Glaser -
Waldek Hebisch