> >>> "Jason Dufair" 05/20/04 05:33 >>>
>
> Well, to borrow an idiom, I think I'm going to take a run at
> the OpenSSL plugin fence.

Yay!

> It seems that compiling OpenSSL as part of compiling the Squeak VM or
> even just the OpenSSL plugin is going to be no small effort.
> I'm having
> a hell of a time just compiling it alone with the mingw toolset on my
> Win32 box.  My current thought is to build a plugin that links to an
> already built OpenSSL dll/so.  Is this reasonable?  Is this Squeak-y
> enough?  Is anyone aware of any licensing issues if I were to
> distribute
> my plugin this way?

IANAL and I'm certainly no Squeak guru, but I'd rather have a plugin that
connects to an already-built OpenSSL dll/so than dragging source around. Not
that I ever build stuff on my Windows box at work anyway. Doing things this
way would mean that I can just have my FreeBSD box upgrade OpenSSL when the
next advisory comes out and not have the squeak port get rebuilt.

Both of OpenSSL's licences are BSD-style licences. I think that just linking
to an external library doesn't constitute a derived product? (Clause 5 of
the OpenSSL licence says

   * 5. Products derived from this software may not be called "OpenSSL"
   *    nor may "OpenSSL" appear in their names without prior written
   *    permission of the OpenSSL Project.

The SSLEay licence just says that

   * 3. All advertising materials mentioning features or use of this
software
   *    must display the following acknowledgement:
   *    "This product includes cryptographic software written by
   *     Eric Young (eay at cryptsoft.com)"
   *    The word 'cryptographic' can be left out if the rouines from the
library
   *    being used are not cryptographic related :-).
   * 4. If you include any Windows specific code (or a derivative thereof)
from
   *    the apps directory (application code) you must include an
acknowledgement:
   *    "This product includes software written by Tim Hudson
(tjh at cryptsoft.com)"

which doesn't sound particularly onerous :)

frank