From: Richard Johnson <Richard.Johnson@Colorado.EDU>
Date: Tue, 17 May 94 19:51:45 PDT
To: cypherpunks@toad.com
Subject: Re: So PGP2.5 is becoming clearing...
In-Reply-To: <199405180117.SAA05395@netcom.com>
Message-ID: <199405180251.UAA12436@spot.Colorado.EDU>
MIME-Version: 1.0
Content-Type: text/plain


Lile Elam <lile@netcom.com> graciously forwarded some comments about
the March 16 RSAREF license to us.

...[Mucho FUD (maybe warranted) about the RSAREF license excised.]

Overall, the license is OK, if a bit stupid in places.  Rather than deal
with supposition, let's get right to specifics in the license itself.

Note that I'm not a lawyer, though my Mom wanted me to be one.  Anything
that looks like legal advice in the following is just mere uninformed
supposition on my part.

---------

> RSA LABORATORIES PROGRAM LICENSE AGREEMENT Version 2.0 March 16, 1994

>  1.   c.   to modify the Program in any manner for porting or
>            performance improvement purposes (subject to Section 2)
>            or to incorporate the Program into other computer programs 
>            for your own personal or internal use, provided that you 
>            provide RSA with a copy of any such modification or 
>            Application Program by electronic mail, and grant RSA a
>            perpetual, royalty-free license to use and distribute such
>            modifications and Application Programs on the terms set
>            forth in this Agreement.

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

Note that the license suddenly starts referring to "Application Program"
in 1.c.  The implicitly explict ;-) definition of "Application Program"
is "other computer programs for your own personal or internal use" into
which the RSAREF Program is "incorporated".  The license later defines
this term explicitly, in line with the implicit use above.

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.

Only "Application Program"s that "incorporate" RSAREF must be given to
RSA.  According to these definitions, PGP (which incorporates RSAREF)
must be given to RSA.  A mail user agent that uses PGP, however, does
not "incorporate" RSAREF.  Likewise, neither does an OS that allows the
mail user agent to employ PGP.  PGP is the only program that
"incorporates" RSAREF here.  RSA is thus not asking for sources to the
entire OS.

       d.   to copy and distribute the Program and Application Programs
            in accordance with the limitations set forth in Section 2.

We can thus freely copy and distribute RSAREF and whatever we build 
that "incorporates" it.  The section 2. restrictions: require us to
distribute source along with any executables we produce (like the
original FSF license did), require us to include the RSAREF
license (similar to FSF copyleft), and require us to get "written"
assurance from recipients that they will not use it for revenue
generation (onerous and weird, but doable).

One point about this really bugs me, though.  We cannot generate
"income" from distribution of RSAREF-incorporating application
programs.  Normally, I would not include recovering costs for
distribution media/time/bandwidth and shipping/handling as "income".
However, they make no explicit acknowledgement of this.  If you
do charge for BBS memberships, on-line accounts, or disks at your
user group meeting, you should probably make it explicitly clear
that you are not charging for specific programs, but for the media
no matter what the user is going to do with it.

In simple terms, RSA wants a cut if you make money (or try to) using
their RSAREF mess.  If you want to do that, the best approach would be
to skip RSAREF and license the use of a more capable and extensible
library from RSA.


Richard