home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / HATCH / WWIVNEWS.ZIP / 9308_1.NWS < prev    next >
Text File  |  1993-08-04  |  28KB  |  491 lines

  1.                ┌┐┌┐┌┐┌┐┌┐┌┐┌────┐┌┐  ┌┐┌─┐ ┌┐┌────┐┌┐┌┐┌┐┌────┐
  2.  ╔═════════════││││││││││││└─┐┌─┘││  │││ └┐│││┌───┘│││││││┌───┘═════════════╗
  3.  ║   Volume 4  ││││││││││││  ││  └┼┐┌┼┘│  └┘││└───┐│││││││└───┐  June/July  ║
  4.  ║   Issue 2   ││││││││││││  ││   ││││ │┌┐  ││┌───┘││││││└───┐│    1993     ║
  5.  ╚═════════╤═══│└┘└┘││└┘└┘│┌─┘└─┐ └┼┼┘ ││└┐ ││└───┐│└┘└┘│┌───┘│═══╤═════════╝
  6.            │   └────┘└────┘└────┘  └┘  └┘ └─┘└────┘└────┘└────┘   │
  7.            │   The Electronic Forum for WWIVNet Sysops & Users!   │
  8.            └──────────────────────────────────────────────────────┘
  9.  
  10.                           ┌─────────────────────┐
  11.                           │This Issue's Features│
  12. ┌─────────────────────────┴─────────────────────┴───────────────────────────┐
  13. │ Random Factors...................................Wayne Bell (1@1)         │
  14. ├──────────────┬─────────────────────────────────────────────┬──────────────┤
  15. │              │    WWIVNews Feature Topic: The UU Debate    │              │
  16. │              └─────────────────────────────────────────────┘              │
  17. │ Introduction to the UU Debate....................Omega Man (1@5282)       │
  18. │                                                                           │
  19. │ Editorial Contributors...........................The Menace (1@4071)      │
  20. │                                                  Redman (1@16950)         │
  21. │                                                  Sleepy (1@3085)          │
  22. │                                                  Snorkel (1@3459)         │ 
  23. │                                                                           │
  24. │ Technical Contributors...........................Deltigar (1@1052)        │
  25. │                                                  Snorkel (1@3459)         │ 
  26. │                                                  Tolkien (1@3456)         │
  27. ├───────────────────────────────────────────────────────────────────────────┤
  28. │ Filo's Mod of the Month..........................Filo (1@2050)            │
  29. │                                                                           │
  30. │ Type 0 Forum.....................................Omega Man (1@5282)       │
  31. │                                                                           │
  32. │ WWIV-Compatible Networks List....................Red Dwarf (1@6264)       │
  33. │                                                                           │
  34. │ TechnOTES........................................WWIVNews Staff           │
  35. │                                                                           │
  36. │ Dateline: @#$*()#!...............................Omega Man (1@5282)       │
  37. └──────────────┬─────────────────────────────────────────────┬──────────────┘
  38.                └─────────────────────────────────────────────┘
  39.  
  40. ───────────────┬─────────────────────────────────────────────┬───────────────
  41.                │               Random Factors                │
  42.                │   Creative Commentary by Wayne Bell (1@1)   │
  43.                └─────────────────────────────────────────────┘
  44.  
  45. Quite a few things to discuss this issue, so let's get started:
  46.  
  47. NET33 BUG:
  48.  
  49. Yes, NET33 does have a bug where the 'BAD PW' SSM lops off the last digit of
  50. a node number. That's because i had strlen(s+1) instead of strlen(s)+1. This
  51. has been fixed for NET34, and the current one is still usable as an error flag
  52. If you see there's a bad PW, you can always look at NET.LOG and see which node
  53. is having connection problems.
  54.  
  55. NET34:
  56.  
  57. NET34 should have multiple nets in the same callout, although I haven't
  58. started coding that part of it yet. As usual, there have been a few minor bug
  59. fixes since net33. No major changes have been done yet, though. I (obviously)
  60. do not have a release date set yet.
  61.  
  62.  
  63. NEW DE1.EXE:
  64.  
  65. As most of you saw in the last mail_to_all_sysops, I've sent out a new
  66. DE1.EXE. (If you haven't installed it, then you won't be reading this.)This
  67. was sent as a UU encoded .ZIP file. To use this, you need to UUDecode it,
  68. unZip it, then overwrite your current WWIVNet DE1.EXE with this. You should no
  69. longer use the old DE1.EXE (the one in NET*.ZIP).
  70.  
  71. There have been those on some of the Sysop subs that have shown concern
  72. whether the UU'd file did in fact originate from @1, despite the source
  73. verification flags. If you're one of those who are still worried about this,
  74. take a look at the archive once you've decoded it. If PKZIP reports the CRC as
  75. 331fe474, then you have an authentic copy.
  76.  
  77. If you are in more than one network, make sure you overwrite the correct 
  78. DE1.EXE. Your DE1.EXE is probably in your WWIVNet data directory, or if not
  79. there, probably in your main WWIV directory.
  80.  
  81. This new DE1.EXE utilizes compression (PKWare Data Compression Library) to 
  82. reduce the size of net updates, and hopefully decrease network costs. This 
  83. also means it is slower than the older version.
  84.  
  85. An aside note to the AC's and GC's: Please make sure that new systems joining 
  86. the network receive this new DE1.EXE. It's also suggested that you make it 
  87. available for download by those sysops who are either unfamiliar or
  88. uncomfortable with the use of the UUDECODE procedures.
  89.  
  90.  
  91. WWIV v4.23:
  92.  
  93. WWIV v4.23 is being worked on now. No, I do not have a preliminary date set 
  94. for its release yet. I will let people know when a date is set, so please do 
  95. not email me to ask. Unlike previous releases, though, v4.23 will have some 
  96. significant portions of the new/upgraded code installed by other people. 
  97. Tolkien (@3456) has installed a number of new features, augmented existing 
  98. ones, and has made a lot of cosmetic changes. Jim Wire (@3950) is in the 
  99. process of installing multi-instance (multi-line) code, and that should be 
  100. being tested by the time this WWIVnews is released.
  101.  
  102. v4.23 already has multi-languages supported (although most of the code for
  103. that was in v4.22 also, and not many non-English language .str files are
  104. available yet). Shakespear (2@2050) is currently working on a FidoNet
  105. implementation, which should work more elegantly than existing interfaces
  106. (which require "fake" fidonet node numbers (@6xx)).
  107.  
  108.  
  109. UU'D FILES & WWIVNet:
  110.  
  111. As has been made clear in the mail-to-all-sysops before the one containing the
  112. DE1.EXE update, files should >NOT< be sent through WWIVNet, except if you have
  113. the permission of all intervening systems. This covers not only UUENCODEd 
  114. files, but also PACKSCAN files, and any other method that may pop up.
  115.  
  116. Yes, many times it may be convenient to use WWIVNet to send files to someone. 
  117. However, by sending them through the net, you make other people pay for your 
  118. convenience, which is not fair. If you have a need currently to send files to 
  119. someone on a continuing basis, the best way is to set up your own mini-
  120. network, and then send files (uuencoded or via PACKSCAN) on your own network.
  121. That leaves the convenience for you, does not cost other people anything, and
  122. will not end up routing normal WWIVNet traffic between your systems (as would
  123. be the case if you simply added a WWIVNet connection between systems). I know
  124. some systems in the St. Louis area have set up their own separate network for
  125. this very purpose.
  126.  
  127. Some people have complained to me about the no-file policy, saying things like
  128.  
  129. "But I already pay $xx a month for dues to the server."  Yes, but that is for 
  130. just ONE server. messages of any type on the net tend to go through many 
  131. intervening systems, not just the one server. Files also tend to be much
  132. larger than normal net traffic, and server dues are based upon normal traffic,
  133. not based upon the few people who want to send large files. In any case, in
  134. the relatively near future (no, no date yet), there will be an FREQ-type
  135. program available for WWIV systems, which will allow direct transfer 
  136. of files between WWIV systems, not using any network. This will end up being 
  137. (I believe) the most convenient method, and will limit the costs to those 
  138. actually doing file transfers.
  139.  
  140. Rules and policies regarding this matter will be covered in detail in the new 
  141. WWIVNet policy docs that will accompany the release of NET33.ZIP. Any
  142. questions regarding the FREQ utility should be directed to the author, 2@2050.
  143.  
  144.  
  145. REGISTRATION & MULTI-LINE WWIV:
  146.  
  147. Prior to this writing, I've received several E-Mails regarding the per-line 
  148. registration deal. I would like to take a somewhat more mellow attitude about 
  149. it right now, than what these people seem to think is the situation.
  150. Basically, explaining what the situation is, why changes are necessary, and
  151. what we're currently proposing, and why. This opposed to taking the attitude
  152. of "This is it, love it or leave it."
  153.  
  154. Previously, the license agreement has not explicitly addressed the issue of 
  155. running a multiple line WWIV, as until recently, it has only been possible to 
  156. run it on one line (and even so, not many people have been going multi-line 
  157. with it so far anyway). Since more and more people have become interested in 
  158. running multi-lines, and since v4.23 will probably support multiple lines, 
  159. obviously the license should be modified to explicitly address the multi-line 
  160. issue. That much, everyone should agree with.
  161.  
  162. The real issue, therefore, is in what way should multi-lines be handled (in
  163. the license)?
  164.  
  165. A long time ago, someone (I'm sure) wanted to run two WWIV's. Not multi-line, 
  166. but two separate BBS's. The question therefore came up, "Do I need one or two 
  167. registrations?"  If someone could run two BBS's with one registration, then it
  168. would also be possible for someone to say, "Yes, I run two BBS's - one at my 
  169. house, and one at my friend John's house" as a way to try to get John's BBS to
  170. count as registered for "free."  Also, other DOS-based licenses (eg, BC++) 
  171. don't work that way - the license is for one copy on one computer. In any 
  172. case, as I understand copyright law (and they just gave a big lecture at work 
  173. on this), the standard license is for one copy on one computer. Anything 
  174. beyond that has to be explicitly granted by the license agreement.
  175.  
  176. So, obviously, if someone was running two BBS's, he needed two registrations.
  177.  
  178. That "decision" also expanded when someone wanted to run two separate BBS's on
  179. the same computer (under DV, say). It therefore came to be "one registration 
  180. per phone line." I'm almost certain I've posted that on at least one sysop's 
  181. sub. 
  182.  
  183. Currently, that also applies to one person running a two-line BBS.
  184.  
  185. Yes, I agree that's not perfectly fair, but it's all I could come up with. If 
  186. I went with anything less restrictive than that, it would become possible for 
  187. people to 'cheat' on it (although I don't think most people would intend to do
  188. that).
  189.  
  190. "But," I hear people saying, "I can mod my BBS however I want, and I choose to
  191. mod it to handle multiple lines."  Actually, that's not accurate. What people 
  192. have done to handle multiple lines is modify the BBS so that multiple copies 
  193. can be running simultaneously, not that one copy can handle multiple lines 
  194. (that is, the difference between having one BBS.EXE running, and having more 
  195. than one BBS.EXE running). So, even though it is one computer handling two 
  196. phone lines, it is still two BBS.EXE's running at the same time. That's two 
  197. copies. Thus the need for two registrations.
  198.  
  199. Let me explain the difference there a bit more. Modifying your BBS to handle 
  200. multiple phone lines would mean that you would have one BBS.EXE running on
  201. your machine, which would have the multi-tasking code built into it, and it
  202. would be the same BBS.EXE that was handling all users (on the same CPU). What
  203. people have done is to have the BBS.EXE's lock files, and gracefully allow
  204. multiple BBS.EXE's to access the same files almost concurrently.
  205.  
  206.  
  207. Unfortunately, since DOS machines can typically handle only one user at a
  208. time, DOS people have never encountered real multi-user licenses. In other 
  209. environments (eg, UNIX, which is what I use at work), where multi-user
  210. machines are common, the typical licensing agreement is for a set number of
  211. concurrently running copies. For example, FrameMaker (a word-processor type
  212. program) has a "license server" program running on one machine in a network.
  213. Whenever a user (on that machine or on another) wants to run FrameMaker, their
  214. copy of FrameMaker gets a "license" from the license server. The server
  215. ensures that no more than the set number of licenses are active at a time. If
  216. you need to run more than that, then you pay more money for more licenses, and
  217. they send you a new keyfile or password to enable the greater number of
  218. licenses (the keyfile/password is based upon the machine name/serial-number/
  219. ethernet-address, to ensure that you don't use the same key/pass on more than
  220. one machine).
  221.  
  222. So, in response to all this, the WWIV license is being changed to be less 
  223. restrictive. Instead of having to have a separate registration for each phone 
  224. line, people will now be able to (legally) run a multi-line WWIV paying much 
  225. less than $80 per line.
  226.  
  227. Hopefully this clarifies matters a bit.
  228.  
  229.  
  230. UTILITY.WW4:
  231.  
  232. Finally, Filo (1@2050) is in the process of compiling a comprehensive list of
  233. utilities for WWIV, to be included in the documentation package. If you wish
  234. to have your utility (or utilities, as the case may be) the following
  235. information should be submitted:
  236.  
  237. FILENAME.EXT, Author's Name, ID, Description
  238.  
  239.    ^      ^       ^          ^   ^
  240.    :      :       :          :   :...Description MUST not be longer than
  241.    :      :       :          :       102 characters including spaces.
  242.    :      :       :          :       If it is available only at a fee
  243.    :      :       :          :       then include the fee in the
  244.    :      :       :          :       description.
  245.    :      :       :          :
  246.    :      :       :          :....... Use PD, SW, or CM as ID to
  247.    :      :       :                   indicate Public Domain, ShareWare
  248.    :      :       :                   or commercial.
  249.    :      :       :
  250.    :      :       :.................. Self Explanatory
  251.    :      :
  252.    :      :.......................... Type of Compression used
  253.    :
  254.    :................................. Filename used as identification
  255.  
  256. Submissions can be sent to the following addresses:
  257.  
  258. WWIVNet:  1@830 
  259. WWIVLink: WWIVNet #1 at 830 @2050
  260. IceNET:   WWIVNet #1 at 830 @2050
  261.  
  262. That's all for now. See you next issue.
  263.  
  264. ───────────────┬─────────────────────────────────────────────┬───────────────
  265.                │        Introduction To The UU Debate        │
  266.                │            by Omega Man (1@5282)            │
  267.                └─────────────────────────────────────────────┘
  268.  
  269. Transmission of UU encoded files over WWIVNet has been a topic of debate for
  270. as long as the net has been in operation. The arguments for and against the
  271. use of UU encoding have periodically turned sysop subs across the net into 
  272. heated flamefest arenas, producing lots of hurt feelings and very few real
  273. answers to the questions raised.
  274.  
  275. The questions raised were simple ones with complex answers. Was the UU method
  276. actually more efficient than a file request network relying on direct hookups?
  277. Were UU'd files containing archives actually larger than the archives by 
  278. themselves? Should text files be UU'd? Do servers and pass-through nodes have
  279. the right to scan network packets and purge UU'd files regardless of size or
  280. content? Does the WWIVNet as a whole have the responsibility to bear the 
  281. costs involved in sending such large files, or does it have the right to 
  282. take steps as a whole to prevent this perceived abuse of resources?
  283.  
  284. Oddly enough, while it appeared the majority of WWIVNet was against UU'd file
  285. transmissions, many of those opposed also expressed their doubts against any
  286. sort of absolute rule against their use. At the same time, those in favor of
  287. few or no controls on UU transmission were also some of the more outspoken and
  288. persuasive members of WWIVNet, and what they lacked in acceptance among their
  289. peers they made up for with tenacity and aggressiveness. 
  290.  
  291. In an effort to help present all sides of this serious issue, WWIVNews placed
  292. a Call for Articles on UU encoding. There were quite a few submissions for
  293. editorials, as well as several reviews and technical articles regarding the
  294. various utilities designed to manage - and even eliminate - network packets
  295. containing UU'd files.
  296.  
  297. However, as this issue was being compiled, WWIVNet 1@1 issued what can best be
  298.  
  299. described as "The Last Word" on UU transmissions. As a result, several of
  300. those who submitted editorials on this topic requested that their submissions
  301. be dropped from publication. The reason cited was the same in all cases: Wayne
  302. had rendered the debate a moot issue, and the forthcoming release of a File
  303. Request netutil simply added the final nail to the coffin.
  304.  
  305. Still, there were some views that were allowed to be expressed. The following
  306. editorials, technical papers, and product reviews are the remainder of the
  307. 30+ submissions on this topic. While the matter has arguably been settled,
  308. for future reference the WWIVNews staff came to the consensus to publish the
  309. remaining submissions, as presented below.
  310.  
  311. ─────────────────────────────────────────────────────────────────────────────
  312. The Menace (WWIVNet 1@4071) 
  313. ─────────────────────────────────────────────────────────────────────────────
  314.  
  315. As of late there has been a controversy concerning UUENCODED files being
  316. transferred across WWIVNet. A UUENCODED file (UUE) is coded with a special
  317. program called UUENCODE, a program common to the UNIX world. By UUE'ing a
  318. file, WWIVNet is capable of sending it across the network as a message. This
  319. encoding is done since WWIVNet and WWIV itself, does not have the capability
  320. of transferring files between nodes of the network. Upon receipt of this
  321. encoded file, you would use UUDECODE to transform it back to it's original
  322. usable/readable state.
  323.  
  324. The issue seems to reside in the cost of the network connects. When these UUE
  325. files are transferred across the network, and distributed amongst the some
  326. 5000 BBS's in WWIVNet, each system must endure the extra cost and time, in
  327. addition to the normal cost associated with a normal network transfer. This
  328. issue may not seem like a concern to many, but there are those who abuse the
  329. freedom that WWIVNet offers. Occasionally sending a UUE file is not the issue,
  330. it is the constant transfer of packets containing large UUENCODED files
  331. created by rather lazy users. Most of these Sysops are accepting the increase
  332. in phone charges without a charge to the users. Most Sysops start a BBS
  333. because it is fun, and the idea behind WWIVNet was the free flow of
  334. information. These UUENCODED files in net packets, increase the cost of
  335. running a BBS and are tarnishing the charm of being "networked".
  336.  
  337. In addition, some users and/or Sysops have been sending Non-Public Domain
  338. files (NPD) across the net in a UUE fashion. This exchange of illegal files is
  339. somewhat alarming to the Sysops who do not wish to associated with that part
  340. of BBS'ing community. The possibility of legal action being taken against a
  341. sysop on a network who has packets containing NPD software could be a major
  342. detraction to those that only wish to use the network as a message medium.
  343.  
  344. A few users have compared WWIVNet to FidoNet, where files from other sites are
  345. allowed to be transferred and housed by your system. WWIVNet is a different
  346. medium all together. That feature was built into FidoNet by its creator, not
  347. much unlike the way it was left out by the creator of WWIV. Wayne wanted a
  348. message based BBS to exchange ideas and information, not files.
  349.  
  350. My opinion, although it will probably anger many, is to come up with a simple
  351. across-the-board policy/standard. I think we should disallow ALL UUENCODED
  352. files from being transferred across WWIVNet. I feel that we can not compare
  353. apples to oranges anymore. We must decided together what the policy for the
  354. network is. In this decision, there should be fair consideration to all, no
  355. matter who they are or for what reasons they run their BBS. This approach
  356. seems fairest to everyone involved. 
  357.  
  358. I have heard talk of a feature in an upcoming release of WWIV, where you would
  359. be able to send a file directly to another node by aid of the BBS list. This
  360. way the cost would be incurred directly to the system who intends to send the
  361. file. This seems to be a wise solution, if it is possible to implement. The
  362. Sysop of the originating system could be notified about the file for transfer,
  363. and have final say as to whether he should let the file be transferred
  364. directly to the intended receiver node. Much like the NET VALIDATION option in
  365. the netted WWIV subs, this would help sysops to regulate the network into an
  366. orderly manner for all, yet maintain a high degree of fairness. Sysops would
  367. have a say in how their systems would be used....
  368.  
  369. ─────────────────────────────────────────────────────────────────────────────
  370. Sleepy (1@3085)
  371. ─────────────────────────────────────────────────────────────────────────────
  372.  
  373. There has been more than enough discussion on the transfer of UU'd files
  374. across WWIVnet. It seems to me that some of the more obvious (not to mention
  375. Important) reasons against them have been completely ignored. That is what
  376. prompted me to offer my opinion for everyone to read. One more thought before
  377. I get to it, please remember that this is only my opinion, backed up with a
  378. few facts that are available to all WWIVnet SysOp's, the only thing I did was
  379. Read The Docs...
  380.  
  381. Here is a partial quote from the WWIVNET.DOC Introduction, which *everyone*
  382. should have read. This quote maybe considered superfluous by a lot of you
  383. however, everything and everyone *Must* start somewhere. 
  384.  
  385. "WWIVnet is a voluntary association of bulletin boards using WWIV software,
  386. and participating in a network by calling one another to facilitate the
  387. transfer of electronic mail (e-mail) and message bases (subs)..."
  388.  
  389. "Through this network, a user of any of the bulletin boards that are members
  390. may send e-mail to a user of any other board. A User may also post on a
  391. message base which may be read by the users of systems which subscribe to that
  392. message base;...Because this system of Communication  read by others and
  393. because it has an effect on systems other than the one on which it originates,
  394. a spirit of cooperation must prevail. Out of this spirit grows a system of
  395. organization and regulation which are discussed in the pages that follow."
  396.  
  397. After reading the above documentation there is only one intelligent  
  398. interpretation:  Data (be it messages or files) transferred on WWIVnet *MUST*
  399. be WWIVnet Message Subs posts or WWIVnet e-mail. IMHO if nothing else common
  400. sense should have turned a light on somewhere. 
  401.  
  402. Since we are all only human, and as such have responsibilities, some with
  403. families, but all with the same feelings that are too often hurt. We should be
  404. able to afford one another common courtesy. Common Courtesy is easily given
  405. and should be extended to everyone in the same manner and
  406.  
  407. degree that we should all like to expect to receive. I don't run up your phone
  408. bill so don't you run up mine. We have all agreed to incur the costs necessary
  409. to transfer WWIVnet to and from our connects, some connects are fortunate
  410. enough to be local to one another. But there are some out there that must pay
  411. to transfer their packets.
  412.  
  413. I don't mean to sound condescending, I honestly believe that all of us were
  414. taught manners by our parents. Everyone wants to be liked and wants to like
  415. everyone in return. However when Joe Blow on AbracadrabraNet will send
  416. anything and everything over his network, that does not mean that Wayne Bell
  417. allows the same. What matters is what is fair. Plain and simple, you don't use
  418. Sally's phone to do Sam's business nor can you expect others to incur charges
  419. for something that has nothing to do with what they are interested in. Would
  420. you pay for you neighbor's newspaper, say the daily East Palooka Extra?  Oh
  421. that isn't the newspaper that you wanted to read?  So sorry, but it is already
  422. here so what can you do???
  423. It is impossible to run a board without expecting it to cost money. But the
  424. normal expenses are high enough without having to pay for another board's
  425. interest in a network that you have no interest in. And saying that sending
  426. "Mod" files is not fair because other files cannot be sent is completely
  427. unfair. The "Mod" files that are sent are for a Message base (which is in the
  428. Documentation as legit data) and the majority of SysOp's in WWIVnet do benefit
  429. from the Mods.
  430.  
  431. I truly believe the whole UU'd discussion took place only because the file's
  432. being sent could be considered "unsolicited junkmail". I'm not calling
  433. anyone's Network Junk...I along with I'm sure 99% of the other WWIV SysOp's,
  434. don't begrudge success to anyone in any project they wish to pursue. We just
  435. don't want to foot the bill. Most of us have already agreed that we don't what
  436. unsolicited e-mail, so the same would (IMHO) be true of files that have
  437. nothing to do with WWIVnet.
  438.  
  439. Although I do not believe that UU'd files should be completely banned, but
  440. once the guidelines are abused the abuse will continue. Most of the SysOp's
  441. that I know fairly well have no problems with WWIVnet files being UU'd and
  442. sent. If someone wants a file bad enough they should pay for it. Whether they
  443. are paying for a Commercial file or for the toll charges for a Shareware
  444. download.
  445.  
  446. We should all care about each other's feelings, boards and pocket's. We are
  447. all in it for the same reason....FUN!  We know just how hard we all have to
  448. work at keeping our boards running. Have a little respect for your fellow
  449. SysOp's and you'll get a lot in return.
  450.  
  451.  
  452. ─────────────────────────────────────────────────────────────────────────────
  453. Redman (1@16950)
  454. ─────────────────────────────────────────────────────────────────────────────
  455.  
  456. The practice of sending a UUE of your net package through another net is not
  457. a very good idea. This is not a practice that other nets should follow. To
  458. start with there was a reason for your starting your own network. And I am
  459. sure that one of the reasons was that you felt you had something better to
  460. offer.
  461.  
  462. Therefore, having started your own net, it would only be proper that you do
  463. not send your net startup package, nor updates through another net. In my
  464. opinion you should either call that board or have the board that wants to
  465. join, call your board for the package. But to send a UUE of your net package
  466. for any reason is not right.
  467.  
  468. I am sure that there is a reason for the UUE's. Otherwise the program would
  469. not have been made. But to use it for one network to send your net package
  470. over another network (Even if it is just one {this time}) is not right. You
  471. and I both know that it is not a 1 time thing. I am sure that many updates
  472. (startup) packages are being sent.
  473.  
  474. I am the AC of DEADnet and I WILL NOT SEND the initial package or even an
  475. upgrade on someone else's network. Other networks were set up (more then
  476. likely) because WWIVnet did not quite suit your needs. Therefore you MUST be
  477. obligated to either a) pay for calling the board that wants to join your net,
  478. or b) have them call you. Seams BLACK AND WHITE. Reason being that I would not
  479. want another network to be sending their updates or start up packages through
  480. my net. 
  481.  
  482. Look at it this way, those that have set up nets did so with the understanding
  483. that their net would be used for their net, not for other networks. Would you
  484. like to set up a net and have other networks tieing up all of your members
  485. boards sending their network through yours? I do not think so!
  486.  
  487. And to think that you can send it in UUE and then complain because it was
  488. deleted is moronic. It plainly states in the doc's that UUE's are allowed for
  489. the MOD sub ONLY. Reasoning behind this was so that those that program would
  490. be able to send ( small ) exe's and com's in a mod. Plus the big boys of WWIV
  491.