mjranum@gouldsd.UUCP (03/20/87)
The other day I happened upon something QUITE interesting that I think might spark some discussion. (We have a source license here for Sun UNIX, so don't bother having your lawyers call me). Anyhow, I noticed that THE SOURCE FOR UUCP HAS NO COPYRIGHT NOTICES IN IT except for in some of the more recent utilities such as uuencode and uudecode. "Hmmm.... very funny, thinks I..." I called one of my friends who has source license for a dual-port OS, including AT&T source and BSD, and asked him the same question. Same answer. Noplace (unless grep is broken) were the magic words 'copyright' to be found. (again, except for the newer tools). uucico, uuxqt, and all those goodies were dated but not copyrighted. In fact, I took a look at some old old hardcopy another fellow I know has, and there were no copyright notices in version 7 either. I contacted the offices of AT&T (the email address fcp@alice) that was given by the fellow from the licensing dept during the recent 'public domain yacc' scandal. I asked them what the deal is. I got a note saying that "we'll get back in touch with you". My questions are as follows, and I invite all comments and answers from the net: 1) what *REALLY* is the copyright status of uucp ? 2) regardless of the answer to the above, what does a total lack of copyright notices mean ? 3) can someone be held legally at fault for, in all good faith, assuming that the global abscence of copyright information indicates that the code is public-domain, and (for example) posting it to the net ? The last comment there is playing the devil's advocate, but I think you see my point. Those of us who frequent the grey areas of bulletin boards know all to well the *REAL* status of anything that doesn't carry a copyright notice. Why is uucp different other than the fact that AT&T's lawyers outnumber the populace of Lichtenstien ? I invite discussion of this, and encourage those of you who have source licenses to check your sources and let me know what you find. "Quick, Jeeves, my asbestos underwear !!" --mjr(); -- "It is better to shred the bugger than to bugger the shredder." -ancient doltic proverb.
news@seismo.UUCP (03/20/87)
UUCP (and the rest of the Unix sources) are LICENSED software from ATT. When your site received your sources from ATT, they argeed in writing to protect them as a valuable trade secret of ATT. The sources remain the property of ATT and they have the right to revoke your license to use them at any time if you do not take proper precautions to safegaurd the files. The licensing is a STRONGER protection than copyright. Your company would probably go out of business (at least your division) if ATT revoked your companies license because of you giving away ATT property. Remember, your company did not buy UNIX source, they bought the right to USE and RELICENSE UNIX. Unix remains the property of ATT. ---rick (I am not an ATT employee, never was and probably never will be. I just bothered to read our license agreement)
schoet@ernie.Berkeley.EDU.UUCP (03/21/87)
There's a method of "copying" another program that seems to have held in court in the past: Someone with access to the source of the program in question studies it carefully and then writes up a description of protocols, interfaces, and functional diagrams. This is then handed to a programmer who does not have access to any of the source and "blindly" produces a program that does the same thing. The company who wrote the original program has no claim, so I'm told, to the new program because it was not a copy of the original. This may sound like splitting hairs, but I recall reading of occaisons where this method has been used sucessfully and legally. Of course I am not a legal expert and may have dreamed the whole thing up, but I think I could dig up the source of the information if anyone's interested. Anyone out there with access to UUCICO care to do the first step? If you did, and posted the result, you'd probably have an equivalent program within a month. Steve ucbvax!schoet The opinions above are mine alone, and are not posted on behalf of anybody.
ron@brl-sem.UUCP (03/21/87)
In article <480@gouldsd.UUCP>, mjranum@gouldsd.UUCP (Marcus J Ranum) writes: > > The other day I happened upon something QUITE interesting that I > think might spark some discussion. (We have a source license here for Sun > UNIX, so don't bother having your lawyers call me). Anyhow, I noticed that > THE SOURCE FOR UUCP HAS NO COPYRIGHT NOTICES IN IT except for in some of > the more recent utilities such as uuencode and uudecode. Up until very recently you never found a copyright notice in UNIX software. UNIX is not protected by copyright, but rather by trade secret. In your agreement with AT&T (or Western in the old days), you agreed not to divulge the UNIX source code nor information on how it operates. Despite the lack of copyright notices in UUCP, it is still AT&T proprietary. -Ron
ron@brl-sem.UUCP (03/22/87)
In article <17953@ucbvax.BERKELEY.EDU>, schoet@ernie.Berkeley.EDU (Steve Schoettler) writes: > > There's a method of "copying" another program that seems to have held > in court in the past: > > Someone with access to the source of the program in question studies it > carefully and then writes up a description of protocols, interfaces, and > functional diagrams. WRONG, WRONG, WRONG. This will not work with UUCP, nor any of the AT&T UNIX code. Once again, UNIX is protected by TRADE SECRET status. You may not divulge the manner that UNIX works without being in violation of the agreement you have with AT&T. -Ron
roy@phri.UUCP (03/22/87)
In article <696@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: > Once again, UNIX is protected by TRADE SECRET status. You may not divulge > the manner that UNIX works without being in violation of the agreement > you have with AT&T. Doesn't that mean that pretty much all of what is on unix-wizards is a violation of our license agreements? How many times have we seen somebody explain that X happens when you do Y because you zap the Z entry in the inode? If that's not divulging information about how Unix works internally, then I don't know what is. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"
jim@hoptoad.uucp (Jim Joyce) (03/22/87)
The UNIX source has an interesting history -- it was not always trade secret! Version 5, I believe, was copyright. This means (if they followed through and filed their copyright claim) that at least two pages of source code were printed and sent to the Library of Congress by AT&T. The legality of claiming trade secret after such action has always seemed to me spurious. Publication of Maurice Bach's The Design of the UNIX Operating System seems yet another indication that UNIX's trade secret status is over. AT&T has told me that the trade secret was not simply the code, but the algorithms. Bach has divulged the algorithms. I have been told that trade secrets must be kept secret; but if over a thousand people in various organizations know something, is it still secret? Some lawyers I have talked with argue yes, and others say no. Naturally, I go along with the trade secret behavior because I do not want to be the test case for AT&T. Disclaimer: I am not a lawyer. But: My info about AT&T's posture on trade secret came from Otis Wilson and Bob Guffey of AT&T Licensing. And No, they wouldn't put anything in writing.
guy%gorodish@Sun.COM (Guy Harris) (03/23/87)
>AT&T has told me that the trade secret was not simply the code, but the >algorithms. Bach has divulged the algorithms. Hell, AT&T divulged some information about the internals of UNIX in the first UNIX issue of the BSTJ. I do not believe that their lawyers are stupid; I presume they have at least some reason to hold the legal opinion that they can still protect UNIX as a trade secret given that.
ddb@viper.UUCP (David Dyer-Bennet) (03/23/87)
In article <480@gouldsd.UUCP> mjranum@gouldsd.UUCP (Marcus J Ranum) writes: >3) can someone be held legally at fault for, in all good faith, assuming > that the global abscence of copyright information indicates that > the code is public-domain, and (for example) posting it to the net ? > > The last comment there is playing the devil's advocate, but I think >you see my point. Those of us who frequent the grey areas of bulletin boards People only have access to the AT&T uucp source under an explicit license agreement, which they would be violating if they posted the source to the net. Copyright isn't the only way to protect computer software! In fact, copyright makes it certain that the code WILL eventually fall into the public domain; it may be that they have deliberately NOT copyrighted the code for that reason. -- David Dyer-Bennet UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!ddb UUCP: ...ihnp4!umn-cs!starfire!ddb Fido: sysop of fido 14/341, (612) 721-8967
geoff@desint.UUCP (03/23/87)
Keywords: In article <694@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: > Up until very recently you never found a copyright notice in UNIX software. > UNIX is not protected by copyright, but rather by trade secret. In your > agreement with AT&T (or Western in the old days), you agreed not to > divulge the UNIX source code nor information on how it operates. Despite > the lack of copyright notices in UUCP, it is still AT&T proprietary. I'd decided to keep my trap shut about this during the recent Yacc controversy, but since Ron's mentioned it I thought I'd toss in my two cents' worth. The interesting thing about trade secrets is that if they ever get publicly exposed, even if it's through malice, they are effictively lost. The interesting thing about copyrights is that, if you can prove that the copyrighted material was ever published WITHOUT a copyright notice, you can't ever claim copyright. I will leave you to draw your own own conclusions about Yacc on the DECUS tape. You ain't gonna catch ME prodding the AT&T lion. WARNING: I'm not a lawyer. If you take actions based solely on the legal opinions in this article, you are an idiot and I do not accept responsibility. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
ed@mtxinu.UUCP (03/24/87)
In article <480@gouldsd.UUCP> mjranum@gouldsd.UUCP (Marcus J Ranum) writes: > The other day I happened upon something QUITE interesting ... >THE SOURCE FOR UUCP HAS NO COPYRIGHT NOTICES IN IT except for in some of >the more recent utilities such as uuencode and uudecode. The legal advice I've received over the years indicates: The lack of copyright notices is essentaially irrelevent. The source licence under which you received the code protects it as a *trade secret,* which means that it contains "intellectual property" of the licensor and that it may be disclosed only in accordance with the terms of the license. The original Unix sources were protected only as trade secrets. It is only recently that vendors have been adding copyrights to the source as well. Copyright does not imply anything about trade secret, i.e. trade secret items may or may not be copyrighted as well. Nor does the lack of copyright notice imply lack of copyright. I don't remember the details, but recent (well relatively recent - it was within the last 10 years) legislation has allowed for copyrighting of materials even if no notice is given. Consult a lawyer for real advice. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
ron@brl-sem.UUCP (03/24/87)
In article <15443@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > Hell, AT&T divulged some information about the internals of UNIX in > the first UNIX issue of the BSTJ. I do not believe that their > lawyers are stupid; I presume they have at least some reason to hold > the legal opinion that they can still protect UNIX as a trade secret > given that. If you think you can reproduce UNIX given the published manuals, books, and journal articles, go to it. It's been done before, and if you want to give it away, I'm sure Stallman would like to hear from you. -ROn
zemon@felix.UUCP (03/24/87)
If you examine your Unix license you will find attached to
it a *large* list of files which constitute what you have
licensed. Notice is not in the files because all of the
files are explicitely called out in the contract.
The list makes pretty boring reading since it goes
something like this:
/bin/adb
/bin/at
/bin/cat
...
but it lists *every* file which is licensed AT&T property.
Why not give up on UUCP and write a replacement using the
Kermit protocol? Doing so wouldn't be much more work than
a small program which invokes C-Kermit instead of uucico
and Kermit really is public domain -- and well documented
and understood!
--
-- Art Zemon
FileNet Corporation
Costa Mesa, California
...!hplabs!felix!zemoned@mtxinu.UUCP (03/24/87)
>The interesting thing about trade secrets is that if >they ever get publicly exposed, even if it's through malice, they are >effictively lost. This is not necessarily true. It depends on the nature of the exposure and the particulars of the contracts. > The interesting thing about copyrights is that, if >you can prove that the copyrighted material was ever published WITHOUT >a copyright notice, you can't ever claim copyright. This is no longer true. Recent changes in copyright legislation have made it possible to claim copyright even after a work has been released without any copyright notice. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
haddock@ti-csl.UUCP (03/25/87)
In article <2473@felix.UUCP> zemon@felix.UUCP (Art Zemon) writes: > >Why not give up on UUCP and write a replacement using the >Kermit protocol? Doing so wouldn't be much more work than >a small program which invokes C-Kermit instead of uucico >and Kermit really is public domain -- and well documented >and understood! >-- > -- Art Zemon Someone correct me if I'm wrong but it is my belief that Kermit is freely distributable but *NOT* Public Domain. Public domain means I can do ANYTHING I want with it INCLUDING selling it in part or in it entirety. Kermit, I believe, has a copyright from Columbia U. plus you need to sign an agreement with Columbia U if you want to use Kermit in a commercial product. Sorry, but I've seen this too many time to let it go by now. -Rusty- ================================================================ Rusty Haddock +++ Texas Instruments, Inc. +++ Dallas, Texas Computer Science Center, CRD&E +++ CSNET: Haddock@TI-CSL USENET: {ut-sally!im4u,convex!smu,sun!texsun}!ti-csl!haddock -- ================================================================ Rusty Haddock +++ Texas Instruments, Inc. +++ Dallas, Texas Computer Science Center, CRD&E +++ CSNET: Haddock@TI-CSL USENET: {ut-sally!im4u,convex!smu,sun!texsun}!ti-csl!haddock
jpm@bnl.UUCP (03/26/87)
>> ...THE SOURCE FOR UUCP HAS NO COPYRIGHT NOTICES IN IT... > > Up until very recently you never found a copyright notice in UNIX software. > UNIX is not protected by copyright, but rather by trade secret. In your > agreement with AT&T (or Western in the old days), you agreed not to > divulge the UNIX source code nor information on how it operates. Despite > the lack of copyright notices in UUCP, it is still AT&T proprietary. What about people who have obtained UNIX sources without ever being bound by an AT&T license agreement? The site they got them from is in trouble, but what legal action can AT&T take against the individual? (not that anybody in their right mind would want to be the test case; AT&T has more lawyers than all the rest of us combined :-)) -- John McNamee jpm@BNL.ARPA decvax!philabs!sbcs!bnl!jpm "Timesharing is the use of many people by a computer"
randy@umn-cs.UUCP (03/26/87)
In article <2473@felix.UUCP> zemon@felix.UUCP (Art Zemon) writes: >Why not give up on UUCP and write a replacement using the >Kermit protocol? Doing so wouldn't be much more work than >a small program which invokes C-Kermit instead of uucico >and Kermit really is public domain -- and well documented >and understood! >-- Just posted to net.sources was the source for John Gilmore's uuslave - a free software implementation of the uucico/uucp protocols. It will compile and run under BSD and SysV, so it shouldn't be too hard to port to minix (I'd do it if I had minix source yet, and the time to do it). The other programs in the uucp family are nowhere near as complicated, and should be easy to write from te manuals even. There's no barrier to using uucp on minix. -randy -- Randy Orrison, University of Minnesota Math Department (even though I'm a Computer Science major) UUCP: {ihnp4, ?}!umn-cs!randy ARPA: randy@cs.umn.arpa "Any opinions expressed are not necessarily irrelevant."
zemon@felix.UUCP (03/28/87)
In article <17638@ti-csl.CSNET> haddock@tilde.UUCP (Rusty Haddock) writes: >In article <2473@felix.UUCP> zemon@felix.UUCP (Art Zemon) writes: >> >>and Kermit really is public domain -- and well documented >> -- Art Zemon > >Someone correct me if I'm wrong but it is my belief that Kermit is >freely distributable but *NOT* Public Domain. > >Rusty Haddock +++ Texas Instruments, Inc. +++ Dallas, Texas 'Scuse me. You're right, I "mispoke." The point I was making is valid, however. It should be easy to write a UUCP replacement using the Kermit protocol, which is well documented and understood. The program could be given away for use under Minix. It probably wouldn't even be too hard to simply "exec" Kermit instead of uucico. -- Art Z. -- -- Art Zemon FileNet Corporation Costa Mesa, California ...!hplabs!felix!zemon
sl@van-bc.UUCP (03/29/87)
In article <73@bnl.UUCP> jpm@bnl.UUCP (John McNamee) writes: >>> ...THE SOURCE FOR UUCP HAS NO COPYRIGHT NOTICES IN IT... >> >> Up until very recently you never found a copyright notice in UNIX software. >> UNIX is not protected by copyright, but rather by trade secret. In your >> agreement with AT&T (or Western in the old days), you agreed not to >> divulge the UNIX source code nor information on how it operates. Despite >> the lack of copyright notices in UUCP, it is still AT&T proprietary. > >What about people who have obtained UNIX sources without ever being bound >by an AT&T license agreement? The site they got them from is in trouble, The sources I've seen contained no copyrights, but also contained no markings of any sort to indicate which of the thousands of AT&T Licenses they may have come from. Does AT&T have some insidious method of permuting each source file in an identifiable manner so that they can track down which sites have been careless about source control :-). What about those licenses that are no longer in business, the receiver comes in and auctions off all of those tapes at about $.50 each? He doesn't give a damm about what's on them. So I find it hard to beleive that AT&T is going to be able in most cases to do anything even if they do track down someone who has a copy. Just how many grad students do you know who have complete version 7, or BSD, or System III/V source tapes hidden away? Some trade secret huh. -- Stuart Lynne ihnp4!alberta!ubc-vision!van-bc!sl Vancouver,BC,604-937-7532
jack@mcvax.UUCP (03/30/87)
In article <2495@felix.UUCP> zemon@felix.UUCP (Art Zemon) writes: > >'Scuse me. You're right, I "mispoke." The point I was >making is valid, however. It should be easy to write a >UUCP replacement using the Kermit protocol, which is well >documented and understood. The program could be given away >for use under Minix. > At last! Someone who agrees with me! This is something I've been suggesting to numerous people the last couple of months, but the only result was a deafening silence. The point is, why should we use those icky uucp protocols that are hardly documented, and unused except in some proprietary sofware (forgetting uulink and uuslave, for the moment). The *only* things we need are a way to reach another system, and some way to get files across to it (with a reasonable guarantee that they will be the same after transmission:-). This is *exactly* what most kermits are doing nowadays. Kermit is available on any machine in the known universe, and if it isn't, it will be tomorrow. The rest of the processing after the files have been transferred, like mailing them off to where they should go, can be done by a 10 line shell script at best, and a 100-200 line C program at worst. Of course, you won't have sequence numbers and callback and all that stuff, but do you *really* care? Just restrict micros to sending mail, and that's all. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
paula@bcsaic.UUCP (03/31/87)
[Whoops, here it comes! Look Out! eeeeaaaaaAAAAGH! FLAME ON!] Has anyone besides myself become tired of reading this continuing discussion of whether or not it is OK to steal AT&T's trade secrets for use in minix? Really, people, there must be something more significant to talk about than trying to rationalize the theft of uucp! [FLAME OFF! Boy, did that feel good!] I would like to hear from people who are working on a tty driver for minix. I would also like to hear from folks who are working on getting minix to run on 808x machines that aren't compatible enough to run the distributed binaries. Has anybody got the floppies from Prentice-Hall yet? How 'bout it? Is anybody doing anything real out there? Paul ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Paul L. Allen | "Look out, men! He's armed!" Boeing Advanced Technology Center | "I've got a cheese grater, | and I'm not afraid to use it!" | "Don't make it any harder paula@boeing.com | on yourself, kid! Drop it!" ...!uw-beaver!ssc-vax!bcsaic!paula | "Eat mozzarella, copper!"
bc@njitsc1.UUCP (03/31/87)
In article <7319@boring.mcvax.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: > >The point is, why should we use those icky uucp protocols that are >hardly documented, and unused except in some proprietary sofware Because it is faster. Compare the transfer speeds of uucp and kermit: you only get about half your baud rate in kermit file transfers. uucp does better. Of course, the real problem is that kermit is still inefficient. (They said they were thinking of improving the protocol a couple of years ago. I wonder if anyone has worked on it...) And while you are looking for a protocol, how about using one that transmits files in both directions at the same time? There are many protocols that have solved this problem already. Actually, I use kermit quite often, and like it. But shouldn't a program that may be responsible for a lot of telephone use be as efficient as possible? Bill Cheswick uucp: bellcore!argus!njitsc1!bc New Jersey Inst. of Tech. ARPA: argus!njitsc1!bc@flash.bellcore.com bitnet: bc%argus.uucp at mouton.arpa"
kdj@se-sd.UUCP (03/31/87)
In article <7319@boring.mcvax.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: >In article <2495@felix.UUCP> zemon@felix.UUCP (Art Zemon) writes: >> >>'Scuse me. You're right, I "mispoke." The point I was >>making is valid, however. It should be easy to write a >>UUCP replacement using the Kermit protocol, which is well >>documented and understood. The program could be given away >>for use under Minix. >> >At last! Someone who agrees with me! > . . . > >The point is, why should we use those icky uucp protocols that are >hardly documented, and unused except in some proprietary sofware >(forgetting uulink and uuslave, for the moment). > >The *only* things we need are a way to reach another system, and some >way to get files across to it (with a reasonable guarantee that they >will be the same after transmission:-). > >-- > Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The point is that UUCP is already being used and what many people want is a way to communicate with what is already on systems. The commentary above makes it look like UUCP is only used in a few places and rather than thousands of Unix systems. I agree that kermit is a better solution but that is , in many cases, irrelevent. Doug Johnston kdj@se-sd.SanDiego.NCR.COM
levy@ttrdc.UUCP (04/01/87)
In article <7319@boring.mcvax.cwi.nl>, jack@mcvax.cwi.nl (Jack Jansen) writes: < The *only* things we need are a way to reach another system, and some < way to get files across to it (with a reasonable guarantee that they < will be the same after transmission:-). < < This is *exactly* what most kermits are doing nowadays. Can Kermit work auto-dialers and negotiate the login protocol? Also--does Kermit negotiate bad-data retry on a smaller scale than whole files? Just curious (I'm not a Kermit guru as you can plainly see). -- |------------dan levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an engihacker @ | vax135}!ttrdc!ttrda!levy | at&t computer systems division | Disclaimer: try datclaimer. |--------skokie, illinois--------|
mh@killer.UUCP (04/01/87)
While everyones waiting for their disks some background noise is to be expected. While you may be getting tired of it, remember that others may thrive on this poop...
jack@mcvax.UUCP (04/01/87)
In article <122@njitsc1.UUCP> bc@njitsc1.UUCP (Bill Cheswick) writes: >In article <7319@boring.mcvax.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: >> >>The point is, why should we use those icky uucp protocols that are >>hardly documented, and unused except in some proprietary sofware > >Because it is faster. Compare the transfer speeds of uucp and kermit: you only >get about half your baud rate in kermit file transfers. uucp does better. > If you only count the time uucp takes to transfer bytes, this is true. However, if you add the time taken to deposit files in the appropriate places, *which kermit does during conversation*, things get far worse. I'm not sure how fancy uucp's like honey-danber handle this, but one of the gross misfeatures of most uucp's is that they deliver files while they're still eating phone time. This, combined with the fact that, for small files, the overhead is enourmous (two files transmitted for each tiny mail message) makes me dislike uucp. Moreover, although I said kermit, you could as easily think of zmodem, or something else. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
blarson@castor.usc.edu.UUCP (04/02/87)
In article <122@njitsc1.UUCP> bc@njitsc1.UUCP (Bill Cheswick) writes: >In article <7319@boring.mcvax.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: >>The point is, why should we use those icky uucp protocols that are >>hardly documented, and unused except in some proprietary sofware > >Because it is faster. Compare the transfer speeds of uucp and kermit: you only >get about half your baud rate in kermit file transfers. uucp does better. Kermit with full duplex windows should aproach 75% effeciency on binary files, and about 95% on ascii text files. UUCP will do worse than windowing kermit on lines with high latency. (Satelite links, fast "9600 baud" half-duplex modems.) (Kermit can work with up to 32 outstanding acks, UUCP is 2 I think.) The large packet option of kermit will do better than that in some situations. >Of course, the real problem is that kermit is still inefficient. The problem is kermit was designed for enviornments present in the real world, and UUCP for an ideal world. Many unix administators have trouble trying to get UUCP to work through real-world modems, port selectors, multiplexors, etc. > (They said >they were thinking of improving the protocol a couple of years ago. I wonder >if anyone has worked on it...) The extentions you are talking about are called "full-duplex windows" and "large packets". Both are present in the most recent protocol manual, and there are implementations available from Columbia university. Unfortunatly, neither are in the Unix implementation C-Kermit yet. Of course, all correct kermit implementations should work with all others, whether any specific enhancement is present or not. >And while you are looking for a protocol, how about using one that transmits >files in both directions at the same time? There are many protocols that >have solved this problem already. I've thought of proposing such an extension to kermit. >Actually, I use kermit quite often, and like it. But shouldn't a program >that may be responsible for a lot of telephone use be as efficient as possible? As efficient as practical. Squeezing a few percent more out a phone conversation by limiting yourself to a single vendor for software is a trade-off that should be examined closly. People seriously interested in kermit can read the info-kermit digest on mod.protocols.kermit. Info-kermit-request@cu20b.columbia.edu can be contacted if you need an arpanet/bitnet subscription. There is also a book on kermit by Frank Da Cruz, I have not yet read it. Kermit is available via arpanet ftp, bitnet, uucp from okstate, and on tapes. The request address above should be willing to send the details if needed. -- Bob Larson Arpa: Blarson@Usc-Eclb.Arpa Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson seismo!cit-vax!usc-oberon!castor.usc.edu!blarson
apratt@atari.UUCP (04/02/87)
in article <1643@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) says: > > Can Kermit work auto-dialers and negotiate the login protocol? Also--does > Kermit negotiate bad-data retry on a smaller scale than whole files? Just > curious (I'm not a Kermit guru as you can plainly see). Kermit would not be called upon to negotiate logins: what people are talking about is placing Kermit at the file-transfer level rather than uucp. The login protocol layer would be the same in both cases. Kermit handles bad transmissions at the packet level; unfortunately, packets are only 94 data bytes long, with (I think) about 6 bytes overhead. Finally, Kermit is a window-of-one protocol, meaning that each packet must be ACKed or NAKed before the next one starts. The overhead of having short packets and many, long ACKs is bad enough, but with some 2400 and 9600-baud modems turnaround (from send mode to receive mode) takes as much as 1/2 second. Definitely bad news. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/
tim@ism780c.UUCP (04/04/87)
In article <2611@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
<> Once again, UNIX is protected by TRADE SECRET status. You may not divulge
<> the manner that UNIX works without being in violation of the agreement
<> you have with AT&T.
<
< Doesn't that mean that pretty much all of what is on unix-wizards
<is a violation of our license agreements? How many times have we seen
<somebody explain that X happens when you do Y because you zap the Z entry
<in the inode? If that's not divulging information about how Unix works
<internally, then I don't know what is.
Note that much of this information has been made public. For example,
there is that book that describes the internals of System V.2 and some
of V.3.
You should be safe talking about anything that has been already published.
--
Tim Smith "And if you want to be me, be me
uucp: sdcrdcf!ism780c!tim And if you want to be you, be you
Compuserve: 72257,3706 'Cause there's a million things to do
Delphi or GEnie: mnementh You know that there are"henry@utzoo.UUCP (Henry Spencer) (04/04/87)
> What about people who have obtained UNIX sources without ever being bound > by an AT&T license agreement? The site they got them from is in trouble, > but what legal action can AT&T take against the individual? (not that > anybody in their right mind would want to be the test case... My understanding [BEWARE, I am not a lawyer, consult an expert before doing anything rash!] is that much depends on how such a person came by those Unix sources. If he knew it was AT&T proprietary material, or if the proverbial "reasonable man" should have known this in his situation, he is in just as much trouble as the site he got it from. If he truly and reasonably thought the stuff wasn't proprietary -- hard to imagine for Unix stuff -- then he is theoretically blameless. (This doesn't mean he can't be sued, of course. It doesn't even mean that such a suit would fail. And even successfully fighting off an AT&T lawsuit would probably bankrupt most anyone.) I caution people once again to get professional advice before taking any action on the above informal amateur commentary. You're playing with fire. -- "We must choose: the stars or Henry Spencer @ U of Toronto Zoology the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (04/04/87)
> Does AT&T have some insidious method of permuting each source file in an > identifiable manner so that they can track down which sites have been > careless about source control :-). Don't laugh, I can think of some really insidious ways of doing this that nobody is ever likely to notice. Not on a file-by-file basis, but enough to trace an entire distribution or a major portion thereof. > What about those licenses that are no longer in business, the receiver comes > in and auctions off all of those tapes at about $.50 each? ... I think that if you look at your license, you will probably find clauses explicitly covering failure of business. Auctioning off those tapes without paying attention to the possibility of them containing proprietary software would be a rather dangerous thing to do. (Also a rather stupid thing -- stuff like customer lists can be very valuable, and don't think the creditors don't know it.) > Just how many grad students do you know who have complete version 7, or BSD, > or System III/V source tapes hidden away? Some trade secret huh. There are undoubtedly a *lot* of unauthorized copies of Unix stuff and even entire Unix distributions floating about. It just might be possible to win a court battle on the claim that AT&T has taken inadequate precautions and can no longer realistically class Unix as a secret. (Trade secret protection does require you to really treat the stuff as a secret, and take reasonable precautions to protect it.) However, I doubt that anybody short of IBM could possibly finance such a battle, since AT&T would almost certainly take a cost-is-no-object victory-at-any-price attitude to such a situation. -- "We must choose: the stars or Henry Spencer @ U of Toronto Zoology the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henry
jack@mcvax.UUCP (04/06/87)
In article <692@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >in article <1643@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) says: >> >> Can Kermit work auto-dialers and negotiate the login protocol? Also--does >> Kermit negotiate bad-data retry on a smaller scale than whole files? Just >> curious (I'm not a Kermit guru as you can plainly see). > >Kermit would not be called upon to negotiate logins: what people are >talking about is placing Kermit at the file-transfer level rather >than uucp. The login protocol layer would be the same in both cases. Well, no. I think I started this discussion, and my idea was to replace uucp *totally*. Or, rather than replacing it, providing an alternative. The point I tried to make in the original article is that implementing uucp on every other micro is a lot of work, while kermit is available, and quite a few kermits will already do things like auto-dailing and uucp-like scripts. So, the only thing you have to do is write two shell scripts, one to deposit outgoing mail into a spooling area, and another to empty the incoming spool area. Of course, on a big timesharing machine these programs will probably be 1000+ lines C programs, checking all sorts of access privileges, etc. but on your own micro, some simple shellscripts will be good enough. Now, you make sure that once in a while kermit is started, dials to the remote site, sends all files in the outgoing spool area to the remote side, grabs all files sitting in the remote outgoing spool area and deposits them in your incoming spool area, and start the second shell script. The files you transfer could be the client side of an SMTP conversation, for instance. As an example, for a micro with only one connection, the following script would be good enough for /bin/rmail: ( echo 'HELO <mysys.mydomain>' echo "MAIL FROM: <$USER@mysys.mydomain>" for i do echo "RCPT TO: <$i>" done echo "DATA" cat echo "QUIT" ) > /usr/spool/outgoing/tmp.$$ mv tmp.$$ msg.$$ Voila, you can send mail from your micro. Granted, a script for incoming mail is slightly more complex, but still less that 100 lines. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
mjranum@osiris.UUCP (04/12/87)
In article <7865@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > What about people who have obtained UNIX sources without ever being bound > > by an AT&T license agreement? The site they got them from is in trouble, > > but what legal action can AT&T take against the individual? (not that > > anybody in their right mind would want to be the test case... > > [...] is that much depends on how such a person came by those > Unix sources. If he knew it was AT&T proprietary material, or if the > proverbial "reasonable man" should have known this in his situation, he is > in just as much trouble as the site he got it from. You mean, for example, if I stumble across uucp source on a public-domain BBS in DC, and it has no copyright notices in it ? Then I call a buddy of mine who actually has AT&T source and there are no notices in that either ? Gee, and this actually happened to, er, my kid brother. That's why, some time ago, I made a fool of myself posting to the net, asking pointed questions. Don't worry, though, I have received a letter from AT&T's licensing department, informing me that uucp is covered under the trade secrets and is copyright. That pretty much settles that... As for the proverbial "reasonable man" - what a stupid concept ! Not only is that idea assuming that nobody has ever stood up in court and LIED but that is legally disenfranchising UNREASONABLE people like me !!! --mjr() ps - I also don't remember if I gave AT&T my home address. lordy knows where they got it. I expect they're gonna come kick in my . *#$ARRGH !!! Help !!.. aauugh ...>!>!>.. *(D.. -- fnordfnordfnordfnordfnordfnordfnordfnordfnordfnordfnordfnordfnordfnordfnord ? - decuac -- osiris!mjranum \__ gouldsd!mjranum