home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / bugs / 4bsd / ucbfixe / 3 next >
Encoding:
Internet Message Format  |  1992-09-03  |  27.6 KB

  1. Path: sparky!uunet!cis.ohio-state.edu!ucbvax!VANGOGH.CS.BERKELEY.EDU!bostic
  2. From: bostic@VANGOGH.CS.BERKELEY.EDU (Keith Bostic)
  3. Newsgroups: comp.bugs.4bsd.ucb-fixes
  4. Subject: V1.97 (4.4BSD-Alpha Release)
  5. Message-ID: <9209032321.AA17257@vangogh.CS.Berkeley.EDU>
  6. Date: 3 Sep 92 23:21:46 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: University of California at Berkeley
  10. Lines: 572
  11. Approved: ucb-fixes@okeeffe.berkeley.edu
  12.  
  13. Subject: 4.4BSD-Alpha Release
  14.  
  15. We would like to announce the availability of the 4.4BSD-Alpha
  16. distribution.  The attached is the cover letter from the
  17. information packet which has been sent to 4BSD licensees.  To
  18. request an order form, please contact our distribution office
  19. by phone at 415-642-7780, by email at bsd-dist@cs.berkeley.edu,
  20. or by U.S. Mail at:
  21.  
  22.     CSRG
  23.     Department of EECS
  24.     University of California
  25.     Berkeley, CA  94720
  26.  
  27. Kirk McKusick
  28. Keith Bostic
  29.  
  30.  
  31. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  32.  
  33.                                                 July 7, 1992
  34.  
  35. Dear Colleague:
  36.  
  37.  
  38.      We are happy to send you  information  about  our  June
  39. 1992  release  of 4.4BSD-alpha.  This release represents our
  40. expectations for the final interfaces that will  be  present
  41. in  4.4BSD.  Our goal in making this release available is to
  42. get feedback on any problems in the design or implementation
  43. of  the  new  facilities,  and to allow adventurous sites to
  44. gain experience with the new interfaces in 4.4BSD.
  45.  
  46.      This distribution is NOT intended to be used on produc-
  47. tion  systems;  nor  is it intended for sites without enough
  48. local expertise to  find  and  fix  any  problems  that  are
  49. encountered.   It  is  intended  to  be  used  to provide an
  50. advance look at some of the facilities and  interfaces  that
  51. we  will  be  distributing  in 4.4BSD.  We are interested in
  52. getting feedback on the problems that you find and also  any
  53. compatibility problems that you encounter in converting your
  54. applications to run on this release.  While we hope that the
  55. interfaces  in this release will not change before the final
  56. release of 4.4BSD, we will make changes  that  we  feel  are
  57. necessary  to  fix  problems  that  arise  during  the alpha
  58. release period (at least in part based on feedback from this
  59. test  group).  Where possible, we will minimize changes that
  60. will break applications ported to this release.  The code in
  61. this  distribution may be redistributed and used in released
  62. products.  However, you are strongly encouraged  to  upgrade
  63. any  code  that  you  use  from  this  distribution  to  the
  64. similarly-licensed distribution of the  4.4BSD  code  within
  65. one year of its release.
  66.  
  67.      Only limited support can  be  provided  by  our  group.
  68. Specifically,  we  cannot  provide help with installation of
  69. this software on other systems, although we are, of  course,
  70. interested in hearing of problems that you encounter.
  71.  
  72.      We are  planning  on  releasing  two  versions  of  the
  73. software,  4.4BSD-Encumbered  and  4.4BSD-Lite.  The 4.4BSD-
  74. Encumbered distribution is  available  only  to  sites  with
  75. UNIX/32V,  System III, or  System  V  source  licenses  with
  76. USL/AT&T.   The 4.4BSD-Encumbered distribution is a complete
  77. distribution in the style of 4.3BSD and  contains  the  com-
  78. plete source for the Berkeley Distribution.
  79.  
  80.      The 4.4BSD-Lite distribution  will  be  a  distribution
  81. that is copyrighted by the University of California and oth-
  82. ers, but may be freely redistributed.  It will be  available
  83. to  anyone  and  requires  no  previous license, either from
  84. USL/AT&T or The Regents of  the  University  of  California.
  85. Its license agreement and content will be similar to that of
  86. the two BSD Networking Releases.  The 4.4BSD-Lite  distribu-
  87. tion  will  contain  only  a  few additional programs and no
  88. additional kernel files from the Second  Networking  release
  89. done  in  June  1991.   However, it will contain support for
  90. additional architectures and will have many  bug  fixes  and
  91. performance  enhancements.   The  distribution  will include
  92. both  software  developed  at  Berkeley  and  also  much  of
  93. software contributed by authors outside Berkeley.
  94.  
  95.      Only the 4.4BSD-Encumbered distribution is available at
  96. this time.  The 4.4BSD-Lite distribution is not available at
  97. this time; we will send out a mailing to notify you when  it
  98. is available.
  99.  
  100.      The enclosed information is designed to serve two  pur-
  101. poses.   The  first  purpose  is  to  acquaint  you with the
  102. details of our distribution so you can  decide  whether  you
  103. would like to receive it.  The second purpose is to tell you
  104. how to obtain our distribution.
  105.  
  106. What is 4.4BSD?
  107.  
  108.      This software distribution is provided on  one  6250bpi
  109. 1/2''  9-track  tape  or one 8mm Exabyte cassette only.  The
  110. 4.4BSD-Encumbered distribution contains complete  source  as
  111. well  as binaries for the HP9000/300 series of workstations.
  112. The 4.4BSD-Lite distribution will contain only freely redis-
  113. tributable  sources.   As the sources do not comprise a com-
  114. plete system, no binaries will be included.
  115.  
  116.      The architectures that are supported include:
  117.  
  118. +    HP 9000/300 68000-based workstations
  119.  
  120. +    Intel 386/486-based machines (ISA/AT or EISA bus only)
  121.  
  122. +    Sony News MIPS-based workstations
  123.  
  124. +    Omron Luna 68000-based workstations
  125.  
  126. +    DECstation 3100 and 5000 MIPS-based workstations
  127.  
  128. +    Sparcstation I & II SPARC-based workstations
  129.  
  130. The distribution does not include the  machine  support  for
  131. the  Tahoe  and VAX architectures found in previous BSD dis-
  132. tributions.  Our primary development is  on  the  HP9000/300
  133. series   machines.    The   other  architectures  are  being
  134. developed and supported by people  outside  the  university.
  135. Consequently,  we  are not able to directly test or maintain
  136. these  other  architectures,  so  cannot  comment  on  their
  137. robustness, reliability, or completeness.
  138.  
  139.      The  major  new  facilities  available  in  the  4.4BSD
  140. release  are  a  new virtual memory system, a log-structured
  141. filesystem, enhancement of the local filesystems to  support
  142. files and filesystems that are up to 2^63 bytes in size, the
  143. addition of ISO/OSI networking support, a  freely  redistri-
  144. butable  implementation  of  NFS,  and the conversion to and
  145. addition of the IEEE Std1003.1  (``POSIX'')  facilities  and
  146. many  of  the  IEEE Std1003.2 facilities.  In addition, many
  147. new utilities and additions to the C library are present  as
  148. well.   The  kernel sources have been reorganized to collect
  149. all machine-dependent files for each architecture under  one
  150. directory,  and  most of the machine-independent code is now
  151. free of code conditional on  specific  machines.   The  user
  152. structure  and  process  structure  have been reorganized to
  153. eliminate the statically-mapped user structure and  to  make
  154. most   of   the  process  resources  shareable  by  multiple
  155. processes.  The system and include files have been converted
  156. to  be compatible with ANSI C, including function prototypes
  157. for most of the  exported  functions.   There  are  numerous
  158. other changes throughout the system.
  159.  
  160.      The new virtual memory implementation is  derived  from
  161. the  MACH operating system developed at Carnegie-Mellon, and
  162. was ported to the BSD kernel at the University of Utah.  The
  163. MACH  virtual memory system call interface has been replaced
  164. with the ``mmap''-based interface described in the  ``Berke-
  165. ley  Software  Architecture  Manual'' (see UNIX Programmer's
  166. Manual, Supplementary Documents, PS1:6).  The  interface  is
  167. similar to the interfaces shipped by several commercial ven-
  168. dors such as Sun, Convex Computer Corp.  and USL/AT&T.   The
  169. integration  of  the new virtual memory is functionally com-
  170. plete, but still  has  serious  performance  problems  under
  171. heavy  memory load.  The internal kernel interfaces have not
  172. yet been completed and the memory pool and buffer cache have
  173. not  yet  been  merged.   Some of these changes are expected
  174. before the release of 4.4BSD.
  175.  
  176.      The ISO/OSI Networking consists of a kernel implementa-
  177. tion  of transport class 4 (TP-4), connectionless networking
  178. protocol  (CLNP),   and   802.3-based   link-level   support
  179. (hardware-compatible with Ethernet*).  We also include  sup-
  180. port  for ISO Connection-Oriented Network Service, X.25, TP-
  181. 0.  The session and presentation layers are provided outside
  182. the  kernel  by  the  ISO  development  environment (ISODE).
  183. Included in this development environment are  file  transfer
  184. and  management  (FTAM), virtual terminals (VT), a directory
  185. services implementation  (X.500),  and  miscellaneous  other
  186. utilities.
  187.  
  188.      A new virtual filesystem interface has  been  added  to
  189. the  kernel  to support multiple filesystems.  In comparison
  190. with other  interfaces,  the  Berkeley  interface  has  been
  191. structured  for  more  efficient support of filesystems that
  192. maintain state (such as the local filesystem).   The  inter-
  193. face  has  been extended with support for stackable filesys-
  194. tems done at UCLA.  These extensions allow  for  filesystems
  195. to  be  layered  on  top  of  each other and allow new vnode
  196. operations to be added without requiring changes to existing
  197. filesystem implementations.
  198.  
  199.      In addition to the local ``fast filesystem'',  we  have
  200. added an implementation of the network filesystem (NFS) that
  201. fully interoperates with the NFS  shipped  by  Sun  and  its
  202. licensees.   Because  our NFS implementation was implemented
  203. using only the publicly available NFS specification, it does
  204. not  require  a  license from Sun to use in source or binary
  205. form.  By default it runs over UDP  to  be  compatible  with
  206. Sun's  implementation.   However,  it can be configured on a
  207. per-mount basis to run over TCP.  Using TCP allows it to  be
  208. used  quickly  and  efficiently  through  gateways  and over
  209. long-haul networks.  Using an extended protocol, it supports
  210. Leases  to  allow  a limited callback mechanism that greatly
  211. reduces the network traffic necessary to maintain cache con-
  212. sistency between the server and its clients.
  213.  
  214.      A new log-structured filesystem  has  been  added  that
  215. provides near disk-speed output and fast crash recovery.  It
  216. is still experimental in the alpha release, though  we  hope
  217. to  have  enough experience with it to recommend it for pro-
  218. duction use by the time of the  final  4.4BSD  release.   We
  219. have also added a memory-based filesystem that runs in page-
  220. able memory, allowing large  temporary  filesystems  without
  221. requiring dedicated physical memory.
  222.  
  223.      The quota system has been  rewritten  to  support  both
  224. user  and  group  quotas (simultaneously if desired).  Quota
  225. expiration is based on time rather than the previous  metric
  226. of  number  of  logins over quota.  This change makes quotas
  227. more useful on fileservers onto which users seldom login.
  228.  
  229.      The 4.4BSD distribution contains most of the interfaces
  230. specified  in  the IEEE Std1003.1 system interface standard.
  231. The biggest area of change is a new  terminal  driver.   The
  232. terminal  driver  is similar to the System V terminal driver
  233. with the addition of the necessary  extensions  to  get  the
  234. functionality  previously  available  in the 4.3BSD terminal
  235. driver.  4.4BSD also adds the  IEEE  Std1003.1  job  control
  236. interface, which is similar to the 4.3BSD job control inter-
  237. face, but adds a security model  that  was  missing  in  the
  238. 4.3BSD  job control implementation.  Other additions include
  239. IEEE Std1003.1 signals, FIFOs, byte-range file locking,  and
  240. saved user and group identifiers.
  241.  
  242.      There are several new tools and utilities  included  in
  243. this  release.  A new version of make allows much-simplified
  244. makefiles for the system software and allows compilation for
  245. multiple  architectures from the same source tree (which may
  246. be mounted read-only).  Notable additions to  the  libraries
  247. include  functions to traverse a filesystem hierarchy, data-
  248. base interfaces to btree and hashing functions, a new,  fast
  249. implementation  of  stdio  and  a  radix sort function.  The
  250. additions to the utility suite include greatly enhanced ver-
  251. sions  of  programs  that display system status information,
  252. implementations of various traditional  tools  described  in
  253. the IEEE Std1003.2 standard, and many others.
  254.  
  255.      We have been tracking  the  IEEE  Std1003.2  shell  and
  256. utility  work  and  have  included prototypes of many of the
  257. proposed utilities.  Because most of the traditional  utili-
  258. ties  have  been replaced with implementations conformant to
  259. the POSIX standards, you should  realize  that  the  utility
  260. software  may  not be as stable, reliable or well documented
  261. as in traditional Berkeley releases.  In particular,  almost
  262. the  entire  manual  suite  has  been rewritten to be freely
  263. redistributable  and,  in  many  instances,  it   does   not
  264. correctly  reflect the current state of the software.  It is
  265. also worth noting that, in rewriting this software, we  have
  266. generally   been   rewarded   with  significant  performance
  267. improvements.  Most of the libraries and header  files  have
  268. been  converted  to  be  compliant with ANSI C.  The default
  269. compiler (gcc) is a superset of ANSI C, but supports  tradi-
  270. tional C as a command-line option.  The system libraries and
  271. utilities all compile with either ANSI or traditional C.
  272.  
  273.      Work  has  also  progressed  in  several  other  areas.
  274. Several important enhancements have been added to the TCP/IP
  275. protocols including TCP header prediction and serial line IP
  276. (SLIP)  with header compression.  The routing implementation
  277. has been completely rewritten to use a hierarchical  routing
  278. tree  with  a mask per route to support the arbitrary levels
  279. of routing found in the ISO protocols.   The  routing  table
  280. also  stores  and  caches route characteristics to speed the
  281. adaptation of the throughput and congestion avoidance  algo-
  282. rithms.
  283.  
  284.      The Kerberos (version 4)  authentication  software  has
  285. been  integrated  into much of the system (including NFS) to
  286. provide the first real network authentication on BSD.
  287.  
  288.      This release includes several important structural ker-
  289. nel  changes.   The  kernel  uses a new internal system call
  290. convention; the use  of  global  (``u-dot'')  variables  for
  291. parameters and error returns has been eliminated, and inter-
  292. rupted system calls no longer abort using  non-local  goto's
  293. (longjmp's).   A  new  sleep interface separates signal han-
  294. dling from  scheduling  priority,  returning  characteristic
  295. errors  to  abort  or restart the current system call.  This
  296. sleep call also  passes  a  string  describing  the  process
  297. state,  which  is  used by the ps(1) program.  The old sleep
  298. interface can be used  only  for  non-interruptible  sleeps.
  299. The  sleep  interface  (tsleep) can be used at any priority,
  300. but is only interruptible if the PCATCH flag is  set.   When
  301. interrupted, tsleep returns EINTR or ERESTART.
  302.  
  303.      Many data structures that  were  previously  statically
  304. allocated  are  now allocated dynamically.  These structures
  305. include mount entries, file entries, user open file descrip-
  306. tors,  the process entries, the vnode table, the name cache,
  307. and the quota structures.
  308.  
  309. The End of BSD from Berkeley
  310.  
  311.      As you may already have heard, the CSRG is going to  go
  312. away  after  the final release of 4.4BSD.  For the following
  313. reasons, clearly the CSRG cannot  continue  in  its  present
  314. form.
  315.  
  316.      Funding has become increasingly time-consuming and dif-
  317. ficult.  We are spending more and more of our time obtaining
  318. funding, time that we would prefer to spend working on  BSD.
  319. As  many  of you are intimately aware, computer corporations
  320. are actively seeking ways to reduce  discretionary  outlays.
  321. Also,  as  UNIX  vendors  have  developed their own research
  322. groups, the work of the CSRG has become  less  necessary  to
  323. them.    Finally,  making  BSD  freely  redistributable  has
  324. resulted in fewer distributions sold, as other organizations
  325. sell our releases for less money.
  326.  
  327.      Support  within  the  University  of   California   has
  328. declined  as  BSD  has  become  less widely used internally.
  329. Victims of our own success, many of the features once  found
  330. only in BSD are now available from every vendor.
  331.  
  332.      The system has become too large and complex for a group
  333. of  four  to  architect and maintain.  In particular, losing
  334. Mike Karels has made it obvious to  us  that  the  group  is
  335. below  critical  mass for developing and distributing a com-
  336. plete UNIX system.
  337.  
  338.      We are making the 4.4BSD-alpha  distribution  available
  339. now.   We  will  spend  the summer and some part of the fall
  340. cleaning up the release and make the  final  4.4BSD  release
  341. available  in  the  fall.  When the final release happens is
  342. mostly dependent on when our current funding runs  out.   At
  343. that  time  we  will  close down the group.  We would really
  344. like to have six months to finish up 4.4BSD.  The amount  of
  345. time  that  we  get is largely a function of how many of you
  346. purchase the alpha distribution.  So, if you are planning to
  347. get  4.4BSD  when  it  comes  out, please consider buying an
  348. alpha distribution with an upgrade option instead.  That way
  349. your money will go to support the final 4.4BSD release.
  350.  
  351.      BSD has always been a community effort, and, as a  com-
  352. munity  effort,  does not rely on a small group of people in
  353. Berkeley to keep it going.  BSD will not go away,  but  will
  354. live  on through the free software and commercial efforts of
  355. many people.  We thank you for your support over the  years,
  356. your  funding,  and,  of course, the software you've contri-
  357. buted to make the BSD system what it is today!
  358.  
  359. How to obtain 4.4BSD-Encumbered
  360.  
  361.      To obtain 4.4BSD-Encumbered we require execution of the
  362. Berkeley  License  Agreement  (6/92).   In addition, foreign
  363. licensees must  execute  Addendum  Number  One  for  Foreign
  364. Licensees   in   ordering  4.4BSD-Encumbered.   The  fee  is
  365. $2000.00 for 4.4BSD-Encumbered.
  366.  
  367.      Because we are a research and development  organization
  368. and  not  a  commercial  organization,  we make our research
  369. results available for a small license  fee.   We  distribute
  370. only  the  whole system ``As Is'' and cannot send individual
  371. pieces of the system.  We are required by the University  of
  372. California  to  have  a formal license arrangement with each
  373. organization to which we distribute. All  material  is  con-
  374. sidered  licensed  material  regardless  of its availability
  375. from other sources that make such material  publicly  avail-
  376. able.   In  addition, for 4.4BSD-Encumbered, we are required
  377. to secure a copy of the AT&T Software  Agreement  with  your
  378. organization  and  confirm  it with AT&T before the software
  379. can be shipped.
  380.  
  381.      Specifically, for 4.4BSD-Encumbered,  we  must  receive
  382. from  your  organization  the  following material before the
  383. distribution can be sent:
  384.  
  385. +    Two copies of the current  Software  Agreement  between
  386.      your company or institution and AT&T (Western Electric)
  387.      that authorize you as a source licensee  for  UNIX/32V,
  388.      System  III, or System V.  Note that a complete copy of
  389.      the agreement up to the Schedule is required, not  just
  390.      the  cover  and/or signature page.  Letters authorizing
  391.      additional CPUs are  not  necessary  in  this  process;
  392.      however,  it  is your legal responsibility to obtain an
  393.      additional CPU authorization from AT&T.
  394.  
  395. +    Two original signed and executed copies of the Berkeley
  396.      License Agreement (6/92) between your company or insti-
  397.      tution and The Regents of the University of  California
  398.      along  with Exhibit A properly filled out.  For Foreign
  399.      licensees, there is an Addendum to the  License  Agree-
  400.      ment  that  must  also  be  executed.   The name of the
  401.      organization on the Berkeley License Agreement must  be
  402.      the  same  as that which appears on the Software Agree-
  403.      ment with AT&T (or  Western  Electric).   The  Berkeley
  404.      License  Agreement  (6/92)  must  be  signed  by a duly
  405.      authorized person who holds a position that is  at  the
  406.      same level or a higher level of authority as that which
  407.      appears on the AT&T  Software  Agreement.  Please  have
  408.      this  person's  name  and  title typed in the available
  409.      space in  addition  to  the  signature.   This  license
  410.      agreement  applies  to  all  the  CPUs  covered  by the
  411.      Software Agreement with AT&T (or Western Electric) that
  412.      you  have  provided.   One  signed copy of the Berkeley
  413.      License Agreement will be returned to you after it  has
  414.      been executed by The Regents of the University of Cali-
  415.      fornia.
  416.  
  417. +    A check from a U.S. bank for $2000.00 must be  received
  418.      before  the distribution can be sent.  Checks should be
  419.      made payable to ``The Regents of the University of Cal-
  420.      ifornia, Computer Systems Research Group.'' If you must
  421.      issue a Purchase Order, together with your  prepayment,
  422.      please  issue one that is blank-backed.  If this is not
  423.      possible, insert and initial in the body  of  the  Pur-
  424.      chase  Order the following clause: ``The terms and con-
  425.      ditions of this Purchase Order are not accepted by  The
  426.      Regents  of  the University of California.  The revised
  427.      Berkeley  License  Agreement  (6/92)  prevails.''  Wire
  428.      transfers are strongly discouraged.
  429.  
  430. +    The attached Site Information  Form  completely  filled
  431.      out.  Your copy of the signed 4.4BSD-Encumbered License
  432.      Agreement will be sent to  the  person  listed  as  the
  433.      administrative  contact.   The distribution itself will
  434.      be sent to the technical contact.  All  information  is
  435.      kept  confidential;  it is for our use in notifying you
  436.      of important bug fixes and the availability  of  future
  437.      BSD  distributions.  Please note that we cannot ship to
  438.      post office boxes; therefore, please have the technical
  439.      contact's address supplied without use of a post office
  440.      box.
  441.  
  442.      A checklist is included to aid you in  assembling  this
  443. material.  All the above material must be sent to:
  444.  
  445.         Pauline Schwartz, Distribution Coordinator
  446.         Computer Systems Research Group
  447.         Computer Science Division, EECS
  448.         University of California
  449.         Berkeley, California 94720
  450.  
  451. Once all these items have been received and  are  in  proper
  452. order,  the  distribution  will  be  sent  to  the technical
  453. address listed on the Site Information Form.  We cannot pro-
  454. vide  delivery  dates.   Once  the material is assembled and
  455. packaged, the distribution is shipped by commercial carrier.
  456. Order  of  shipment  will be based on time of arrival of the
  457. properly completed paperwork and confirmation with  AT&T  if
  458. necessary.  Because of the differential in costs of shipping
  459. outside the United States, we ask that organizations  beyond
  460. the  North  American  continent  pay  the  collect  shipping
  461. charges.  If the destination is one where  collect  shipment
  462. cannot  be  made by the carrier, then advance payment of the
  463. shipping charges will be required.
  464.  
  465.      The most expedient way to ensure that your full distri-
  466. bution  is  sent  as  quickly as possible is to include in a
  467. single package two original copies of the appropriate Berke-
  468. ley License Agreement completed and properly signed (without
  469. modification), two complete copies  of  your  AT&T  Software
  470. Agreement  the  appropriate check properly made out to ``The
  471. Regents of the University of  California,  Computer  Systems
  472. Research  Group''  and a completely filled out Site Informa-
  473. tion Form and to send this single  package  to  the  address
  474. noted above.
  475.  
  476.      Please note that if you modify  the   Berkeley  License
  477. Agreement,  you  may  experience  a delay of three months or
  478. more  before  receiving  an  acceptance  or  denial  of  the
  479. changes.  We reserve the right to cancel your application if
  480. we have not received the requested paperwork within 60  days
  481. from the date it was sent to us.
  482.  
  483. Ordering the Upgrade to 4.4BSD
  484.  
  485.      For those who would like to order the  upgrade  to  the
  486. present alpha release of 4.4BSD, we offer the opportunity to
  487. prepay a fee of $400.00 for such upgrade,  scheduled  to  be
  488. released at year's end or soon thereafter.  The advantage in
  489. ordering the upgrade at  the  time  of  ordering  the  alpha
  490. release  is  that  there  will  not  be additional licensing
  491. costs.
  492.  
  493.      If  one  wishes  to  order  the  4.4BSD-Encumbered  and
  494. upgrade,  the  total  fee  will be $2,400.00.  For those who
  495. choose not to order the upgrade now, we will notify you when
  496. it  is  available  so that you may order it for whatever fee
  497. will be set at that time.
  498.  
  499. Special Cases
  500.  
  501.      University of California Sites.  If you are a  part  of
  502. the  University  of  California,  the following requirements
  503. apply: To run 4.4BSD-Encumbered on any CPU, you must have  a
  504. CPU  authorization  under  The  Regents of the University of
  505. California  Software  Agreement  with  AT&T.   This  can  be
  506. obtained  by contacting Pam True at (510) 642-6348 in Berke-
  507. ley Campus Materiel Management for an application. A copy of
  508. this should be sent to us.  In addition, the following items
  509. must be sent to the Computer Systems Research  Group:  1)  a
  510. letter  of  authorization  signed by the Director or Head of
  511. Department requesting 4.4BSD-Encumbered,  stating  that  you
  512. have  read  and  understood  the  Berkeley License Agreement
  513. (6/92) and that your organization will abide by  it;  2)  an
  514. IOC for $2,000.00; and 3) a Site Information Form.
  515.  
  516.      Government Agencies and Government Contractors.
  517.  
  518. +    The U.S. Government has a UNIX Source  Software  Agree-
  519.      ment  with  AT&T  dated  Sept.  1,  1975.  If you are a
  520.      government agency operating  under  the  1975  Software
  521.      Agreement, you do not need a copy of the aforementioned
  522.      Software Agreement; instead you must  send  a  copy  of
  523.      your  additional  CPU  authorization  from  AT&T.   The
  524.      Berkeley License Agreement for 4.4BSD-Encumbered (6/92)
  525.      should  be  signed  by the appropriate Contracting Off-
  526.      icer.
  527.  
  528. +    Several government agencies  have  acquired  their  own
  529.      AT&T  UNIX Software Agreement.  Here, we need a copy of
  530.      this  Software  Agreement  with  AT&T.   The   Berkeley
  531.      License  Agreement  (6/92)  must  be signed by the same
  532.      officeholder (or replacement) whose  signature  appears
  533.      on  the  Software  Agreement with AT&T.  The government
  534.      agency shall be  identified  as  the  Licensee  in  the
  535.      Berkeley License Agreement (6/92).
  536.  
  537. +    If you are a contractor  of  the  Government  and  have
  538.      obtained  an additional CPU authorization from AT&T for
  539.      your contract  work,  the  Berkeley  License  Agreement
  540.      (6/92)  must  be  signed by the appropriate Contracting
  541.      Officer  for  the  contract.   The  contractor   should
  542.      address  a  letter  to  the Contracting Officer stating
  543.      that the contractor agrees to abide by  the  terms  and
  544.      conditions of the Berkeley License Agreement (6/92) for
  545.      4.4BSD and ask that the Contracting  Officer  sign  the
  546.      Berkeley License Agreement (6/92) for 4.4BSD.  The Con-
  547.      tracting Officer should then return the signed Berkeley
  548.      License  Agreement (6/92) directly to the Computer Sys-
  549.      tems Research Group with a cover  letter  stating  that
  550.      the  contractor  is hereby authorized to receive a copy
  551.      of 4.4BSD-Encumbered.
  552.  
  553. A Special Note
  554.  
  555.      The procedures and rules set out in this  document  are
  556. University  and  AT&T  constraints that must be followed for
  557. the distribution of software to be possible.   The  Computer
  558. Systems Research Group has no control over these constraints
  559. and must reject your application if  material  submitted  is
  560. not in order.
  561.  
  562. If You Have Read Everything and Still Need Help
  563.  
  564.      If you have questions about the licensing process after
  565. reading  this letter, you may call Pauline Schwartz at (510)
  566. 642-7780, write to her, or contact her via  electronic  mail
  567. at pauline@cs.berkeley.edu.
  568.  
  569.  
  570.                          Sincerely yours,
  571.  
  572.  
  573.  
  574.                          Marshall Kirk McKusick
  575.                          Research Computer Scientist
  576.                          Computer Systems Research Group
  577.  
  578. _________________________
  579. UNIX, UNIX/32V, UNIX  System III, and UNIX System V are
  580. registered  trademarks of USL/AT&T in the USA and other
  581. countries.
  582.  
  583. Ethernet is a trademark of the Xerox Corporation.
  584.  
  585.