Re: So PGP2.5 is becoming clearing...

[dat@spock.ebt.com (David Taffs)]

   From: Richard Johnson <Richard.Johnson@Colorado.EDU>

   "Performance improvement" purposes can obviously include allowing more
   secure performance via longer (2048 bits anyone?) keys.

I would agree with this. Performance improvement doesn't just mean speed.

   The key here is "incorporated".  Since RSAREF is designed as a C
   library, the only way to "incorporate" it is to call its functions from
   a program.  Thus, if you don't call specific RSAREF functions, you're
   not "incorporating" RSAREF.  "Incorporation" of RSAREF is thus not
   transitive.

I would be careful here. Another conceivable definition of
"incorporate" is "to link with". Perhaps it might mean to statically
link with, or dynamically link with. This definition would be
transitive, but could still be circumvented.

I have seen examples of commercial products interfacing to various GNU-ware,
protected by copyleft. I forget the exact details, but there was at least
a layer of free-ware provided in between that accessed the GNU-ware via a
shell interface. I will look up the exact details and post them if I can.
Calling an RSAREF shell program would not be incorporating it, IMHO.

It seems to me that if you provide a free shell-accessible program
that invoked whatever free-ware you want to write around RSAREF, and
you invoked that shell program from inside another program that was a
commercial product, that you would be protected. It is of course possible
that closer binding would also provide adequate protection; this is just
one way that I believe would be adequate. It restricts the interface to
a relatively low-bandwidth, potentially inefficient interface, but this
seems to be their goal, and it also seems adequate for e-mail purposes.
(The RSAREF could be in a background server process, always running,
providing enhanced efficiency, if desired.)

Of course, I am not a lawyer either, although I have watched an awful
lot of Judge Wapner. Get your own legal opinion if you really care.

   ...

   Richard

-- 
dat@ebt.com (David Taffs)