zmtx/zmrx, zmodem implementation build from scratch

158 views
Skip to first unread message

Chuck Forsberg WA7KGX

unread,
Jul 20, 1994, 4:55:42 PM7/20/94
to
In article <30clkg$o...@news4all.hacktic.nl> pa...@hacktic.nl (Paul Jongsma) writes:
> This archive contains a implementation of Zmodem which is not based on
> existing sources but is developed from scratch. Consult the readme and

About the only thing is this package that are created from
scratch are the "new" authors' copyright notices which were
illegally substituted for the Omen Technology Copyright notice
on rz/sz 2.24 from which it was originally copied. To dispel
any doubt about copying and copyright infringement, note the
following juxtaposition of zmodem.h from rz/sz 3.24 and the
zmodem.h which Jongsma claims was written from scratch.

If this "zm" package is not a violation of copyright law then
neither the GNU Copyleft nor Columbia University's Kermit
copyrights have any protection of law.


/*
* Z M O D E M . H Manifest constants for ZMODEM
* application to application file transfer protocol
* Copyright 1993 Omen Technology Inc All Rights Reserved
*/
/*
* zmodem.h
* zmodem constants
* (C) Mattheij Computer Service 1994
*/


#define ZMAXHLEN 16 /* Max header information length NEVER CHANGE */
#define ZMAXHLEN 0x10 /* maximum header information length */

#define ZMAXSPLEN 1024 /* Max subpacket length NEVER CHANGE */
#define ZMAXSPLEN 0x400 /* maximum subpacket length */

#define CANVHDR 01 /* Variable headers OK */
#define ZF1_CANVHDR 0x01 /* Variable headers OK */

#define ZMCHNG 8 /* Change filename if destination exists */
#define ZF1_ZMCHNG 8 /* Change filename if destination exists */

--
Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, GSZ and DSZ
Omen Technology Inc "The High Reliability Software"
TeleGodzilla BBS: 503-621-3746 FAX:-3735 CIS:70007,2304

Kent Williams

unread,
Jul 20, 1994, 5:27:42 PM7/20/94
to
From article <1994Jul20....@omen.UUCP>,
by c...@omen.UUCP (Chuck Forsberg WA7KGX):

> In article <30clkg$o...@news4all.hacktic.nl> pa...@hacktic.nl
(Paul Jongsma) writes:
>> This archive contains a implementation of Zmodem which is not based on
>> existing sources but is developed from scratch. Consult the readme and
>
> About the only thing is this package that are created from
> scratch are the "new" authors' copyright notices which were
> illegally substituted for the Omen Technology Copyright notice
> on rz/sz 2.24 from which it was originally copied. To dispel
> any doubt about copying and copyright infringement, note the
> following juxtaposition of zmodem.h from rz/sz 3.24 and the
> zmodem.h which Jongsma claims was written from scratch.
>

There is actually a lot of code that is different between rz/sz and
zmtx and zmrx; this is evident from the fact that rz/sz work really
well, and zmtx and zmrx don't work at all, at least when I tried them
on AIX.

It should be noted that zmodem was developed by Mr. Forsberg, and the
sale of his implementation of the protocol is a primary source of his
income. He is not Bill Gates -- if you call Omen Technologies, you
will either get him or his wife. Considering the daily, constant,
commercial use of his products, it would behoove companies in the
internet community to shell out a few bucks to him for his efforts.

I am a satisfied customer of Mr. Forsberg (for over 10 years!), and have
no other connection to him.

Kent Williams -- ke...@cadsi.com | Opinions expressed here are those of |
"A man who has nothing in | a two headed peg-legged midget who |
particular to recommend him | lives in my ear, not CADSI's |
discusses all sorts of subjects at +--------------------------------------+
random as though he knew everything." - One of Sei Shonagon's Hateful Things

Paul A Vixie

unread,
Jul 20, 1994, 10:53:30 AM7/20/94
to
Is zmodem.h the only file you're concerned about? If that't the only file
that contains text or algorythms similar to your own previous (copyrighted,
shareware) rz/sz, I'm sure the "zm" authors will change it for you. I can't
see a lot of similarity in any other file. Can you?

Interesting selection of newsgroups. I'm sure the kermit people are going
to be fascinated by this zmodem debate. But just in case they aren't, I'm
specifying a Followup-To on this article which removes the kermit group.

(Btw, when I get the automatic reminders that I'm posting nonsource to the
alt.sources group, I'm going to flame the sender, his postmaster, his mother,
his internet access provider, and then the sender again just for measure.)
--
Paul Vixie
Redwood City, CA
decwrl!vixie!paul
<pa...@vix.com>

R. Stewart Ellis

unread,
Jul 20, 1994, 8:25:44 PM7/20/94
to


Amen! Spam the net nazis!

RE the header file, what about getting it from a very early release of rzsz?


--
R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765 ___________________
Humanities & Social Science, GMI Eng.& Mgmt. Inst. / _____ ______
Flint, MI 48504 el...@nova.gmi.edu / / / / / /
Gopher,chimera,nn,tin,jove,modems, free code is best!/________/ / / / /

Peter da Silva

unread,
Jul 20, 1994, 8:49:55 PM7/20/94
to
It sure looks like zm is based directly on Omen Technologies source, and
unlike the BSDI/UCB/USL case it looks like a deliberate attempt to disguise
a violation of copyright, at least in the case of the zmodem.h file, rather
than accidental release of a handful of files as in the Net/2 distribution.

I have some problems with Omen Technology's creative redefinition of "non-
commercial use" in their shareware version of the zmodem host-side programs,
but the actual terms of that license are legal and supportable. I'm going
to delete my copy of zm as soon as I get home.

Clarence Wilkerson

unread,
Jul 20, 1994, 9:15:16 PM7/20/94
to
Here's an item from comp.os.linux.announce that I found
strange... the idea that a non author could take public
domain work by someone else and laundry it to be under
a GPL license. Note that here there is no claim of
intellectual effort involved in a rewrite. It's a
repackinging.


Article: 2503 of comp.os.linux.announce
From: mpo...@magnus.acs.ohio-state.edu (Matthew D Porter)
Newsgroups: comp.os.linux.announce
Subject: lrzsz 0.10
Followup-To: comp.os.linux.misc
Date: 17 Jul 1994 21:59:41 GMT
Organization: The Ohio State University
Lines: 34
Approved: linux-a...@tc.cornell.edu (Lars Wirzenius)
Message-ID: <30c9kd$d...@hydra.Helsinki.FI>
NNTP-Posting-Host: hydra.helsinki.fi
Keywords: rzsz, Zmodem, file transfer protocol

I've uploaded lrzsz 0.10 to sunsite as lrzsz-0.10.tar.gz. It is currently in
/pub/Linux/Incoming, but will probably settle in /pub/Linux/apps/comm in the
near future. lrzsz is a cosmetically changed rzsz based on the last public
domain version so there should be no distribution problems with it.

The README from lrzsz follows:
------------------------------

Lrz/Lsz is a cosmetically modified zmodem/ymodem/xmodem package built from the
public-domain version of Chuck Forsberg's rzsz package. This package contains
NO code from later releases of rzsz which would preclude it from being released
under the GPL.

Lrz/Lsz was created to provide a working GNU copylefted zmodem solution for
the Debian GNU/Linux distribution although it will work for any Linux
system.

Please note that credit should be given to Chuck Forsberg (rzsz) and Stephen
Satchell/Satchell Evaluations (crc routines) for this package, any
modifications by myself were minor and merely introduced to better mesh rzsz
with the standard Linux communications programs.

lrzsz 0.10 4-15-94
Matt Porter
por...@osu.edu

--
Matt Porter "The only thing necessary for the triumph of evil is
por...@osu.edu for good men to do nothing." --Edmund Burke
finger mpo...@magnus.acs.ohio-state.edu for PGP Public Key

--
Mail submissions for comp.os.linux.announce to: linux-a...@tc.cornell.edu
PLEASE remember Keywords: and a short description of the software.


Chuck Forsberg WA7KGX

unread,
Jul 21, 1994, 12:43:38 AM7/21/94
to

I don't see any problem with this lrz/lsz package based on the
public domain rz/sz code. I presume "cosmetically changed"
means the user interface has been modified to better suit his
tastes. As far as I know he has the right to add value to the
PD rz/sz and do with the result what he wishes. He does not
appear to be misrepresenting the derivation of the work.

Gene Kim

unread,
Jul 21, 1994, 2:32:51 AM7/21/94
to
In article <30kgnj$c...@starbase.neosoft.com>,

Peter da Silva <pe...@Starbase.NeoSoft.COM> wrote:
>It sure looks like zm is based directly on Omen Technologies source, and
>unlike the BSDI/UCB/USL case it looks like a deliberate attempt to disguise
>a violation of copyright, at least in the case of the zmodem.h file, rather
>than accidental release of a handful of files as in the Net/2 distribution.

Could you elaborate about what you find objectionable? Were the
zm authors to simply replace their zmodem.h file with one from an old
rzsz package, would your qualms about copyright violations go away?

Although copyrights apply to text matter, which includes header
files and code alike, I find nothing blatantly objectionable or
deceiving about lifting and renaming a bunch of defines. After all,
they are just Zmodem opcodes -- there are only so many ways you can
describe them while still retaining their meaning.

PS: I have nothing against Chuck. I remember reading his
postings with some awe on the Exec-PC BBS back in 1984. But I still
believe writing free, unencumbered software is good karma. :-)

Gene

---
Gene Kim (gk...@cs.arizona.edu)
University of Arizona, Gould Simpson Bldg, Rm 710, Tucson, AZ 85721
Home: 602-881-6642, Office: 602-621-4215
--
Gene Kim (gk...@cs.arizona.edu)
University of Arizona, Gould Simpson Bldg, Rm 710, Tucson, AZ 85721
Home: 602-881-6642, Office: 602-621-4215

Bill Pemberton

unread,
Jul 21, 1994, 9:57:10 AM7/21/94
to
In article <30k4se$3...@nexus.uiowa.edu>,

Kent Williams <will...@herky.cs.uiowa.edu> wrote:
>
>There is actually a lot of code that is different between rz/sz and
>zmtx and zmrx; this is evident from the fact that rz/sz work really
>well, and zmtx and zmrx don't work at all, at least when I tried them
>on AIX.
>

zmtx and zmrx work fine under AIX for me. The zmrx program does have a
problem with one of the PC comm packages that I use, but it is an oddball
package.


--
Bill

Peter da Silva

unread,
Jul 21, 1994, 2:28:11 PM7/21/94
to
In article <30l4qj$l...@chuckwalla.cs.arizona.edu>,

Gene Kim <gk...@CS.Arizona.EDU> wrote:
> Could you elaborate about what you find objectionable? Were the
> zm authors to simply replace their zmodem.h file with one from an old
> rzsz package, would your qualms about copyright violations go away?

No.

They have established a reasonable suspicion that the whole package is
copied, by using a clumsily disguised zmodem.h file. What else have they
"borrowed"?
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"

Andrew Valencia

unread,
Jul 21, 1994, 3:17:52 PM7/21/94
to
In <id.FDF...@nmti.com> pe...@nmti.com (Peter da Silva) writes:

>They have established a reasonable suspicion that the whole package is
>copied, by using a clumsily disguised zmodem.h file. What else have they
>"borrowed"?

Yes, but I went wading through the source hoping to find any other sign of
copying, and failed. If any of the C source had been duplicated as
clumsily, I would've expected to have found it. Instead, the structure, way
of handling cancels, timeouts, etc. all look substantially different.

Has anybody found other footprints of this alleged copying in the actual
data structures and algorithms of this implementation?

Andy

Erick Herring

unread,
Jul 21, 1994, 3:17:28 PM7/21/94
to
Vix is: vi...@vix.com (Paul A Vixie)

>> Is zmodem.h the only file you're concerned about? If that't the
>> only file that contains text or algorythms similar to your own
>> previous (copyrighted, shareware) rz/sz, I'm sure the "zm" authors
>> will change it for you. I can't see a lot of similarity in any
>> other file. Can you?

As a point of precedence, there is no firm legal decision as to the
copyright protections afforded to interface descriptions such as
header files.


Regards,
Erick
-----
Erick Herring | Computation is the art of carefully throwing
H Data, Aalborg | away information [and] Life is the art of
UNIX Consulting | carefully throwing away opportunities, an
SysAdmin & Programming | interesting coincidental parallel.
her...@iesd.auc.dk | - Guy L. Steele Jr.

Leslie Mikesell

unread,
Jul 21, 1994, 4:44:28 PM7/21/94
to
In article <30kgnj$c...@starbase.neosoft.com>,
Peter da Silva <pe...@Starbase.NeoSoft.COM> wrote:

>I have some problems with Omen Technology's creative redefinition of "non-
>commercial use" in their shareware version of the zmodem host-side programs,
>but the actual terms of that license are legal and supportable.

The terms may be legal, but I don't see how anyone can support them at a
dialup site since they demand that you know what is running on the other end of
the line. One machine here has close to 1000 entries in /etc/passwd.
Rather than calling everyone up and asking if they happen to use an Omen
product, I think I'll keep running the old klunky version.

Les Mikesell
l...@mcs.com

Mike McCarty

unread,
Jul 21, 1994, 9:12:44 PM7/21/94
to
In article <1994Jul21.0...@omen.uucp>,
Chuck Forsberg WA7KGX <c...@omen.UUCP> wrote:

[stuff deleted]

)>Lrz/Lsz is a cosmetically modified zmodem/ymodem/xmodem package built from the
)>public-domain version of Chuck Forsberg's rzsz package. This package contains
)>NO code from later releases of rzsz which would preclude it from being released
)>under the GPL.
)>
)>Lrz/Lsz was created to provide a working GNU copylefted zmodem solution for
)>the Debian GNU/Linux distribution although it will work for any Linux
)>system.
)>
)>Please note that credit should be given to Chuck Forsberg (rzsz) and Stephen
)>Satchell/Satchell Evaluations (crc routines) for this package, any
)>modifications by myself were minor and merely introduced to better mesh rzsz
)>with the standard Linux communications programs.
)>

[stuff deleted]

)I don't see any problem with this lrz/lsz package based on the
)public domain rz/sz code. I presume "cosmetically changed"
)means the user interface has been modified to better suit his
)tastes. As far as I know he has the right to add value to the
)PD rz/sz and do with the result what he wishes. He does not
)appear to be misrepresenting the derivation of the work.

Hmmm. When a copyright or patent is put in the public domain, that does
not mean that there is no copyright or patent. It means that the public
owns the copyright or patent. It does EMPHATICALLY NOT mean that a
person can do what he wants to do with the material in the public
domain. That's why the GNU free software foundation goes to such lengths
to ensure that people can do what they want (except make money, I guess)
off of their "copylefted" software. They can't just put the copyright in
the public domain, because it would not do what they want.

This appears to me to be a blatant violation of copyright to me.

But I'm not a lawyer.

Mike
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

Chang K Yoon

unread,
Jul 21, 1994, 9:48:43 PM7/21/94
to
In article <30n6ec$o...@sun001.dsccc.com> jmcc...@spd.dsccc.com (Mike McCarty) writes:
[stuff deleted]
>
>)I don't see any problem with this lrz/lsz package based on the
>)public domain rz/sz code. I presume "cosmetically changed"
>)means the user interface has been modified to better suit his
>)tastes. As far as I know he has the right to add value to the
>)PD rz/sz and do with the result what he wishes. He does not
>)appear to be misrepresenting the derivation of the work.
>
>Hmmm. When a copyright or patent is put in the public domain, that does
>not mean that there is no copyright or patent. It means that the public
>owns the copyright or patent.

Actually, when a copyright or patent is put in the public domain, there
IS no copyright any longer. The item that is placed in the public domain
truely means that it was placed in the public domain. You, me, or whoever
else wants to can do anything to it including making modifications and
then copyrighting the result.

>It does EMPHATICALLY NOT mean that a
>person can do what he wants to do with the material in the public
>domain.

I >ALMOST< completely disagree with this. There are a few restrictions,
of which the primary one is that you can't take a public domain item and
then attempt to copyright it.

>That's why the GNU free software foundation goes to such lengths
>to ensure that people can do what they want (except make money, I guess)
>off of their "copylefted" software. They can't just put the copyright in
>the public domain, because it would not do what they want.

Yes, this is true. However, the GNU FSF's "copylefted" statement is
actually talking about a copyright that gives you freedom to do anything
with the code, binaries, etc., except make money. I'd quote from the GNU
Public License, but unfortunately, I can't figure out how to put this
editor in the background. ^Z doesn't work. :(

>
>This appears to me to be a blatant violation of copyright to me.
>

Nope. Please see above statements.

>But I'm not a lawyer.

It's Ok. I'm not either. :)

Chang
--
---------------------------------------------------------------------------
| Chang Yoon | cy...@utdallas.edu -OR- |
| Center for Space Sciences - UT Dallas | cy...@utd500.utdallas.edu |
---------------------------------------------------------------------------

Peter da Silva

unread,
Jul 21, 1994, 9:44:22 PM7/21/94
to
In article <vandys.7...@cisco.com>,

Andrew Valencia <van...@cisco.com> wrote:
> Yes, but I went wading through the source hoping to find any other sign of
> copying, and failed. If any of the C source had been duplicated as
> clumsily, I would've expected to have found it. Instead, the structure, way
> of handling cancels, timeouts, etc. all look substantially different.

Supposedly he used a document in the public domain called "zmodem.doc" to
implement the program. The zmodem.h file is based on that document. If that's
the case the reason for the similarity to the Omen code is obvious, and quite
benign.

Peter da Silva

unread,
Jul 21, 1994, 9:46:22 PM7/21/94
to
In article <30mmnc$q...@mercury.mcs.com>, Leslie Mikesell <l...@MCS.COM> wrote:
> The terms may be legal, but I don't see how anyone can support them at a
> dialup site since they demand that you know what is running on the other
> end of the line.

Certainly. It's the most bizarre definition of "non-commercial" that I've
seen and I'm also sticking to the old version.

hamilton on BIX

unread,
Jul 22, 1994, 8:50:07 AM7/22/94
to
jmcc...@spd.dsccc.com (Mike McCarty) writes:

>Hmmm. When a copyright or patent is put in the public domain, that does
>not mean that there is no copyright or patent. It means that the public
>owns the copyright or patent. It does EMPHATICALLY NOT mean that a
>person can do what he wants to do with the material in the public
>domain. That's why the GNU free software foundation goes to such lengths
>to ensure that people can do what they want (except make money, I guess)
>off of their "copylefted" software. They can't just put the copyright in
>the public domain, because it would not do what they want.

>This appears to me to be a blatant violation of copyright to me.

>But I'm not a lawyer.

I think you should talk to one. Whatever is in the public domain
may be used by anyone for any otherwise legal purpose. That includes
publishing it for profit.

The reason the FSF uses a copyleft is because that last part (publishing
for profit) is not acceptable to them.

Regards,
Doug Hamilton KD1UJ hami...@bix.com Ph 508-358-5715
Hamilton Laboratories, 13 Old Farm Road, Wayland, MA 01778-3117, USA

Bill Pemberton

unread,
Jul 22, 1994, 9:04:04 AM7/22/94
to
In article <id.FDF...@nmti.com>, Peter da Silva <pe...@nmti.com> wrote:
>In article <30l4qj$l...@chuckwalla.cs.arizona.edu>,
>Gene Kim <gk...@CS.Arizona.EDU> wrote:
>> Could you elaborate about what you find objectionable? Were the
>> zm authors to simply replace their zmodem.h file with one from an old
>> rzsz package, would your qualms about copyright violations go away?
>
>No.
>
>They have established a reasonable suspicion that the whole package is
>copied, by using a clumsily disguised zmodem.h file. What else have they
>"borrowed"?

I disagree, the header file doesn't create reasonable suspicion of anything.
If the only example is that the #defines are similar, that doesn't tell me a
thing. The defines MUST be similar for the silly thing to work, it's part
of the protocol!

You know, there is a lot of code out there with:

#define TRUE 1
#define FALSE 0


Are they all copyright violations of the first one that came up with this?


Furthermore, look at the code. I haven't dug deep into it, but on a casual
look they are different. For example, you can actually read the code to zmrx.

Also, if they copied the code, why didn't they copy all of it? zmrx omits a
few things like the handling of ZSINIT. If you're going go copy, why leave
out major functionality?

--
Bill


James Michael Chacon

unread,
Jul 22, 1994, 10:02:04 AM7/22/94
to
hami...@BIX.com (hamilton on BIX) writes:

>jmcc...@spd.dsccc.com (Mike McCarty) writes:

>I think you should talk to one. Whatever is in the public domain
>may be used by anyone for any otherwise legal purpose. That includes
>publishing it for profit.

>The reason the FSF uses a copyleft is because that last part (publishing
>for profit) is not acceptable to them.

BZZTT...Wrong.

The FSF's copyleft never says *anywhere* in it you can't sell copylefted
software. It just says you also have to give access to the source as well.
There's nothing stopping me from taking gcc and advertising it (with source)
for $500. If someone wants to pay me for it, then that's their problem.

By your logic, companies like Cygnus and Lucid can't exist (which they do).
These places sell Copylefted software (and maintaince on it) for a living.

I think you need to go read the copyleft again.

James

Jim Balter

unread,
Jul 22, 1994, 10:48:26 AM7/22/94
to
In article <30n8hr$p...@news.utdallas.edu>,

Chang K Yoon <cy...@utdallas.edu> wrote:
>Yes, this is true. However, the GNU FSF's "copylefted" statement is
>actually talking about a copyright that gives you freedom to do anything
>with the code, binaries, etc., except make money.

Since when does the GNU copyleft forbid you from making money?
You can charge for copylefted software, but you can't horde it.
That may make it less likely that people will pay you money for it,
but it isn't disallowed.
--
<J Q B>

Peter da Silva

unread,
Jul 22, 1994, 1:28:21 PM7/22/94
to
In article <CtCEy...@murdoch.acc.virginia.edu>,

Bill Pemberton <wf...@tigger.itc.Virginia.EDU> wrote:
> If the only example is that the #defines are similar, that doesn't tell me a
> thing. The defines MUST be similar for the silly thing to work, it's part
> of the protocol!

Leaving aside the likelihood that the defines were copied from a paper, the
comments and the *names* of the symbols were very close, too. I wish someone
would post the zmodem.doc file and clear this whole thing up.

Peter da Silva

unread,
Jul 22, 1994, 1:31:39 PM7/22/94
to
In article <jqbCtC...@netcom.com>, Jim Balter <j...@netcom.com> wrote:
> Since when does the GNU copyleft forbid you from making money?
> You can charge for copylefted software, but you can't horde it.
> That may make it less likely that people will pay you money for it,
> but it isn't disallowed.

That reminds me an awful lot of the Administration's claim that Clipper
and the export ban don't *prevent* you from implementing a different
scheme. You can't sell it overseas, or to the government, or to people
who want to talk to the government... but they're not actually *forbidding*
non-escrowed encryption.

Jon Gefaell

unread,
Jul 22, 1994, 10:34:32 AM7/22/94
to
In article <30n6ec$o...@sun001.dsccc.com>,

Mike McCarty <jmcc...@spd.dsccc.com> wrote:
>
>Hmmm. When a copyright or patent is put in the public domain, that does
>not mean that there is no copyright or patent. It means that the public
>owns the copyright or patent. It does EMPHATICALLY NOT mean that a
>person can do what he wants to do with the material in the public
>domain. That's why the GNU free software foundation goes to such lengths
>to ensure that people can do what they want (except make money, I guess)
>off of their "copylefted" software. They can't just put the copyright in
>the public domain, because it would not do what they want.
>
>This appears to me to be a blatant violation of copyright to me.
>
>But I'm not a lawyer.

Neither do you understand the terms 'copyright' and 'public domain' and
I'll wager you've no idea what the GPL is either, since you couldn't
possibly understand the latter and not understand the former.
--
http://Hopper.ITC.Virginia.EDU/~jeg7e/ - rec.motorcycles, soc.motss, rec.guns
_____________________________________________________________________________
\ \ / Jon Gefaell, Computer Systems Engineer | Amateur Radio, KD4CQY
\/\/ (title here), Monticello Area Virtual Village | -Will chmod for Food-
\/ The University of Virginia, Charlottesville | Hac...@Virginia.EDU
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DoD #1439 '82 CB900F "The Turing Machine" - B4 t+ w++ dc g++ k+ s+ m r p++

Chuck Forsberg WA7KGX

unread,
Jul 22, 1994, 6:46:34 PM7/22/94
to
In article <CtCEy...@murdoch.acc.Virginia.EDU> wf...@tigger.itc.Virginia.EDU (Bill Pemberton) writes:
>In article <id.FDF...@nmti.com>, Peter da Silva <pe...@nmti.com> wrote:
>>In article <30l4qj$l...@chuckwalla.cs.arizona.edu>,
>>Gene Kim <gk...@CS.Arizona.EDU> wrote:
>>> Could you elaborate about what you find objectionable? Were the
>>> zm authors to simply replace their zmodem.h file with one from an old
>>> rzsz package, would your qualms about copyright violations go away?
>>
>>No.
>>
>>They have established a reasonable suspicion that the whole package is
>>copied, by using a clumsily disguised zmodem.h file. What else have they
>>"borrowed"?
>
>I disagree, the header file doesn't create reasonable suspicion of anything.
>If the only example is that the #defines are similar, that doesn't tell me a
>thing. The defines MUST be similar for the silly thing to work, it's part
>of the protocol!

By the same logic, there's nothing wrong with armed robbery compared to
unarmed robbery. You MUST use guns for the silly heist to work reliably!

They could have used a public domain version of zmodem.h without any
difficulty whatsoever interoperating with Omen Technology Products.

>
>You know, there is a lot of code out there with:
>
>#define TRUE 1
>#define FALSE 0
>
>
>Are they all copyright violations of the first one that came up with this?

I'm not complaining about their cpying of "#define SOH 1" from rz/sz
despite the fact their code never uses it.

I'm complaining about what they've copied from the Copyrighted
zmodem.h. The following makes the plagiarism clear:

rz> /*
rz> * Z M O D E M . H Manifest constants for ZMODEM
rz> * application to application file transfer protocol
rz> * Copyright 1993 Omen Technology Inc All Rights Reserved
rz> */
zm> /*
zm> * zmodem.h
zm> * zmodem constants
zm> * (C) Mattheij Computer Service 1994
zm> */

Obviously Mattheij isn't too bright on copyright basics. The (C) does not
have legal significance. Omen's "All Rights Reserved" does.

rz> #define ZMAXHLEN 16 /* Max header information length NEVER CHANGE */
zm> #define ZMAXHLEN 0x10 /* maximum header information length */

rz> #define ZMAXSPLEN 1024 /* Max subpacket length NEVER CHANGE */
zm> #define ZMAXSPLEN 0x400 /* maximum subpacket length */

rz> #define CANVHDR 01 /* Variable headers OK */
zm> #define ZF1_CANVHDR 0x01 /* Variable headers OK */

rz> #define ZMCHNG 8 /* Change filename if destination exists */
zm> #define ZF1_ZMCHNG 8 /* Change filename if destination exists */

>Furthermore, look at the code. I haven't dug deep into it, but on a casual
>look they are different. For example, you can actually read the code to zmrx.

rz/sz would be easier to read if it didn't have a zillion #ifdefs and special
cases to support the wide variety of platforms it supports. You should have
seen it before I removed the VMS and GEnie support from rz/sz 3.xx!

>Also, if they copied the code, why didn't they copy all of it? zmrx omits a
>few things like the handling of ZSINIT. If you're going go copy, why leave
>out major functionality?

Because it's a lousy, lazy copy that was clumsily hacked in in
attempt to disguise the plagiarism. That it's a piece of poorly
hacked compost does not excuse plagiarism and copyright
infringement.

It's obvious they did their code massaging with a guilty
conscience. They didn't have to recode the rz/sz zsendline()
into tx() et al because the zsendline routine is unchanged from
the PD versions. Their version is slower. It doesn't meet the
protocol definition beacause they made a mistake when they
attempted to hide the fact thet they'd copied zsendline()
instead of independently developing code.

Chuck Forsberg WA7KGX

unread,
Jul 22, 1994, 7:05:39 PM7/22/94
to
In article <id.QD...@nmti.com> pe...@nmti.com (Peter da Silva) writes:
>In article <CtCEy...@murdoch.acc.virginia.edu>,
>Bill Pemberton <wf...@tigger.itc.Virginia.EDU> wrote:
>> If the only example is that the #defines are similar, that doesn't tell me a
>> thing. The defines MUST be similar for the silly thing to work, it's part
>> of the protocol!
>
>Leaving aside the likelihood that the defines were copied from a paper, the
>comments and the *names* of the symbols were very close, too. I wish someone
>would post the zmodem.doc file and clear this whole thing up.

Zmodem.doc is a bit long to post in its entirety, but it contains none of
the plagiarized items I've been complaining about.

The ZMODEM Inter Application File Transfer Protocol

Chuck Forsberg

Omen Technology Inc


A overview of this document is available as ZMODEM.OV
(in ZMDMOV.ARC)


This file may be redistributed without restriction provided the text is
not altered.

Please distribute as widely as possible.

Omen Technology Incorporated
The High Reliability Software

17505-V Northwest Sauvie Island Road
Portland Oregon 97231
VOICE: 503-621-3406 :VOICE
Modem: 503-621-3746 Speed 1200,2400,19200(Telebit PEP)
Compuserve:70007,2304 GEnie:CAF
UUCP: ...!tektronix!reed!omen!caf

Chapter 0 Rev June-24-88 Typeset 6-24-88 1

Gregory Neil Shapiro

unread,
Jul 22, 1994, 7:49:46 PM7/22/94
to
zm may or may not be plagerized in some way, it's not my place to say.

rzsz is a licensed product only freely useable if used with Omen Systems or
you must pay for it.

So I don't have to worry about the battle over zm and the licensing charges
for rzsz, is there a zmodem implementation for Unix that is freely
available or doesn't have the tight restrictions on usage rzsz does? This
is for about 130 DECstations in a higher education environment.

I can't see paying money for students to download homework/ftp'ed files
from the system using rzsz and I don't want the school to be in legal
jeopardy by using zm which may be violating a copyright.

Is there any zmodem safe ground?

Paul Gilmartin

unread,
Jul 22, 1994, 8:59:42 PM7/22/94
to
Gregory Neil Shapiro (gsha...@monkeyboy.WPI.EDU) wrote:

: So I don't have to worry about the battle over zm and the licensing charges


: for rzsz, is there a zmodem implementation for Unix that is freely
: available or doesn't have the tight restrictions on usage rzsz does? This

Certainly. Chuck Forsberg referred in recent postings to "public domain"
zmodem. This is any release about 1.36 (08-31-87) or earlier, which many
sites still carry. For example:

Host ftp.uu.net

Location: /networking/terms
FILE -rw-r--r-- 59565 Jul 2 1992 zmodem.tar.Z

Host rascal.ics.utexas.edu

Location: /misc/unix
FILE -rw-r--r-- 56861 Mar 28 1989 zmodem.tar.Z

The code is robust and effective, IMHO.

-- gil

Paul A Vixie

unread,
Jul 22, 1994, 4:28:10 PM7/22/94
to
Chuck's earlier zmodem was posted to comp.sources.unix in volume 12.
See gatekeeper.dec.com:~ftp/pub/usenet/comp.sources.unix/volume12/zmodem/*

Chuck Forsberg WA7KGX

unread,
Jul 23, 1994, 2:58:45 AM7/23/94
to

There are a number of older rz/sz versions floating around up to 2.03
which are public domain. The README file in rz/sz 3.xx mentions this.

Unlike "KermitWare", the PD versions of rz/sz will remain public domain.


Omen provides the "ZMODEM Developer's Collection" with the
latest royalty free C source code and XMODEM, YMODEM, and ZMODEM
protocol description. These files are kept up to date with
reported bug fixes. They compile to functional Unix and VMS
programs that send and receive files with XMODEM, YMODEM, and
ZMODEM. Many versions of Unix and VMS are supported. These
files are the foundation of most ZMODEM ports including Telix,
Procomm, Qmodem, etc. Interfacing the high level ZMODEM
functions to the user's operating system and communications
primitives is the user's responsibility.

The Developers' Collection is sold on an as-is basis. It is
the customer's responsibility to interface the ZMODEM routines
to his desired communications environment.

Those desiring technical support may call 1-900-737-7836 at
$4.69 per minute. Unregistered callers seeking technical
support will be referred to our 900 number.


The ZMODEM source code in the Developer's Collection does not
include the Copyrighted ZMODEM-90(Tm) extensions (compression,
Mobyturbo(Tm), variable length headers, etc.) which require
sublicensing. Please note that rz/sz beginning with version 3.0
is Copyrighted, as noted in the rz.c, sz.c, and zmr.c source
files. Note that zmr.c is included in both rz and sz and so is
its copyright notice.

Base price is $89.00 (MSDOS 360k 5.25 in, check with order).
Add $5.00 for 3.5 inch. Contact Omen about other formats.
Checks not drawn on U.S. banks must add the bank collection fee
($50 minimum.)

ABA Routing #12300-2011. All wire transfer fees must be paid by
the customer. The Developer's Collection can be ordered by mail.

1994Jul22
94Jul22194946
CtCEys
D8A
DECstations
EDU
Followup
GSHAPIRO
MSDOS
Mobyturbo
Newsgroups
PD
Procomm
Qmodem
README
Telix
Tm
UUCP
VMS
WPI
XMODEM
YMODEM
ZMODEM
Zmodems
acc
alt
asteriod
collison

Robert Bauer

unread,
Jul 23, 1994, 3:50:26 AM7/23/94
to
In article <id.TD...@nmti.com>, Peter da Silva <pe...@nmti.com> wrote:
>In article <jqbCtC...@netcom.com>, Jim Balter <j...@netcom.com> wrote:
>> Since when does the GNU copyleft forbid you from making money?
>> You can charge for copylefted software, but you can't horde it.
>
>That reminds me an awful lot of the Administration's claim that Clipper
>and the export ban don't *prevent* you from implementing a different
>scheme. You can't sell it overseas, or to the government, or to people
>who want to talk to the government... but they're not actually *forbidding*
>non-escrowed encryption.

While your clipper analogy sounds good, the fact is that people *are* making
money from software distributed under the GPL. Case in point: Linux cdrom
sellers. All (or nearly all) of the software distributed on these disks is
copylefted.

Whether or not money can be made on alternative encryption schemes--should
the clipper proposal pass--remains to be seen.

Robert
--
_____ _ __ | rba...@ecst.csuchico.edu
_ __|___ | |_ / _|___ | N7TFZ@KE6LW.#NOCAL.CA.USA.NA
| '_ \ / /| __| ||_ / |------------------------------------------------
| | | |/ / | |_| _/ / |
|_| |_/_/ \__|_|/___| | "Unix wants to be free"

Andy Rabagliati

unread,
Jul 23, 1994, 2:31:49 AM7/23/94
to
Well, Chuck has some points. And, somehow I think that freeware writers
that go commercial somehow get a raw deal on net.opinion - Phil Katz,
and whoever did ARC got the same flak.

Haven't looked at the code myself - why bother when mathematical analyses
will show up in alt.sources tomorrow :-)

Cheers, Andy.

#! /bin/sh
echo "Read the source, Luke!"

Richard Kooijman

unread,
Jul 23, 1994, 5:00:36 AM7/23/94
to
c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:

>I'm complaining about what they've copied from the Copyrighted
>zmodem.h. The following makes the plagiarism clear:

>rz> * Z M O D E M . H Manifest constants for ZMODEM


>rz> * application to application file transfer protocol
>rz> * Copyright 1993 Omen Technology Inc All Rights Reserved
>rz> */
>zm> /*
>zm> * zmodem.h
>zm> * zmodem constants
>zm> * (C) Mattheij Computer Service 1994
>zm> */

So they used the wrong zmodem.h . The public domain zmodem.h isn't that
much different I guess.

>>Also, if they copied the code, why didn't they copy all of it? zmrx omits a
>>few things like the handling of ZSINIT. If you're going go copy, why leave
>>out major functionality?

>Because it's a lousy, lazy copy that was clumsily hacked in in
>attempt to disguise the plagiarism. That it's a piece of poorly
>hacked compost does not excuse plagiarism and copyright
>infringement.

You still haven't proven that. Saying that they used the wrong
zmodem.h is still a bit different from saying they copied all your code.

>It's obvious they did their code massaging with a guilty
>conscience. They didn't have to recode the rz/sz zsendline()
>into tx() et al because the zsendline routine is unchanged from
>the PD versions.

So if the zmodem.h was unchanged since the PD version, nobody would have
noticed anything.

>Their version is slower. It doesn't meet the
>protocol definition beacause they made a mistake when they
>attempted to hide the fact thet they'd copied zsendline()
>instead of independently developing code.

I am going to compare the versions for myself.


Richard.

Willard F. Dawson

unread,
Jul 23, 1994, 12:25:24 PM7/23/94
to
p...@sanitas.stortek.com (Paul Gilmartin) writes:

>Host ftp.uu.net

It's not all that robust and effective on Solaris 2.3, unfortunately.
I'm sure that some signalling has changed, requiring some tweaks...

Benjamin Z. Goldsteen

unread,
Jul 23, 1994, 1:26:01 PM7/23/94
to
p...@sanitas.stortek.com (Paul Gilmartin) writes:

>Host ftp.uu.net

It is old and doesn't implement a lot of things. On the other hand, I
am not sure what I am supposed to do with the newer code --
licensing-wise.

By the way, somebody wanted the public zmodem doc's. They aren't too
hard to find (I think they are somewhere on wuarchive, for example),
but here is one excerpt:


#define CANCRY 8 /* Receiver can decrypt */
#define CANFDX 01 /* Rx can send and receive true FDX */
#define CANOVIO 02 /* Rx can receive data during disk I/O */
#define CANBRK 04 /* Rx can send a break signal */
#define CANCRY 010 /* Receiver can decrypt */
#define CANLZW 020 /* Receiver can uncompress */
#define CANFC32 040 /* Receiver can use 32 bit Frame Check */
#define ESCCTL 0100 /* Receiver expects ctl chars to be escaped */
#define ESC8 0200 /* Receiver expects 8th bit to be escaped */
#define TESCCTL 0100 /* Transmitter expects ctl chars to be escaped
#define TESC8 0200 /* Transmitter expects 8th bit to be escaped

However, I can't find any other definitions for things like ZACK. I
didn't look very carefully, though.
--
Benjamin Z. Goldsteen

John Navas

unread,
Jul 23, 1994, 11:22:40 AM7/23/94
to
Andy Rabagliati (an...@wizzy.com) wrote:
> Well, Chuck has some points. And, somehow I think that freeware writers
> that go commercial somehow get a raw deal on net.opinion - Phil Katz,
> and whoever did ARC got the same flak.


In the case of Mr. Katz, it was hardly a "raw deal" -- he got started by
violating the copyright on ARC (name and source code) and got caught. SEA
(the authors of ARC) got "flak" for taking appropriate legal action
against PKware (Phil's company) from free spirits that don't believe in
software copyrights.

--
Best regards,
John

Chuck Forsberg WA7KGX

unread,
Jul 23, 1994, 4:19:46 PM7/23/94
to
In article <30qm7k$8...@liberator.et.tudelft.nl> ric...@dutepp6.et.tudelft.nl (Richard Kooijman) writes:
>c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>>I'm complaining about what they've copied from the Copyrighted
>>zmodem.h. The following makes the plagiarism clear:
>
>>rz> * Z M O D E M . H Manifest constants for ZMODEM
>>rz> * application to application file transfer protocol
>>rz> * Copyright 1993 Omen Technology Inc All Rights Reserved
>>rz> */
>>zm> /*
>>zm> * zmodem.h
>>zm> * zmodem constants
>>zm> * (C) Mattheij Computer Service 1994
>>zm> */
>
>So they used the wrong zmodem.h . The public domain zmodem.h isn't that
>much different I guess.

"I guess" ??? Why not learn the facts before posting?


They removed the legal copyright notice in the 3.24 zmodem.h and
substituted their own. If that was an honest mistake they must
have been brain damaged from drug overdose when they did it.

If they had used PD materials I wouldn't be pointing out their
copyright violation.

Garrett Wollman

unread,
Jul 23, 1994, 4:53:25 PM7/23/94
to
In article <1994Jul22.2...@omen.uucp>,

Chuck Forsberg WA7KGX <c...@omen.UUCP> wrote:
>rz> /*

>rz> * Z M O D E M . H Manifest constants for ZMODEM
>rz> * application to application file transfer protocol
>rz> * Copyright 1993 Omen Technology Inc All Rights Reserved
>rz> */
>zm> /*
>zm> * zmodem.h
>zm> * zmodem constants
>zm> * (C) Mattheij Computer Service 1994
>zm> */
>
>Obviously Mattheij isn't too bright on copyright basics. The (C) does not
>have legal significance. Omen's "All Rights Reserved" does.

Sorry, Chuck, but you lose. What has legal significance is the Berne
Convention, which says that copyright exists independent of any
notices affixed to the copyrighted work.

-GAWollman

--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wol...@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence. We like people
MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant

Jeffrey T Berntsen

unread,
Jul 23, 1994, 6:54:41 PM7/23/94
to
jna...@ccnet.com (John Navas) writes:

I wouldn't call what Mr. Katz is getting a raw deal, but possibly just deserts.
Look at the newer archivers out there like ARJ and UC2. They beat PKZIP in
terms of features, reliability, and compression obtained. Phil has just gotten
too commercial for his own good. (When you ignore requests for bug fixes from
the folks who made you #1 in the first place, it's gone too far....)

As far as the SEA legal action goes (yes I _AM_ dragging it up again), they
weren't exactly innocent of lifting other source code themselves. BTW, weren't
you involved in that whole thing, John?

>--
>Best regards,
>John

John Navas

unread,
Jul 23, 1994, 7:10:50 PM7/23/94
to
Jeffrey T Berntsen (je...@world.std.com) wrote:
> As far as the SEA legal action goes (yes I _AM_ dragging it up again), they
> weren't exactly innocent of lifting other source code themselves.

SEA did make some use of public domain code, which was entirely legal and
proper. Phil Katz made use of copyrighted SEA code, which was not.

> BTW, weren't
> you involved in that whole thing, John?

Yes. I was the expert for SEA. I testified that I had found evidence of
copyright infringement by PKware. That testimony was uncontroverted.

--
Best regards,
John

Paul A Vixie

unread,
Jul 23, 1994, 2:40:44 PM7/23/94
to
>They removed the legal copyright notice in the 3.24 zmodem.h and
>substituted their own. If that was an honest mistake they must
>have been brain damaged from drug overdose when they did it.

No, they didn't. The similarity with 3.24's zmodem.h file came via a
different path.

As moderator of comp.sources.unix I have been evaluating Mr. Forsberg's claims
of copyright violation. My preliminary findings is that he _does_ have cause
for complaint. But zmodem.h isn't the problem.

Chuck Forsberg WA7KGX

unread,
Jul 23, 1994, 11:57:40 PM7/23/94
to
In article <30s005$n...@GRAPEVINE.LCS.MIT.EDU> wol...@ginger.lcs.mit.edu (Garrett Wollman) writes:
>In article <1994Jul22.2...@omen.uucp>,
>Chuck Forsberg WA7KGX <c...@omen.UUCP> wrote:
>>rz> /*
>>rz> * Z M O D E M . H Manifest constants for ZMODEM
>>rz> * application to application file transfer protocol
>>rz> * Copyright 1993 Omen Technology Inc All Rights Reserved
>>rz> */
>>zm> /*
>>zm> * zmodem.h
>>zm> * zmodem constants
>>zm> * (C) Mattheij Computer Service 1994
>>zm> */
>>
>>Obviously Mattheij isn't too bright on copyright basics. The (C) does not
>>have legal significance. Omen's "All Rights Reserved" does.
>
>Sorry, Chuck, but you lose. What has legal significance is the Berne
>Convention, which says that copyright exists independent of any
>notices affixed to the copyrighted work.

Sorry, Garrett, you didn't pay attention to my statement. I did not say
the copyright was invalid because it had (C) instead of "All Rights
Reserved". I said the (C) was without legal significance. On the other
hand, "All Rights Reserved" does have significance in some parts of the
world, or at least it used to.

Paul Schauble

unread,
Jul 24, 1994, 4:01:35 AM7/24/94
to
hami...@BIX.com (hamilton on BIX) writes:

>jmcc...@spd.dsccc.com (Mike McCarty) writes:

Exactly. Note well that the GNU software is !!NOT!! in the public domain.

++PLS


Jim Balter

unread,
Jul 24, 1994, 5:42:33 AM7/24/94
to
In article <30qi42$l...@charnel.ecst.csuchico.edu>,

Robert Bauer <rba...@ecst.csuchico.edu> wrote:
>In article <id.TD...@nmti.com>, Peter da Silva <pe...@nmti.com> wrote:
>>In article <jqbCtC...@netcom.com>, Jim Balter <j...@netcom.com> wrote:
>>> Since when does the GNU copyleft forbid you from making money?
>>> You can charge for copylefted software, but you can't horde it.
>>
>>That reminds me an awful lot of the Administration's claim that Clipper
>>and the export ban don't *prevent* you from implementing a different
>>scheme. You can't sell it overseas, or to the government, or to people
>>who want to talk to the government... but they're not actually *forbidding*
>>non-escrowed encryption.
>
>While your clipper analogy sounds good, the fact is that people *are* making
>money from software distributed under the GPL. Case in point: Linux cdrom
>sellers. All (or nearly all) of the software distributed on these disks is
>copylefted.
>
>Whether or not money can be made on alternative encryption schemes--should
>the clipper proposal pass--remains to be seen.

The analogy sucks because the FSF puts no restrictions on alternative compilers,
alternative operating systems, alternative utilities, etc. FSF and Richard
Stallman may have a hidden agenda to prevent people from making money selling
*any* software, and the GPL may be a tool in this nefarious scheme, but it
*does not* operate in the way that the quoted restrictions operate, and
mentioning them is pure obfuscation.

The government will flood the market with inferior encryption, and will use
its power to prevent you from providing or using better encryption.

FSF floods the market with superior tools, and forbids you from restricting
the distribution of any improvement on those tools. It does not prevent
you from providing or using better tools.

Not at all the same thing.
--
<J Q B>

14033-R.SCHREIBMAIER(MT5655)1223MT

unread,
Jul 24, 1994, 6:16:28 PM7/24/94
to
From article <1994Jul23....@omen.UUCP>, by c...@omen.UUCP (Chuck Forsberg WA7KGX):

> In article <GSHAPIRO.94...@monkeyboy.WPI.EDU> gsha...@monkeyboy.WPI.EDU (Gregory Neil Shapiro) writes:
>>Is there any zmodem safe ground?
>
> There are a number of older rz/sz versions floating around up to 2.03
> which are public domain. The README file in rz/sz 3.xx mentions this.

I am curious to know precisely what the cutoff is. I had heard that
it was "somewhere around April 1988." However, I saw a zmodem package
on oak.oakland.edu that had the "pd" letters attached to the name.
It turns out to be SZ 2.12 of 5/29/88 and RZ 2.03 of 5/17/88. Is this
really public domain or did this one go beyond the cutoff date?

If it did go beyond the cutoff date, how does one find the latest
public domain version?

--
----------------------------------------------------
Bob Schreibmaier K2PH | UUCP: ...!att!mtdcr!bob
AT&T Bell Laboratories | Internet: b...@mtdcr.att.com
Middletown, N.J. 07748 | ICBM: 40o21'N, 74o8'W

Chuck Forsberg WA7KGX

unread,
Jul 24, 1994, 9:22:50 PM7/24/94
to
In article <CtGtv...@nntpa.cb.att.com> b...@mtdcr.att.com writes:
>From article <1994Jul23....@omen.UUCP>, by c...@omen.UUCP (Chuck Forsberg WA7KGX):
>> In article <GSHAPIRO.94...@monkeyboy.WPI.EDU> gsha...@monkeyboy.WPI.EDU (Gregory Neil Shapiro) writes:
>>>Is there any zmodem safe ground?
>>
>> There are a number of older rz/sz versions floating around up to 2.03
>> which are public domain. The README file in rz/sz 3.xx mentions this.
>
>I am curious to know precisely what the cutoff is. I had heard that
>it was "somewhere around April 1988." However, I saw a zmodem package
>on oak.oakland.edu that had the "pd" letters attached to the name.
>It turns out to be SZ 2.12 of 5/29/88 and RZ 2.03 of 5/17/88. Is this
>really public domain or did this one go beyond the cutoff date?

An early internal, non public domain rz/sz contained the zmr.c
file with the notation that it contained Omen Technology trade
secrets. That version did not include variable length headers.

When rz/sz with RLE was introduced in April 1989 it included
variable length headers and a strongly worded copyright notice.
From the April 1989 rz/sz archive README file:

"New for April 1989: ZMODEM compression and other compatible
extensions have been added to the rz and sz programs. Please
read the comments in the rz.c and sz.c source code for
licensing information for commercial use.

Previous versions of rz and sz (April 1988) remain Public Domain."

>
>If it did go beyond the cutoff date, how does one find the latest
>public domain version?

The current royalty free rz/sz is 2.03/2.16. This includes a
few bugfixes beyond the last pd released to Usenet. These files
are in the ZMODEM Developer's Collection ($89.00).

Peter da Silva

unread,
Jul 24, 1994, 9:44:05 PM7/24/94
to
In article <30qi42$l...@charnel.ecst.csuchico.edu>,
Robert Bauer <rba...@ecst.csuchico.edu> wrote:
> While your clipper analogy sounds good, the fact is that people *are* making
> money from software distributed under the GPL.

I know there are. No analogy is 100%. What I'm getting at is that the
conflict between the declared intent and the underlying goals is similar
in both cases.

> Whether or not money can be made on alternative encryption schemes--should
> the clipper proposal pass--remains to be seen.

I'm sure there will be ways of doing it. After all, people are already selling
BSD systems on CDROM even though you have to get the DES encryption code for
/etc/passwd elsewhere. The DES ban, foolish as it is, hasn't done it.

If I were Microsoft, trying to sell Secure Mail outside the US, I'd license
a third-party implementation of PGP from someone in India or Taiwan and
have them cut the disks in Australia.

Peter da Silva

unread,
Jul 24, 1994, 9:46:57 PM7/24/94
to
In article <jqbCtF...@netcom.com>, Jim Balter <j...@netcom.com> wrote:
> The government will flood the market with inferior encryption, and will use
> its power to prevent you from providing or using better encryption.

> FSF floods the market with superior tools, and forbids you from restricting
> the distribution of any improvement on those tools. It does not prevent
> you from providing or using better tools.

Of course. The government is the government, and the real consequences from
any action they initiate are guaranteed to be worse than anything any
individual without the privilege of initiating force can do.

That's a given in *any* situation.

Peter da Silva

unread,
Jul 24, 1994, 9:49:27 PM7/24/94
to
In article <1994Jul22.2...@omen.uucp>,
Chuck Forsberg WA7KGX <c...@omen.UUCP> wrote:
> In article <id.QD...@nmti.com> pe...@nmti.com (Peter da Silva) writes:
> >In article <CtCEy...@murdoch.acc.virginia.edu>,
> >Bill Pemberton <wf...@tigger.itc.Virginia.EDU> wrote:
> >> If the only example is that the #defines are similar, that doesn't tell me a
> >> thing. The defines MUST be similar for the silly thing to work, it's part
> >> of the protocol!

> >Leaving aside the likelihood that the defines were copied from a paper, the
> >comments and the *names* of the symbols were very close, too. I wish someone
> >would post the zmodem.doc file and clear this whole thing up.

> Zmodem.doc is a bit long to post in its entirety, but it contains none of
> the plagiarized items I've been complaining about.

So how about posting a pointer to it, perhaps an URL?

Chuck Forsberg WA7KGX

unread,
Jul 25, 1994, 12:56:44 AM7/25/94
to
In article <id.3VI...@nmti.com> pe...@nmti.com (Peter da Silva) writes:
>
>> >Leaving aside the likelihood that the defines were copied from a paper, the
>> >comments and the *names* of the symbols were very close, too. I wish someone
>> >would post the zmodem.doc file and clear this whole thing up.
>
>> Zmodem.doc is a bit long to post in its entirety, but it contains none of
>> the plagiarized items I've been complaining about.
>
>So how about posting a pointer to it, perhaps an URL?

oak.oakland.edu pub/misc/protocols/zmodem8.doc Regular text file.

Jim Balter

unread,
Jul 25, 1994, 6:25:48 AM7/25/94
to
In article <id.1VI...@nmti.com>, Peter da Silva <pe...@nmti.com> wrote:
>In article <jqbCtF...@netcom.com>, Jim Balter <j...@netcom.com> wrote:
>> The government will flood the market with inferior encryption, and will use
>> its power to prevent you from providing or using better encryption.
>
>> FSF floods the market with superior tools, and forbids you from restricting
>> the distribution of any improvement on those tools. It does not prevent
>> you from providing or using better tools.
>
>Of course. The government is the government, and the real consequences from
>any action they initiate are guaranteed to be worse than anything any
>individual without the privilege of initiating force can do.
>
>That's a given in *any* situation.

An interesting form of argument.

Aaron: "Bob tells me that he rejected Charlie's advances."
Doug: "That reminds me of how the state of Georgia will throw you in jail
for sodomy."
Aaron: "Wait, that not the same! It *Bob's* body!"
Doug: "Of course it's not the same. The government is the government, and


the real consequences from any action they initiate are guaranteed
to be worse than anything any individual without the privilege of
initiating force can do. That's a given in *any* situation."
--

<J Q B>

R. Stewart Ellis

unread,
Jul 25, 1994, 8:49:25 AM7/25/94
to
wda...@crl.com (Willard F. Dawson) writes:

>p...@sanitas.stortek.com (Paul Gilmartin) writes:

>>Gregory Neil Shapiro (gsha...@monkeyboy.WPI.EDU) wrote:

[...]


>>
>>The code is robust and effective, IMHO.

>It's not all that robust and effective on Solaris 2.3, unfortunately.
>I'm sure that some signalling has changed, requiring some tweaks...

Many apps that depend on sgtty semantics do not properly handle the streams
because of some screwups in the ioctl handling. I do not use zmodem from
2.3 anymore, but I believe things were better if zmodem is compiled in the
Sys5 universe.


--
R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765 ___________________
Humanities & Social Science, GMI Eng.& Mgmt. Inst. / _____ ______
Flint, MI 48504 el...@nova.gmi.edu / / / / / /
Gopher,chimera,nn,tin,jove,modems, free code is best!/________/ / / / /

Rob Healey

unread,
Jul 25, 1994, 11:53:57 AM7/25/94
to
In article <GSHAPIRO.94...@monkeyboy.wpi.edu>,

Gregory Neil Shapiro <gsha...@monkeyboy.WPI.EDU> wrote:
>I can't see paying money for students to download homework/ftp'ed files
>from the system using rzsz and I don't want the school to be in legal
>jeopardy by using zm which may be violating a copyright.
>
If this is an issue than kermit with good sized packets and
sliding windows should do the trick. Source and binarys are
on ftp: kermit.columbia.edu I believe. Kermit provides decent
emulation on PC's and Mac's so it should make a usable replacement
for any comm package a student would be using.

-Rob

Michael C. Loewen

unread,
Jul 25, 1994, 1:04:02 PM7/25/94
to
Would the folks participating in the Zmodem discussion consider removing
the alt.sources groups from their Newsgroups header? Or change it to
alt.sources.d?

--
Mike Loewen The Centre Programmers Unit BBS
mlo...@cpumagic.scol.pa.us (814) 353-0566 V.32bis/HST

Peter da Silva

unread,
Jul 25, 1994, 1:31:29 PM7/25/94
to
Clinton's stated goal is to prevent strong crypto. Since he's the government
he can pass laws discouraging the use of strong crypto (though for political
reason's he hasn't actually done that).

RMS's stated goal is to eliminate the sale of software as a product. Since
he is not the government he has to use more subtle means to achieve this
goal. But other than the fact that the government has the threat of force
to back up their actions the two strategies are quite similar: you establish
a standard (the FSF is trying to do this by making GCC so much better than
anyone else's compiler nobody considers using anything else, the government
is trying to do this by putting barriers in the way of competing schemes)
and you then use legal means to coerce people into supporting your goal (G++
is free, but if you link your code with the G++ library you have to put it
under the GPL if you want to distribute it, Clipper is exportable, but if
you want to use it you have to be wiretap-friendly).

In both cases there are ways around it. You can not use GCC, or you can not
use their libraries. You can assemble your Clipper-free phones in Taiwan and
only *import* them to the country (so Clipper exports jobs).

It's *not* an exact analogy. It is, however, comparable.

The whole GPL thing bothers me in a lot of ways. I *do* think software should
be delivered with the source code. I'm 90% in agreement with the FSF in just
about every front. I've just got this 10% that really burns. There's too much
good software out there that just wouldn't exist if there wasn't a commercial
software market. Ironically, I personally use very little of it... most of it
runs on operating systems that are foul and disgusting... I don't even sell
software: I do tech support... the FSF software makes my job easier.

But there's all these people out there who need software designed for novices.
It takes a lot of work to make software user-friendly. People aren't going
to do that if they're not going to get a lot of money for it, because it's
not fun. It's not satisfying. Hackers don't like doing it. But it's gotta be
done, and the only way I can see to pay for it is to charge the user money
and threaten him with the law if he gives it to his friends.

So, *yes*, force people to sell the source code with their packages. That's
a good goal! But by forcing people to give up the right to prevent piracy of
their code to use their tools is just counterproductive. I means that the
software I *most* want the source to... the packages that my users have on
their desks... is NEVER going to be available.

Back to the point... the FSF is doing almost what I thought they should be
doing. The problem, I thought, was just that they were going too far with
it. But no...

Now the government is doing the same thing. Heavy handed, as always, but
it's still attempting to capture market share and use it for political ends.
And it bothers me that I haven't opposed the tactic itself... just the goals
the tactic has been used for. I've been naive, thinking that only the good
guys (or at least the benign guys) are using the market for political goals.

And because they're the government, what they're doing is *nasty*.

John Navas

unread,
Jul 25, 1994, 2:46:17 PM7/25/94
to
Peter da Silva (pe...@nmti.com) wrote:
> Clinton's stated goal is to prevent strong crypto. Since he's the government
> he can pass laws discouraging the use of strong crypto (though for political
> reason's he hasn't actually done that).

...

> Now the government is doing the same thing. Heavy handed, as always, but
> it's still attempting to capture market share and use it for political ends.
> And it bothers me that I haven't opposed the tactic itself... just the goals
> the tactic has been used for. I've been naive, thinking that only the good
> guys (or at least the benign guys) are using the market for political goals.

> And because they're the government, what they're doing is *nasty*.


The good news is that in the long run such government tactics inevitably
fail.

--
Best regards,
John

System Administrator

unread,
Jul 25, 1994, 9:06:23 PM7/25/94
to
Peter da Silva (pe...@nmti.com) wrote:
: Clinton's stated goal is to prevent strong crypto. Since he's the government

: he can pass laws discouraging the use of strong crypto (though for political
: reason's he hasn't actually done that).

I'm against Clipper too, and I was against it before I ever heard of Bill
Clinton.

--
Greg Shenaut -- gksh...@ucdavis.edu

Matthew Hannigan

unread,
Jul 26, 1994, 5:51:08 AM7/26/94
to
pe...@nmti.com (Peter da Silva) writes:
>They have established a reasonable suspicion that the whole package is
>copied, by using a clumsily disguised zmodem.h file. What else have they
>"borrowed"?

Are you sure that they "clumsily disguised" it, and not merely
took out bits that they didn't use, thinking that it was perfectly
OK to use a .h file? (Whether it is actually OK or not)

--
-Matt Hannigan

Message has been deleted

Chuck Forsberg WA7KGX

unread,
Jul 26, 1994, 8:39:15 PM7/26/94
to

Yes, clumsily disguised. Compare zsendline() in sz (public
domain vsn) to the clumsily (and incorrectly!) rewritten tx() in
"zmtx/zmrx, zmodem implementation build from scratch".

With my zsendline, 75% of transmitted characters are handled
relatively efficiently with a bit test, a store, and macro
driven buffering (putchar()).

With this idiot's tx() we must first scan the list of special
characters (the switch statement). There are 9 entries in this
list so the compiler will usually generate a list search. The
alternative table driven code is unlikely since the list is
rather sparse (9 entries, size of 136) which would unreasonably
waste memory. After the list search, zm checks for a control
character, then calls a separate subroutine to update the
lastsent variable. This extra level of subroutine nesting on
every character adds even more overhead compared to zdendline().
Furthermore, this idiot always does an AND when setting
lastsent, despite the fact that lastsent is used only 1 per cent
of the time. Because lastsent is used only 1% of the time (when
a CR is sent) it is more efficient to mask lastsent only in the
rare cases where it is referenced instead of masking it once per
every character.

In his rush to disguise his plagiarizing of rz/sz, Mattheij
managed to mangle the logic that protects the Telenet PC Pursuit
CR@CR sequence. The ZMODEM spec calls for this sequence to be
protected, which zsendline does by escaping any CR that comes
after an @ character. Mattheij's stupid tx() only does this when
all control characters are escaped. If all control characters
are escaped there's no point checking for a CR preceded by the @
character, is there Jacques?

Telenet discontinued PC Pursuit earlier this year, so it would
seem logical that someone with the expertise Mattheij claims
to have would cleanly remove the PC Pursuit specific support
while he was redefining the ZMODEM protocol. Instead, he
just broke it in the process of covering up his plagiarism.

Note how cleverly Mattheij improved the clarity of zmodem.h
by changing decimal constants to hex when he substituted his
copyright notice for the legitimate Omen Technology copyright:

#define ZMAXHLEN 16 /* Max header information length NEVER CHANGE */
#define ZMAXHLEN 0x10 /* maximum header information length */


#define xsendline(c) putchar(c)
/*
* Send character c with ZMODEM escape sequence encoding.
* Escape XON, XOFF. Escape CR following @ (Telenet net escape)
*/
zsendline(c)
{

/* Quick check for non control characters */
if (c & 0140)
xsendline(lastsent = c);
else {
switch (c &= 0377) {
case ZDLE:
xsendline(ZDLE);
xsendline (lastsent = (c ^= 0100));
break;
case 015:
case 0215:
if (!Zctlesc && (lastsent & 0177) != '@')
goto sendit;
/* **** FALL THRU TO **** */
case 020:
case 021:
case 023:
case 0220:
case 0221:
case 0223:
xsendline(ZDLE);
c ^= 0100;
sendit:
xsendline(lastsent = c);
break;
default:
if (Zctlesc && ! (c & 0140)) {
xsendline(ZDLE);
c ^= 0100;
}
xsendline(lastsent = c);
}
}
}

void
tx_raw(int c)

{
#ifdef DEBUG
if (raw_trace) {
fprintf(stderr,"%02x ",c);
}
#endif

last_sent = c & 0x7f;

putchar(c);
}

/*
* transmit a character ZDLE escaped
*/

void
tx_esc(int c)

{
tx_raw(ZDLE);
/*
* exclusive or; not an or so ZDLE becomes ZDLEE
*/
tx_raw(c ^ 0x40);
}

/*
* transmit a character; ZDLE escaping if appropriate
*/

void
tx(unsigned char c)

{
switch (c) {
case ZDLE:
tx_esc(c);
return;
break;
case 0x8d:
case 0x0d:
if (escape_all_control_characters && last_sent == '@') {
tx_esc(c);
return;
}
break;
case 0x10:
case 0x90:
case 0x11:
case 0x91:
case 0x13:
case 0x93:
tx_esc(c);
return;
break;
default:
if (escape_all_control_characters && (c & 0x60) == 0) {
tx_esc(c);
return;
}
break;
}
/*
* anything that ends here is so normal we might as well transmit it.
*/
tx_raw((int) c);

Anthony D'Atri

unread,
Jul 27, 1994, 12:52:56 AM7/27/94