w8sdz@smoke.ARPA (Keith B. Petersen ) (09/09/88)
SIMTEL20 will be going with Phil Katz's new file archiving method
because it will be a standard set by a group effort of various
well-known shareware and PD authors. The file format will be clearly
defined and a public release will be made of portable C-language sources
suitable for porting to any operating system with a C compiler. The
file format and the portable source code will be placed in the PUBLIC
DOMAIN, with no restrictions on how it may be distributed. If you want
to pay $12.50 an hour for downloading it from one service when it is
also available from another for $5 an hour, that's your business.
--Keith
--
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARMY.MIL
Uucp: {att,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.army.mil!w8sdz
GEnie: W8SDZw8sdz@smoke.ARPA (Keith B. Petersen ) (09/11/88)
How can we reason that we should use ZOO as the new standard when the
latest is *not* public domain? To say "well, if you go back to an
earlier version it's public domain" indicates to me that if we did that
we would never see any growth in the PUBLIC DOMAIN version because
anything with more features would be (and is) copyrighted.
We should not place ourselves in a position where a copyright holder has
control over the future growth of *any* standard. That's the mistake we
made when we all chose to use ARC.
--
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARMY.MIL
Uucp: {att,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.army.mil!w8sdz
GEnie: W8SDZcww@ndmath.UUCP (Clarence W. Wilkerson) (09/12/88)
As long as it agreed that the Zoo file format is public domain and that the term "ZOO" can be used to describe the process, I would suggest using this standard. It is slower than PKPAK, but I assume Katz or other talented programmers could produce faster versions by handcoding it. .
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/12/88)
In article <1213@ndmath.UUCP> cww@ndmath.UUCP (Clarence W. Wilkerson) writes: >As long as it agreed that the Zoo file format is public domain >and that the term "ZOO" can be used to describe the process, I >would suggest using this standard. It is hereby agreed that the zoo file format is public domain and the term "zoo" may be used to describe the process. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/14/88)
In article <8476@smoke.ARPA> w8sdz@brl.arpa (Keith B. Petersen (WSMR|towson) <w8sdz>) writes: >How can we reason that we should use ZOO as the new standard when the >latest is *not* public domain? Keith, zoo the archiver itself may not be, but the archive format is. Let's assume the new public domain standard that you mentioned has come into being. Both the format and the source code are in the public domain. Now suppose somebody takes the source code, adds great speed and some new features that a lot of people want, and distributes the result as a copyrighted program *without source*, just for MS-DOS. Suppose this new program creates archives that can still be extracted by previous programs, so MS-DOS users don't feel bad about using it, and it becomes a de facto standard--but it uses an undocumented extended archive format. You've lost control. Any other extensions you now make to the public domain format will likely be incompatible with the extensions already made in the format used by this new binary-only program. By the way, nobody is actually forbidden from distributing zoo 2.x, though a lot of articles make it sound that way. All that they have to do is EITHER conform to some very reasonable requirements, OR contribute 10% of the gross to a non-profit organization of my choice, OR contact me to negotiate an exception. If somebody is unwilling to do even one of these three, how much trouble do you expect me to go to on his behalf? -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/14/88)
In article <8476@smoke.ARPA> w8sdz@brl.arpa (Keith B. Petersen (WSMR|towson) <w8sdz>) writes: >How can we reason that we should use ZOO as the new standard when the >latest is *not* public domain? To say "well, if you go back to an >earlier version it's public domain" indicates to me that if we did that >we would never see any growth in the PUBLIC DOMAIN version because >anything with more features would be (and is) copyrighted. This assumption may have arisen because I didn't quite explain the idea behind 2.0 having different restrictions than previous versions. My general policy in the future will be to have some reasonable restrictions on the distribution of the then-current version, with all previous versions having no restrictions other than that the recipient know he's not getting the current version. When 2.0 is superseded by any significant upgrade, that upgrade will have some reasonable distribution requirements, but the restrictions on 2.0 will be lifted. The philosphy is that those who provide free software to others at a low cost and without trying to restrict redistribution get to distribute the current version. Those who do otherwise get to distribute the slightly-outdated but still-extremelely-useful previous version. Since the intent is to maintain both upward and downward compatiblity, nobody gets to receive a zoo archive that can't be listed and extracted. So, from the point of view of the user: 1. If I'm willing to go to slight trouble, I always get to use the latest version. 2. If I want to get zoo from a source that doesn't conform to the current version's distribution requirements, I possibly am a version behind. But I still get to extract all zoo archives I find anywhere. Should there ever be a need to change zoo such that downward compatibility is lost (no such plans for now), I will distribute a new version that will be redistributable without restrictions. You only have my verbal promise, but that's about all you get in this business anyway. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
pjh@mccc.UUCP (Pete Holsberg) (09/15/88)
In article <3916@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: ...In article <1213@ndmath.UUCP> cww@ndmath.UUCP (Clarence W. Wilkerson) writes: ...>As long as it agreed that the Zoo file format is public domain ...>and that the term "ZOO" can be used to describe the process, I ...>would suggest using this standard. ... ...It is hereby agreed that the zoo file format is public domain and the ...term "zoo" may be used to describe the process. ...-- ...Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi Terrific, Rahul!! Now, would you say the same thing about the zoo programs? :-) Pete
pjh@mccc.UUCP (Pete Holsberg) (09/15/88)
Keith, When will it be ready?
les@chinet.UUCP (Leslie Mikesell) (09/15/88)
In article <3944@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >>How can we reason that we should use ZOO as the new standard when the >>latest is *not* public domain? >Keith, zoo the archiver itself may not be, but the archive format is. >Let's assume the new public domain standard that you mentioned has come >into being. Both the format and the source code are in the public >domain. Now suppose somebody takes the source code, adds great >speed and some new features that a lot of people want, and distributes >the result as a copyrighted program *without source*, just for MS-DOS. Since we are supposing, why not suppose instead that people will ignore the copyrighted binary since they can't count on everyone having it. Now everyone loses out on those nifty features. Anyway "great speed" would probably come from scrapping the source code and working in assembly. >You've lost control. Any other extensions you now make to the public >domain format will likely be incompatible with the extensions already >made in the format used by this new binary-only program. Or suppose someone takes your now public-domain file format and produces a product with useful extensions (say, multi-part mailable output or maintaining links where supported by the OS, or new compression methods) without using your source code. It would just take more effort (and thus make it less likely that anyone will have the benefits of these additions). >... If somebody is unwilling to >do even one of these three, how much trouble do you expect me to go to >on his behalf? As long as there are any restrictions on distribution zoo is unlikely to become a real standard especially in light of the arc fiasco. Of course you don't owe anyone a free program but it is good and I would like to see it extended, not restricted. Les Mikesell
ward@cfa.harvard.EDU (Steve Ward) (09/16/88)
... The summary line is an overstatement. I don't think anyone characterizes Rahul in any negative way. I don't know Rahul, but feel compelled to point out that he is taking one of two very reasonable and favorable (to the rest of us) positions that greatly benefit the public. The first position is to place code in the public domain, period. The second (Rahul's) position is to copyright the code with explicit provisions for anyone is a non-commercial, non-profit environment to freely use and redistribute the source code and binaries. Rahul further provides for the commercialites and profitites by stating that "easy terms" are available. Furthermore, Rahul has placed the zoo archive file format into the public domain along with the use of word zoo as a descriptive term for file archiving using this format. I say, give Rahul a strong round of applause. Maybe you would like him to place it all in the PD, but the way I see the public get at least 2 out a possible 3 and should be appreciative of this. For the hardcore publicites, since the zoo archive format is in the public domain, write your own version of zoo from scratch and put it in the PD! Voila! you will have exactly what you want. Interestly, everyone seems to think that enhanced versions will be rewritten versions anyway, so just rewrite from scratch and you'll get your PD program. You can even use the term "zoo" in your manuals and docs and pollute the english language with zoo-verbs and zoo-nouns and zoo-adverbs! Now I also like the idea of a callboration for a PD standard for archiving. This is especially attractive now because a lot of good work has been done, implying (hope,hope) that the next generation will be better, and more importantly, the standard will be fully documented in a written standards document for everyone to use in writing whatever (presumably PD :-) ) software they desire, while remaining compatible. Since the zoo archive file format is in the PD, I assume that it will at least get reviewed and considered in the development process for this upcoming PD archive standard. Steven Ward ...harvard!cfa!ward
rlb@xanth.cs.odu.edu (Robert Lee Bailey) (09/16/88)
In article <8465@smoke.ARPA> you write: >SIMTEL20 will be going with Phil Katz's new file archiving method >because it will be a standard set by a group effort of various >well-known shareware and PD authors. The file format will be clearly >defined and a public release will be made of portable C-language sources >suitable for porting to any operating system with a C compiler. The >file format and the portable source code will be placed in the PUBLIC >DOMAIN, with no restrictions on how it may be distributed. If you want >to pay $12.50 an hour for downloading it from one service when it is >also available from another for $5 an hour, that's your business. AMEN! I'm glad to see that finally there is going to be some cooperation in setting a standard archive format. I, for one, don't like being held at the whim of a company (SEA) that wants to act in such a manner that hurts everyone in the PC universe. I hope that this standard will also be submitted to IEEE for consideration. IEEE adoption of this as a standard would insure that NO ONE company could claim that it belongs to them. This would certainly insure file compatibility regardless of the type of system. Bob Bailey
dennis@raphel.UUCP (Dennis Vogel) (09/16/88)
In article <1088@cfa.cfa.harvard.EDU>, ward@cfa.harvard.EDU (Steve Ward) writes: > ... > You can even use the term > "zoo" in your manuals and docs and pollute the english language > with zoo-verbs and zoo-nouns and zoo-adverbs! > > Steven Ward ...harvard!cfa!ward I haven't seen this mentioned here but I may have missed it. What is the derivation of the term 'zoo' in Rahul's archiving/ compression tools? Is it an acronym? I know it came well before the current situation with SEA v. PK but is it intended to be a reflection on the state of things in this area of shareware development? Rahul, enquiring minds want to know! Dennis R. Vogel AT&T Bell Laboratories Somerset, NJ
george@rebel.UUCP (George M. Sipe) (09/17/88)
In article <8476@smoke.ARPA> w8sdz@brl.arpa (Keith B. Petersen (WSMR|towson) <w8sdz>) writes: >How can we reason that we should use ZOO as the new standard when the >latest is *not* public domain? To say "well, if you go back to an >earlier version it's public domain" indicates to me that if we did that >we would never see any growth in the PUBLIC DOMAIN version because >anything with more features would be (and is) copyrighted. > >We should not place ourselves in a position where a copyright holder has >control over the future growth of *any* standard. That's the mistake we >made when we all chose to use ARC. >-- >Keith Petersen >Arpa: W8SDZ@SIMTEL20.ARMY.MIL >Uucp: {att,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.army.mil!w8sdz >GEnie: W8SDZ I believe I understand the point Keith is trying to make (in this and a number of other postings). But, consider this: 1. Katz et. al. come out with a new (non-infringing) archive utility with speed and features roughly comparable to zoo 1.71 (public domain). 2. After some time, it is reasonably debugged. 3. Someone (maybe me :-) takes it, makes it faster and adds many very useful features so that everyone will want to use it (like zoo 2.0 maybe). BUT, I copyright it with whatever unreasonable terms I can think up. Of course, everyone would be free to use the previous PD version if they were willing to give up my improvements. They could even reimplement the new features in the PD version and keep it PD if they wanted to. What's the difference between this and using the PD zoo as a base to build upon? Just (1) the PD zoo is here today and debugged, (2) the PD zoo has many useful support utilities (of varying PD/copyright status), (3) the PD zoo has been proven across a number of diverse systems and has a current "following". Consider supporting zoo, or at least PD zoo. If anyone knows Katz, ask him to use PD zoo as his starting point. At least ask him to use its file format. The file format is PD as is the term "zoo". Let's not get another format just to be different when it is not necessary. -- George M. Sipe, Phone: (404) 662-1533 Tolerant Systems, 6961 Peachtree Industrial, Norcross, GA 30071 UUCP: ...!{decvax,hplabs,linus,rutgers,seismo}!gatech!rebel!george
jamesd@qiclab.UUCP (James Deibele) (09/18/88)
In article <8465@smoke.ARPA> w8sdz@brl.mil (Keith Petersen) writes: >SIMTEL20 will be going with Phil Katz's new file archiving method >because it will be a standard set by a group effort of various >well-known shareware and PD authors. The file format will be clearly >defined and a public release will be made of portable C-language sources >suitable for porting to any operating system with a C compiler. The >file format and the portable source code will be placed in the PUBLIC >DOMAIN, with no restrictions on how it may be distributed. If you want Did Thom Henderson (principal of SEA) kick your dog or something, Keith? ARC is a file format that's clearly defined, available now, with source available. Machines that are capable of reading SEA-style ARC format are not limited to IBM and clones, but include Amiga, Apple, Atari (8-bit), Atari ST, CP/M, Macintosh, UNIX, and VMS machines. For all I know, there are more. SEA hasn't gone after anybody except Phil Katz, who was going after their bread-and-butter market, site licensing (that's where the shareware authors who make more than $50 total in registrations are making their money, not from the public). There's been a lot of concern over the lawsuit in FidoNet because ARC (or its derivatives) is used constantly to move mail. Henderson has expressed some agreement to signing releases for use of ARC, but so far as I know, no-one has taken them up on it. SEA is a four-person firm. PKware is a four-person firm. SEA approached PKware about coming to some sort of licensing agreement, the terms of which only PKware and SEA know. PKware declined. SEA spent 8 months and $40,000 in legal fees getting their ducks lined up, time they undoubtedly could have put to better use in speeding up ARC. From what I remember, SEA tolerated PKware for a long time, even though PKware was actively solicting donations from day one. They reacted only when PKware started taking out ads deni- grating ARC. SIMTEL20 can do whatever. Encode your stuff with ROT-13 if it brings you joy. Meanwhile, I'll continue to use a standard that all my callers, even non-DOS types, can use. -- James S. Deibele jamesd@qiclab or jamesd@percival TECHBooks: The Computer Book Specialists (800) TECH-BKS 3646 SE Division Portland, OR 97202 (503) 238-1005 TECHBooks One BBS (#1:105/4.0); 3/12/24 (503) 760-1473
w8sdz@smoke.ARPA (Keith B. Petersen ) (09/18/88)
The officers of FIDO had better do some calling around, as I did.
Tell them to start with Gary Conway, author of the popular NARC
menu-driven ARC viewer/extractor/etc. Gary's program is written TOTALLY
in assembler. Gary has had to hire a lawyer after SEA contacted him
with certain demands only Gary can tell you about.
I'm surprised that the Fido group is so uninformed. They had better do
some inventigation of their own before aligning themselves with SEA.
Don't take my word - call various shareware authors who write programs
that do anything with or to ARC files. Many of them are on CIS's IBM
Forum and they are up in arms! Read the "Hot Topics" thread there.
Please let's move this to comp.sys.ibm.pc *only*. The binaries
discussion group is for discussing the programs posted to
comp.binaries.ibm.pc.
--
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARMY.MIL
Uucp: {att,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.army.mil!w8sdz
GEnie: W8SDZ