>> Based on my reading of the license terms, the MD5 code in libc is
>> sufficiently encumbered that anyone who has ever used it even once
>> is required, whenever mentioning it in any context, to note that it
>> is "derived from the RSA Data Security, Inc. MD5 Message-Digest
>> Algorithm".
> You can reference the algorithm without referencing the actual
> implementation of that algorithm.

True - but, as far as I can tell, irrelevant.  If I have used the
implementation in libc, which is derived from the RSADSI one, I am
compelled, whenever referring to that implementation, to recite the
attribution I quoted above.  --As I read the license, that is.

> Read the license carefully...  It does not require that software
> which uses it be identified in such a manner,

Semi-true as far as it goes, but to the extent that it is true I think
it is irrelevant to my point.

$NetBSD: md5.copyright,v 1.1 1997/01/30 01:01:41 thorpej Exp $ in
/usr/src/lib/libc/md says, in part,

[begin quote]
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.
[end quote]

$NetBSD: md5c.c,v 1.3 1998/03/26 23:53:36 cgd Exp $ in that same
directory contains similar language (it appears identical in a casual
visual comparison I just did).

These do not require attribution attached to software, only to
references to it and mention of it.  Whenever I produce "material
mentioning or referencing" that "derived work" (eg, this message), I
have to recite that attribution I quoted...since I have used said
derivative work (by accidentally running an md5 implementation that was
linked with that md5 code).

Such is my opinion.  Yours seems to be otherwise.  Tell me, do you
believe the libc MD5 code is not a "derivative work" in the sense of
the above license clause?  Or do you believe that messages such as the
ones in question are not "material mentioning or referencing" it?  Or
do you think that people who have used the relevant code are
nevertheless not bound to obey the license terms?  Or do you think that
despite all those, such messages are not required to include that
attribution?  I can't see any justification for any of those and would
love to know where you find some, 'cause I really hate having to trot
out that phrase.  (If RSADSI wants me to advertise them, they can damn
well pay me to!)

>> According to my reading of the license.  That's why I'd like to hear
>> a real legal opinion on the matter...which is where I came in.
> So why didn't you actually get a legal opinion before flaming on this
> list ...

Because I'm not the one who's tasked with the duty of ensuring that
only appropriate licenses go into the tree (except (to an unclear-to-me
extent) in things I commit, which most certainly doesn't include the
relevant code).  Because I'm not about to spend *my* money to fix (what
I see as) someone else's mistake - especially since I offered another,
easier, cheaper fix: a public-domain reimplementation.

If it comes down to a choice of (1) dropping NetBSD, (2) routinely
ignoring that license clause, or (3) routinely reciting that
attribution...well, I'd hope I'd have the strength to do (1).  (3),
however, is completely out of the question.  But as I read the license,
my only other choices are (4) never use such a derivative work (I've
already blown this one) and (5) never "mention[] or referenc[e]" said
derivative work.

Actually, in practice I'd probably attempt (5), and fall back to (3) on
those (hopefully rare) occasions when (5) is impractical.  (Though I
suspect merely even doing (3) would be seen as "flaming" if seen by you
or someone who thinks as you do on this issue.)

> ... for no particularly good reason?

Perhaps it was "no particularly good reason".  Perhaps many/most NetBSD
users don't care about licenses and are quite content to routinely
violate them.  Perhaps I've misread something and there's no violation
involved, though as I indicated above it sure doesn't look like it to
me.  But when I see something that looks like a timebomb waiting to
explode in the form of a lawsuit against some innocent NetBSD user
whose only (moral) offense has been to trust the Project to not inflict
unreasonable license terms, I see getting it fixed, or at least
alerting the potentially-affected users, as not only a reasonable thing
to do but as a _duty_.

Ideally, I should merely need to alert core, who would then either fix
the problem or explain why it's not a problem.  Unfortunately, NetBSD
core has a long history of (a) being extremely uncommunicative [%] and
(b) taking a very long time to resolve almost anything, which makes it
impossible to tell whether anyone's even seen the putative note, much
less whether and how it might be fixed.  And that leaves?  Right.
Alerting the users.

[%] I've seen signs that this may be changing.  Even if it is somehow
cured overnight, there will be an awful lot of history to overcome.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B