NODE f7b7170bSo PGP2.5 is becoming clearing...
lile@netcom.com (Lile Elam)Tue, 17 May 94 18:18:03 PDT
Have you seen this? If you would rather that I not send
such things to this list, I can do that.
let me know,
-lile
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lile Elam | "Remember... No matter where you go, there you are."
lile@netcom.com |
Un*x Admin / Artist | Buckaroo Banzai
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NODE 52025251Re: So PGP2.5 is becoming clearing...
jamesd@netcom.com (James A. Donald)Tue, 17 May 94 18:47:56 PDT
Lile Elam posted the RSA licensing agreement. He thought it
was bad. I think it is great. Maybe I do not understand it.
If I understand it correctly it gives us the right to fix PGP
2.6 if it is broken.
You cannot use it in commercial software directly, but you can
write freeware that has hooks in so the freeware can be used
by another program or by a human, and then write commercial
software that uses those hooks.
For example I could write a freeware account management
program that generates digitally signed IOUs, and a
commercial program that uses the freeware program.
Am I missing something? This sounds like the war is over
and we won!
NODE feaea3a3Re: So PGP2.5 is becoming clearing...
jkreznar@ininx.com (John E. Kreznar)Wed, 18 May 94 03:44:08 PDT
-----BEGIN PGP SIGNED MESSAGE-----
> Lile Elam posted the RSA licensing agreement. He thought it
> was bad. I think it is great. Maybe I do not understand it.
> Am I missing something? This sounds like the war is over
> and we won!
You would have to consent to be a national person (United States of
America or Canada) in order to have it. You wouldn't want to give up
your freeman status to do that, would you?
John E. Kreznar | Relations among people to be by
jkreznar@ininx.com | mutual consent, or not at all.
-----BEGIN PGP SIGNATURE-----
Version: 2.3a
iQCVAgUBLdnwysDhz44ugybJAQHZfQQA0gLlkVbTOG72NR2FyFoKOzFSIPv/AG9k
+BoPCZjMqbDexVvWnftlUXizEVoUsM7qJHCN3oOurzntsJvRy0WVVd7HmomkV57l
8JC7yFBUI9Ogw/txa/I9+sVWymcKfTC6s7exIO7NDCX7pWu+nLuKDS+xZ4xfgaSN
MVdryFgx3Ww=
=XQNM
-----END PGP SIGNATURE-----
NODE 569246a0Re: So PGP2.5 is becoming clearing...
"Perry E. Metzger" <perry@imsi.com>Wed, 18 May 94 08:33:34 PDT
John E. Kreznar says:
> You would have to consent to be a national person (United States of
> America or Canada) in order to have it. You wouldn't want to give up
> your freeman status to do that, would you?
Given that to my knowledge no court, federal official, or other
organization that counts recognises "freeman status" to my knowledge,
it would seem to be a very small loss.
.pm
NODE 79e801c7So PGP2.5 is becoming clearing...
jkreznar@ininx.com (John E. Kreznar)Wed, 18 May 94 15:08:05 PDT
-----BEGIN PGP SIGNED MESSAGE-----
Perry E. Metzger writes:
> John E. Kreznar says:
> > You would have to consent to be a national person (United States of
> > America or Canada) in order to have it. You wouldn't want to give up
> > your freeman status to do that, would you?
> Given that to my knowledge no court, federal official, or other
> organization that counts recognises "freeman status" to my knowledge,
> it would seem to be a very small loss.
What they certainly _do_ recognize, however, is that a person who _does_
agree to the PGP 2.5 terms has affirmed that he _is_ a national person.
This could be used by a court to negate any subsequent denial by the
person that he is a subject of the United States of America or Canada.
The absence on one's record of such affirmations is a prerequisite for
freeman status.
John E. Kreznar | Relations among people to be by
jkreznar@ininx.com | mutual consent, or not at all.
-----BEGIN PGP SIGNATURE-----
Version: 2.3a
iQCVAgUBLdqRM8Dhz44ugybJAQFeKAP9EQPF8HucD5DUZ7x+ujnWxC4Td5uW/Wzy
6tQybwcBAwJuCenqWHDHdx5awGkANo9HTx63cD41rAls1rsXIyDRF2h2fTa1sLkM
d6Soww9JG4PUAHGLFJvu1SCt13nBzotGrEpOp16c0y9QeW9yQ+QCFSnFq2bw75F4
zi1yarlYyQo=
=Da9O
-----END PGP SIGNATURE-----
NODE 4b6dd8b5Re: So PGP2.5 is becoming clearing...
Richard Johnson <Richard.Johnson@Colorado.EDU>Tue, 17 May 94 19:51:45 PDT
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
NODE 8919068eRe: So PGP2.5 is becoming clearing...
dat@spock.ebt.com (David Taffs)Wed, 18 May 94 11:28:34 PDT
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)