4.4BSD Release

45 views
Skip to first unread message

Keith Bostic

unread,
Jun 29, 1993, 5:57:39 PM6/29/93
to
June 1, 1993

Dear Colleague:


We are happy to send you information about our June
1993 release of 4.4BSD. This distribution is the final
release that will be done by the Computer Systems Research
Group (CSRG). For details on the demise of CSRG, see ``The
End of BSD from Berkeley'' below.

This distribution is intended to be used on production
systems; it has been run extensively at several test sites
and has proven to be stable and reliable. However, because
of the shutdown of the CSRG, there will not be anyone avail-
able at Berkeley to assist with problems, so it should not
be used by sites without enough local expertise to find and
fix any problems that are encountered.

The code in this distribution may be redistributed and
used in released products provided that you abide by the due
credit requirements listed in your license agreement. We
have attempted to make the system as compliant with the
POSIX 1003.1 and 1003.2 standards as was possible at the
time of its release. We have not been able to run it
through any of the verification test suites, thus, you
should not claim conformance with either standard without
first validing the code.

We had planned on releasing two versions of the
software, 4.4BSD-Encumbered and 4.4BSD-Lite. Currently, we
are releasing only 4.4BSD-Encumbered. The 4.4BSD-Encumbered
distribution is available only to sites with UNIX/32V, Sys-
tem III, or System V source licenses with Western Electric,
American Telephone and Telegraph (AT&T), or UNIX Systems
Laboratories (USL). The 4.4BSD-Encumbered distribution is a
complete distribution in the style of 4.3BSD and contains
the complete source for the Berkeley Distribution.

The 4.4BSD-Lite distribution was to have been a distri-
bution that was copyrighted by the University of California
and others, but could be freely redistributed. It was to
have been available to anyone and require no previous
license, either from USL/Novell or The Regents of the
University of California. Its license agreement and content
would have been similar to that of the two BSD Networking
Releases. However, USL has brought a lawsuit against the
University and the University has voluntarily decided to
withhold the distribution of 4.4BSD-Lite until the lawsuit
is resolved.

The enclosed information is designed to serve two pur-
poses. The first purpose is to acquaint you with the
details of our distribution so you can decide whether you
would like to receive it. The second purpose is to tell you
how to obtain our distribution.

What is 4.4BSD?

This software distribution is provided on one 6250bpi
1/2'' 9-track tape or one 8mm Exabyte cassette only. The
4.4BSD-Encumbered distribution contains complete source as
well as binaries for one of the following three architec-
tures:

+ HP 9000/300 68000-based workstations.

+ DECstation 3100 and 5000 MIPS-based workstations.

+ Sparcstation I & II SPARC-based workstations. Please
note that the SPARC kernel will not run on the Sparcs-
tation 10.

If you wish to obtain binaries for more than one architec-
ture, they may be purchased at the same time for an addi-
tional $500.00 fee.

The distribution supports a somewhat wider set of
machines than those for which we have built binaries. The
architectures that are supported in source form include:

+ HP 9000/300 68000-based workstations

+ Intel 386/486-based machines (ISA/AT or EISA bus only)

+ Sony News MIPS-based workstations

+ Omron Luna 68000-based workstations

+ DECstation 3100 and 5000 MIPS-based workstations

+ Sparcstation I & II SPARC-based workstations

The distribution does not include the machine support for
the Tahoe and VAX architectures found in previous BSD dis-
tributions. Our primary development environment is the
HP9000/300 series machines. The other architectures are
developed and supported by people outside the university.
Consequently, we are not able to directly test or maintain
these other architectures, so cannot comment on their
robustness, reliability, or completeness.

The major new facilities available in the 4.4BSD
release are a new virtual memory system, the addition of
ISO/OSI networking support, a new virtual filesystem inter-
face supporting filesystem stacking, a freely redistribut-
able implementation of NFS, a log-structured filesystem,
enhancement of the local filesystems to support files and
filesystems that are up to 2^63 bytes in size, enhanced
security and system management support, and the conversion
to and addition of the IEEE Std1003.1 (``POSIX'') facilities
and many of the IEEE Std1003.2 facilities. In addition,
many new utilities and additions to the C library are
present as well. The kernel sources have been reorganized
to collect all machine-dependent files for each architecture
under one directory, and most of the machine-independent
code is now free of code conditional on specific machines.
The user structure and process structure have been reorgan-
ized to eliminate the statically-mapped user structure and
to make most of the process resources shareable by multiple
processes. The system and include files have been converted
to be compatible with ANSI C, including function prototypes
for most of the exported functions. There are numerous
other changes throughout the system.

The new virtual memory implementation is derived from
the MACH operating system developed at Carnegie-Mellon, and
was ported to the BSD kernel at the University of Utah. The
MACH virtual memory system call interface has been replaced
with the ``mmap''-based interface described in the ``Berke-
ley Software Architecture Manual'' (see UNIX Programmer's
Manual, Supplementary Documents, PSD:5). The interface is
similar to the interfaces shipped by several commercial ven-
dors such as Sun, USL, and Convex Computer Corp. The
integration of the new virtual memory is functionally com-
plete, but still has serious performance problems under
heavy memory load. The internal kernel interfaces have not
yet been completed and the memory pool and buffer cache have
not been merged.

The ISO/OSI Networking consists of a kernel implementa-
tion of transport class 4 (TP-4), connectionless networking
protocol (CLNP), and 802.3-based link-level support
(hardware-compatible with Ethernet*). We also include
support for ISO Connection-Oriented Network Service, X.25,
TP-0. The session and presentation layers are provided out-
side the kernel by the ISO development environment (ISODE).
Included in this development environment are file transfer
and management (FTAM), virtual terminals (VT), a directory
services implementation (X.500), and miscellaneous other
utilities.

A new virtual filesystem interface has been added to
the kernel to support multiple filesystems. In comparison
with other interfaces, the Berkeley interface has been
structured for more efficient support of filesystems that
maintain state (such as the local filesystem). The inter-
face has been extended with support for stackable filesys-
tems done at UCLA. These extensions allow for filesystems
to be layered on top of each other and allow new vnode
operations to be added without requiring changes to existing
filesystem implementations.

In addition to the local ``fast filesystem'', we have
added an implementation of the network filesystem (NFS) that
fully interoperates with the NFS shipped by Sun and its
licensees. Because our NFS implementation was implemented
using only the publicly available NFS specification, it does
not require a license from Sun to use in source or binary
form. By default it runs over UDP to be compatible with
Sun's implementation. However, it can be configured on a
per-mount basis to run over TCP. Using TCP allows it to be
used quickly and efficiently through gateways and over
long-haul networks. Using an extended protocol, it supports
Leases to allow a limited callback mechanism that greatly
reduces the network traffic necessary to maintain cache con-
sistency between the server and its clients.

A new log-structured filesystem has been added that
provides near disk-speed output and fast crash recovery. It
is still experimental in the 4.4BSD release, so we do not
recommend it for production use. We have also added a
memory-based filesystem that runs in pageable memory, allow-
ing large temporary filesystems without requiring dedicated
physical memory.

The local ``fast filesystem'' has been enhanced to do
clustering which allows large pieces of files to be allo-
cated contiguously resulting in near doubling of filesystem
throughput. The filesystem interface has been extended to
allow files and filesystems to grow to 2^63 bytes in size.
The quota system has been rewritten to support both user and
group quotas (simultaneously if desired). Quota expiration
is based on time rather than the previous metric of number
of logins over quota. This change makes quotas more useful
on fileservers onto which users seldom login.

The system security has been greatly enhanced by the
addition of additional file flags that permit a file to be
marked as immutable or append only. Once set, these flags
can only be cleared by the super-user when the system is
running single user. To protect against indiscriminate
reading or writing of kernel memory, all writing and most
reading of kernel data structures must be done using a new
``sysctl'' interface. The information to be access is
described through an extensible ``Management Information
Base'' (MIB).

The 4.4BSD distribution contains most of the interfaces
specified in the IEEE Std1003.1 system interface standard.
The biggest area of change is a new terminal driver. The
terminal driver is similar to the System V terminal driver
with the addition of the necessary extensions to get the
functionality previously available in the 4.3BSD terminal
driver. 4.4BSD also adds the IEEE Std1003.1 job control
interface, which is similar to the 4.3BSD job control inter-
face, but adds a security model that was missing in the
4.3BSD job control implementation. Other additions include
IEEE Std1003.1 signals, FIFOs, byte-range file locking, and
saved user and group identifiers.

There are several new tools and utilities included in
this release. A new version of make allows much-simplified
makefiles for the system software and allows compilation for
multiple architectures from the same source tree (which may
be mounted read-only). Notable additions to the libraries
include functions to traverse a filesystem hierarchy, data-
base interfaces to btree and hashing functions, a new, fast
implementation of stdio and a radix sort function. The
additions to the utility suite include greatly enhanced ver-
sions of programs that display system status information,
implementations of various traditional tools described in
the IEEE Std1003.2 standard, and many others.

We have been tracking the IEEE Std1003.2 shell and
utility work and have included prototypes of many of the
proposed utilities. Because most of the traditional utili-
ties have been replaced with implementations conformant to
the POSIX standards, you should realize that the utility
software may not be as stable, reliable or well documented
as in traditional Berkeley releases. In particular, almost
the entire manual suite has been rewritten to reflect the
POSIX defined interfaces, and in some instances it does not
correctly reflect the current state of the software. It is
also worth noting that, in rewriting this software, we have
generally been rewarded with significant performance
improvements. Most of the libraries and header files have
been converted to be compliant with ANSI C. The default
compiler (gcc) is a superset of ANSI C, but supports
traditional C as a command-line option. The system
libraries and utilities all compile with either ANSI or
traditional C.

Work has also progressed in several other areas.
Several important enhancements have been added to the TCP/IP
protocols including TCP header prediction and serial line IP
(SLIP) with header compression. The routing implementation
has been completely rewritten to use a hierarchical routing
tree with a mask per route to support the arbitrary levels
of routing found in the ISO protocols. The routing table
also stores and caches route characteristics to speed the
adaptation of the throughput and congestion avoidance algo-
rithms.

The Kerberos (version 4) authentication software has
been integrated into much of the system (including NFS) to
provide the first real network authentication on BSD.

This release includes several important structural ker-
nel changes. The kernel uses a new internal system call
convention; the use of global (``u-dot'') variables for
parameters and error returns has been eliminated, and inter-
rupted system calls no longer abort using non-local goto's
(longjmp's). A new sleep interface separates signal han-
dling from scheduling priority, returning characteristic
errors to abort or restart the current system call. This
sleep call also passes a string describing the process
state, which is used by the ps(1) program. The old sleep
interface can be used only for non-interruptible sleeps.
The sleep interface (tsleep) can be used at any priority,
but is only interruptible if the PCATCH flag is set. When
interrupted, tsleep returns EINTR or ERESTART.

Many data structures that were previously statically
allocated are now allocated dynamically. These structures
include mount entries, file entries, user open file descrip-
tors, the process entries, the vnode table, the name cache,
and the quota structures.

The End of BSD from Berkeley

For the following three reasons, the CSRG clearly could
not continue in its present form.

Funding had become increasingly time-consuming and dif-
ficult. We were spending more and more of our time obtain-
ing funding, time that we would have preferred to spend
working on BSD. As many of you are intimately aware, com-
puter corporations are actively seeking ways to reduce dis-
cretionary outlays. Also, as UNIX vendors have developed
their own research groups, the work of the CSRG became less
necessary to them. Finally, making BSD freely redistribut-
able resulted in fewer distributions sold, as other
organizations sold our releases for less money.

Support within the University of California declined as
BSD became less widely used internally. Victims of our own
success, many of the features once found only in BSD are now
available from every vendor.

The system has become too large and complex for a group
of four to architect and maintain. In the last few years it
became obvious to us that we had to expand the size of our
group if we wanted to continue developing and distributing a
complete UNIX system. Expansion was impossible given the
external funding environment and the space constraints
imposed by the university.

BSD has always been a community effort, and, as a com-
munity effort, does not rely on a small group of people in
Berkeley to keep it going. BSD will not go away, but will
live on through the free software and commercial efforts of
many people. We thank you for your support over the years,
your funding, and, of course, the software you've contri-
buted to make the BSD system what it is today!

How to obtain 4.4BSD-Encumbered

To obtain 4.4BSD-Encumbered we require execution of the
Berkeley License Agreement (6/92). In addition, foreign
licensees must execute Addendum Number One for Foreign
Licensees in ordering 4.4BSD-Encumbered. The fee is
$2500.00 for 4.4BSD-Encumbered.

Because we are a research and development organization
and not a commercial organization, we make our research
results available for a small license fee. We distribute
only the whole system ``As Is'' and cannot send individual
pieces of the system. We are required by the University of
California to have a formal license arrangement with each
organization to which we distribute. In addition, for
4.4BSD-Encumbered, we are required to secure a copy of the
USL (or AT&T or Western Electric) Software Agreement with
your organization and confirm it with USL before the
software can be shipped.

Specifically, for 4.4BSD-Encumbered, we must receive
from your organization the following material before the
distribution can be sent:

+ Two copies of the current Software Agreement between
your company or institution and USL (or AT&T or Western
Electric) that authorize you as a source licensee for
UNIX/32V, System III, or System V. Note that a com-
plete copy of the agreement up to the Schedule is
required, not just the cover and/or signature page.
Letters authorizing additional CPUs are not necessary
in this process; however, it is your legal responsibil-
ity to obtain an additional CPU authorization from USL.

+ Two original signed and executed copies of the Berkeley
License Agreement (6/92) between your company or insti-
tution and The Regents of the University of California
along with Exhibit A properly filled out. For Foreign
licensees, there is an Addendum to the License Agree-
ment that must also be executed. The name of the
organization on the Berkeley License Agreement must be
the same as that which appears on the Software Agree-
ment with USL (or AT&T or Western Electric). The
Berkeley License Agreement (6/92) must be signed by a
duly authorized person who holds a position that is at
the same level or a higher level of authority as that
which appears on the USL (or AT&T or Western Electric)
Software Agreement. Please have this person's name and
title typed in the available space in addition to the
signature. This license agreement applies to all the
CPUs covered by the Software Agreement with USL (or
AT&T or Western Electric) that you have provided. One
signed copy of the Berkeley License Agreement will be
returned to you after it has been executed by The
Regents of the University of California.

+ A check from a U.S. bank for $2500.00 must be received
before the distribution can be sent. Checks should be
made payable to ``The Regents of the University of Cal-
ifornia, Computer Systems Research Group.'' If you must
issue a Purchase Order, together with your prepayment,
please issue one that is blank-backed. If this is not
possible, insert and initial in the body of the Pur-
chase Order the following clause: ``The terms and con-
ditions of this Purchase Order are not accepted by The
Regents of the University of California. The revised
Berkeley License Agreement (6/92) prevails.'' Wire
transfers are strongly discouraged.

+ The attached Site Information Form completely filled
out. Your copy of the signed 4.4BSD-Encumbered License
Agreement will be sent to the person listed as the
administrative contact. The distribution itself will
be sent to the technical contact. All information is
kept confidential; it is for our use in notifying you
of important bug fixes and the availability of 4.4BSD-
Lite should it become available. Please note that we
cannot ship to post office boxes; therefore, please
have the technical contact's address supplied without
use of a post office box.

A checklist is included to aid you in assembling this
material. All the above material must be sent to:

Pauline Schwartz, Distribution Coordinator
Computer Systems Research Group
Computer Science Division, EECS
University of California
Berkeley, California 94720

Once all these items have been received and are in proper
order, the distribution will be sent to the technical
address listed on the Site Information Form. We cannot pro-
vide delivery dates. Once the material is assembled and
packaged, the distribution is shipped by commercial carrier.
Order of shipment will be based on time of arrival of the
properly completed paperwork and confirmation with USL if
necessary. Because of the differential in costs of shipping
outside the United States, we ask that organizations beyond
the North American continent pay the collect shipping
charges. If the destination is one where collect shipment
cannot be made by the carrier, then advance payment of the
shipping charges will be required.

The most expedient way to ensure that your full distri-
bution is sent as quickly as possible is to include in a
single package two original copies of the appropriate Berke-
ley License Agreement completed and properly signed (without
change), two complete copies of your USL (or AT&T or Western
Electric) Software Agreement, the appropriate check properly
made out to ``The Regents of the University of California,
Computer Systems Research Group'' and a completely filled
out Site Information Form and to send this single package to
the address noted above.

Please note that if you modify the Berkeley License
Agreement, you may experience a delay of three months or
more before receiving an acceptance or denial of the
changes. We reserve the right to cancel your application if
we have not received the requested paperwork within 60 days
from the date it was sent to us.

Special Cases

University of California Sites. If you are a part of
the University of California, the following requirements
apply: To run 4.4BSD-Encumbered on any CPU, you must have a
CPU authorization under The Regents of the University of
California Software Agreement with USL. This can be
obtained by contacting Pam True at (510) 642-6348 in Berke-
ley Campus Materiel Management for an application. A copy of
this should be sent to us. In addition, the following items
must be sent to the Computer Systems Research Group: 1) a
letter of authorization signed by the Director or Head of
Department requesting 4.4BSD-Encumbered, stating that you
have read and understood the Berkeley License Agreement
(6/92) and that your organization will abide by it; 2) an
IOC for $2,500.00; and 3) a Site Information Form.

Government Agencies and Government Contractors.

+ The U.S. Government has a UNIX Source Software Agree-
ment with AT&T dated Sept. 1, 1975. If you are a
government agency operating under the 1975 Software
Agreement, you do not need a copy of the aforementioned
Software Agreement; instead you must send a copy of
your additional CPU authorization from AT&T. The
Berkeley License Agreement for 4.4BSD-Encumbered (6/92)
should be signed by the appropriate Contracting Off-
icer.

+ Several government agencies have acquired their own
AT&T UNIX Software Agreement. Here, we need a copy of
this Software Agreement with USL or AT&T. The Berkeley
License Agreement (6/92) must be signed by the same
officeholder (or replacement) whose signature appears
on the Software Agreement with USL or AT&T. The
government agency shall be identified as the Licensee
in the Berkeley License Agreement (6/92).

+ If you are a contractor of the Government and have
obtained an additional CPU authorization from USL or
AT&T for your contract work, the Berkeley License
Agreement (6/92) must be signed by the appropriate Con-
tracting Officer for the contract. The contractor
should address a letter to the Contracting Officer
stating that the contractor agrees to abide by the
terms and conditions of the Berkeley License Agreement
(6/92) for 4.4BSD and ask that the Contracting Officer
sign the Berkeley License Agreement (6/92) for 4.4BSD.
The Contracting Officer should then return the signed
Berkeley License Agreement (6/92) directly to the Com-
puter Systems Research Group with a cover letter stat-
ing that the contractor is hereby authorized to receive
a copy of 4.4BSD-Encumbered.

A Special Note

The procedures and rules set out in this document are
University and USL constraints that must be followed for the
distribution of software to be possible. The Computer Sys-
tems Research Group has no control over these constraints
and must reject your application if material submitted is
not in order. If you have questions about the licensing
process after reading this letter, you may call Pauline
Schwartz at (510) 642-7780, write to her, or contact her via
electronic mail at pau...@cs.berkeley.edu.


Sincerely yours,

Marshall Kirk McKusick
Research Computer Scientist
Computer Systems Research Group


_________________________
UNIX, UNIX/32V, UNIX System III, and UNIX System V are
registered trademarks of USL/Novell in the USA and some
other countries.

_________________________
Ethernet is a trademark of the Xerox Corporation.

Wolfgang Rupprecht

unread,
Jun 29, 1993, 9:26:17 PM6/29/93
to
bos...@toe.CS.Berkeley.EDU (Keith Bostic) writes:
>We are happy to send you information about our June 1993 release of
>4.4BSD. [...] We had planned on releasing two versions of the
>software, 4.4BSD-Encumbered and 4.4BSD-Lite. [...] USL has brought

>a lawsuit against the University and the University has voluntarily
>decided to withhold the distribution of 4.4BSD-Lite until the lawsuit
>is resolved.

Are *any* parts of 4.4 freely available?

Why are the Berkeley lawyers being such wimps? What good are ones
attack dogs if they are afraid of the other guys attack dogs? Can't
BSDI's lawyers give Berkeley's some assertiveness training or
something?

-wolfgang
--
Wolfgang Rupprecht <wolf...@wsrcc.com> 39469 Gallaudet Dr., Fremont CA 94538

Chris G. Demetriou

unread,
Jun 29, 1993, 9:35:10 PM6/29/93
to
Subject: 4.4BSD Release

June 1, 1993

Dear Colleague:


We are happy to send you information about our June

1993 release of 4.4BSD. This distribution is the final
release that will be done by the Computer Systems Research
Group (CSRG). For details on the demise of CSRG, see ``The
End of BSD from Berkeley'' below.

This distribution is intended to be used on production
systems; it has been run extensively at several test sites
and has proven to be stable and reliable. However, because
of the shutdown of the CSRG, there will not be anyone avail-
able at Berkeley to assist with problems, so it should not
be used by sites without enough local expertise to find and
fix any problems that are encountered.

The code in this distribution may be redistributed and
used in released products provided that you abide by the due
credit requirements listed in your license agreement. We
have attempted to make the system as compliant with the
POSIX 1003.1 and 1003.2 standards as was possible at the
time of its release. We have not been able to run it
through any of the verification test suites, thus, you
should not claim conformance with either standard without
first validing the code.

We had planned on releasing two versions of the


software, 4.4BSD-Encumbered and 4.4BSD-Lite. Currently, we
are releasing only 4.4BSD-Encumbered. The 4.4BSD-Encumbered
distribution is available only to sites with UNIX/32V, Sys-
tem III, or System V source licenses with Western Electric,
American Telephone and Telegraph (AT&T), or UNIX Systems
Laboratories (USL). The 4.4BSD-Encumbered distribution is a
complete distribution in the style of 4.3BSD and contains
the complete source for the Berkeley Distribution.

The 4.4BSD-Lite distribution was to have been a distri-
bution that was copyrighted by the University of California
and others, but could be freely redistributed. It was to
have been available to anyone and require no previous
license, either from USL/Novell or The Regents of the
University of California. Its license agreement and content
would have been similar to that of the two BSD Networking

Releases. However, USL has brought a lawsuit against the


University and the University has voluntarily decided to
withhold the distribution of 4.4BSD-Lite until the lawsuit
is resolved.

The enclosed information is designed to serve two pur-

Dick Dunn

unread,
Jun 30, 1993, 11:41:13 PM6/30/93
to
wolf...@wsrcc.com (Wolfgang Rupprecht) writes:
[Keith/Kirk letter on 4.4 availability]
...
>Why are the Berkeley lawyers being such wimps?...

How are they wimps? They've made a decision about what's the most
reasonable approach while the suit is pending. It may be that they
want to minimize the cost to the university in the (now increasingly
unlikely) event they lose the suit--and that's good strategy. It may
be that they don't see a major gain to the university in releasing
4.4-Lite sooner. (I'm not saying I agree with that, but it's a plausible
line of reasoning.)

>...What good are ones
>attack dogs if they are afraid of the other guys attack dogs?...

The university's "attack dogs" are probably mostly concerned with defense
of the university. Unlike many large corporations, universities can't
generally make money suing other organizations. But anyway...

>...Can't BSDI's lawyers give Berkeley's some assertiveness training or
>something?

This is really the crux of the matter--the situation is very different for
these two organizations, and the lawyers are behaving accordingly.

BSDI: They have nothing to lose by selling/distributing their product. As
long as they're not under injunction, the more they sell and the sooner
they sell it, the better off they are. If they win the suit, it vindicates
the decision not to hold back; if they lose the suit, they're just shut
down, period. That's why they released 1.0 as soon as the injunction
request was denied.

UC Berkeley: They actually have nothing to gain by distributing early! It
would be nice, and we'd all like to see it, but all they get is the chance
to give something away sooner. OTOH, if they lose the suit, the penalty
against the university may well depend in part on how they've acted in the
meantime. Moreover, there's no reason for them to do things which might
provoke more aggressive legal action from USL...the sooner the case gets
decided, the better.

It's really easy to get impatient with the process..."justice" in a big
suit like this is unbelievably, unconscionably slow. Frankly, I think we
should be glad that UC's lawyers are actually fighting this case instead of
giving it up. They could well have said "we can't afford the time and
expense of fighting this" and settled out of court--which probably would
have meant no 4.4 at all. In fact, I seem to recall there was a point when
it *did* look like they weren't going to defend against the suit, but either
decided or were persuaded to continue.

If UC weren't defending, BSDI would have a much harder (perhaps impossible)
battle...and from there, it would get pretty grim--first for UC work and
BSDI, but soon thereafter for the free efforts as well.

As much as I'd like to see 4.4-Lite come out tomorrow, I think we're much
better off with UC in the picture but moving carefully, than not having
them involved at all.

(And the worst of it is that nobody in power at USL seems to have a clue
that this whole affair amounts to little more than a sales promotion effort
for Microsoft...)
--
Dick Dunn r...@eklektix.com -or- raven!rcd Boulder, Colorado USA
...Simpler is better.

Vernon Schryver

unread,
Jul 1, 1993, 10:56:01 AM7/1/93
to
In article <1993Jul...@eklektix.com>, r...@raven.eklektix.com (Dick Dunn) writes:
> ...

> >...What good are ones
> >attack dogs if they are afraid of the other guys attack dogs?...
>
> The university's "attack dogs" are probably mostly concerned with defense
> of the university. Unlike many large corporations, universities can't
> generally make money suing other organizations. ...

I wonder about that in this particular case.

The SVR3 and SVR4 source includes a lot of BSD source, but not
a lot of references to the Regents of the University of California.
Look at the System V network code.

Of course, maybe the BSD copyright is satisfied anyway. I know
I don't understand what is or is not required to satisfy it for a
commercial product, exactly where you must give BSD credit.


> ...


> (And the worst of it is that nobody in power at USL seems to have a clue
> that this whole affair amounts to little more than a sales promotion effort
> for Microsoft...)

And for Netware. (Remember USL's new bosses.)


Vernon Schryver, v...@sgi.com

Gerhard Fuernkranz

unread,
Jul 1, 1993, 11:11:36 AM7/1/93
to
What is the real difference between BSD-Encumbered and BSD-Lite ?
Which parts are missing in BSD-Lite ?

Thanks in advance

--
Gerhard Fuernkranz SIEMENS Austria Corp.
Email: fu...@siemens.co.at Gudrunstr. 11
Phone: +43-1-60171-5716 A-1100 Wien

Keith Moore

unread,
Jul 1, 1993, 6:00:33 PM7/1/93
to
What I'd like to know is: are the non-AT&T portions of 4.4BSD marked
in such a way as to distinguish them, and are 4.4BSD licensees
restricted from redistributing those portions?

--
Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN 37996-1301
Internet: mo...@cs.utk.edu BITNET: moore@utkvx
Let's stamp out software copyright in our lifetime.

Wolfgang Rupprecht

unread,
Jul 1, 1993, 6:30:39 PM7/1/93
to
r...@raven.eklektix.com (Dick Dunn) writes:
>How are they wimps? They've made a decision about what's the most
>reasonable approach while the suit is pending. It may be that they
>want to minimize the cost to the university in the (now increasingly
>unlikely) event they lose the suit--and that's good strategy. It may
>be that they don't see a major gain to the university in releasing
>4.4-Lite sooner.

From my vantage point it appears that AT&T doesn't have to actually
win the court case. They can just keep matters in the courts for a
few years. Look at how long the Apple look-and-feel suit has gone on.
If the AT&T suit stretches out just as long, that will keep 4.4BSD out
of the hands of most of us for the next 5-10 years. Will anyone even
care if a 10 year old BSD4.4 is finally released?

>UC Berkeley: They actually have nothing to gain by distributing
>early!

Actually, if this AT&T gambit works to either delay, or actually
prevent Berkeley from distributing *its* work, what is to prevent
other companies from trying to legally tie up other universities in
areas where they compete? What if a CPU manufacturer decides that
some RISC chip that a university is building may compete with them?
Suppose that a crypto company decides that some algorithms that a
university is using competes with their product. Once one university
shows that it can be pushed around, other ethically challenged
companies may be encouraged to give it a try too.

Rob Robertson

unread,
Jul 1, 1993, 12:13:49 PM7/1/93
to
In article <20vmq1...@CS.UTK.EDU> mo...@cs.utk.edu (Keith Moore) writes:

What I'd like to know is: are the non-AT&T portions of 4.4BSD marked
in such a way as to distinguish them, and are 4.4BSD licensees
restricted from redistributing those portions?

yes. the files that have the at&t copyright on them belong to at&t.
the ones only that have the UC Rodents copyright do not belong to
at&t.

no, you are not forbidden to redistribute the non-AT&T portions.

rob
--
william robertson
r...@agate.berkeley.edu

"indecision is the key to flexibility"

David E. Wexelblat

unread,
Jul 1, 1993, 7:40:51 PM7/1/93
to
In article <20voif$3...@wsrcc.com> wolf...@wsrcc.com (Wolfgang Rupprecht) writes:
> r...@raven.eklektix.com (Dick Dunn) writes:
> >How are they wimps? They've made a decision about what's the most
> >reasonable approach while the suit is pending. It may be that they
> >want to minimize the cost to the university in the (now increasingly
> >unlikely) event they lose the suit--and that's good strategy. It may
> >be that they don't see a major gain to the university in releasing
> >4.4-Lite sooner.
>
> From my vantage point it appears that AT&T doesn't have to actually
> win the court case. They can just keep matters in the courts for a
> few years. Look at how long the Apple look-and-feel suit has gone on.
> If the AT&T suit stretches out just as long, that will keep 4.4BSD out
> of the hands of most of us for the next 5-10 years. Will anyone even
> care if a 10 year old BSD4.4 is finally released?
>

I've been waiting more than a year to be able to say this....

IT'S NOT AT&T'S LAWSUIT!!!!!

It's USL's lawsuit. It was partly AT&T's lawsuit, when they owned part
of USL. It was also partly Novell's, Sony's, etc, etc (I can't remember
any of USL's other previous owners). It's NOW (as of June 14) Novell's
lawsuit. Put the blame where the blame belongs.

And for the certain low-class subset of BSD users out there (you know who
you are...): Not everyone who works for AT&T works for USL. And not
everyone who works for AT&T was in favor of the suit. Nor did we have
any control over it. Sending hate-mail to the grunts in the trenches does
not win you friends, and does not encourage these grunts to work on freeware
projects that you benefit from (XFree86 spring immediately to mind :->).

Yes, I did get hate-mail asking how a low-class AT&T slime like me had
the guts to post publically on the net. Fortunately, I didn't let that
discourage me. Now that AT&T is no longer involved, I can publically
say: F.O.A.D (mail me if you don't know what that means).

>
> -wolfgang
> --
> Wolfgang Rupprecht <wolf...@wsrcc.com> 39469 Gallaudet Dr., Fremont CA 94538


--
David Wexelblat <dw...@mtgzfs3.att.com> (908) 957-5871 Fax: (908) 957-5627
AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ 07748

XFree86 requests should be addressed to <xfr...@physics.su.oz.au>

"How many times must good men die? How many tears will the children cry,
'til we suffer no more sadness? Oh, stop the madness. Stop all the madness."
-- Molly Hatchet, Fall Of The Peacemakers.

Sean Eric Fagan

unread,
Jul 1, 1993, 8:12:20 PM7/1/93
to
In article <ROB.93Ju...@gangrene.berkeley.edu> r...@agate.berkeley.edu (Rob Robertson) writes:
>no, you are not forbidden to redistribute the non-AT&T portions.

You just get to face being sued by USL.

Rob Robertson

unread,
Jul 1, 1993, 4:11:53 PM7/1/93
to

you can face getting sued by USL by saying `unix' the wrong way.

Wolfgang Rupprecht

unread,
Jul 2, 1993, 3:30:29 AM7/2/93
to
dw...@mtgzfs3.att.com (David E. Wexelblat) writes:
>wolf...@wsrcc.com (Wolfgang Rupprecht) writes:
>>[...]

>And for the certain low-class subset of BSD users out there (you know who
>you are...): [...] Sending hate-mail to the grunts in the trenches does

>not win you friends, and does not encourage these grunts to work on freeware
>[...]Now that AT&T is no longer involved, I can publically

>say: F.O.A.D (mail me if you don't know what that means).
>> -wolfgang
>> --
>> Wolfgang Rupprecht <wolf...@wsrcc.com> 39469 Gallaudet Dr., Fremont CA 94538

Can we please be a bit more careful in the quoting the next time?
Your post sounds like I sent you nasty email. As far as I know, I
have never sent any email to you ever.

Henry Spencer

unread,
Jul 2, 1993, 1:23:58 PM7/2/93
to
In article <20vmq1...@CS.UTK.EDU> mo...@cs.utk.edu writes:
>What I'd like to know is: are the non-AT&T portions of 4.4BSD marked
>in such a way as to distinguish them, and are 4.4BSD licensees
>restricted from redistributing those portions?

The portions that UCB *thinks* are non-AT&T are marked. And there is
no prohibition on redistributing things that are non-AT&T. But note the
difference in phrasing between those two sentences -- the whole lawsuit
turns on differences of opinion about what is proprietary and what isn't.

If you take UCB's word for it, you're in big trouble if the court decides
that their judgement was wrong. If you decide for yourself what's clean
and what isn't, you're next in line for a lawsuit if UCB loses this one.
(These unpleasant outcomes now look unlikely, but can't be ruled out.)

And anyone who too-flagrantly proceeds on the assumption that the suit
will be decided the right way is a candidate for becoming a co-defendant,
which is troublesome and expensive even if the good guys eventually win.
--
Altruism is a fine motive, but if you | Henry Spencer @ U of Toronto Zoology
want results, greed works much better. | he...@zoo.toronto.edu utzoo!henry

Wolfgang Schelongowski

unread,
Jul 2, 1993, 9:42:16 PM7/2/93
to
dw...@mtgzfs3.att.com (David E. Wexelblat) writes:

> I've been waiting more than a year to be able to say this....
>
> IT'S NOT AT&T'S LAWSUIT!!!!!

[Statements with which I mostly agree not repeated]

> Yes, I did get hate-mail asking how a low-class AT&T slime like me had
> the guts to post publically on the net. Fortunately, I didn't let that
> discourage me.

It may be a little bit too late for this advice, but you should
have collected typical excerpts from the hate-mail (sine ira et
studio) including the name of the senders. From time to time you
could have posted this collection in a suitable newsgroup where
you are known (this one or comp.windows.x.i386unix). So the people
who wrote hate-mail would have been exposed for their ignorant
"rightfully smiting the heathen and thus saving the world".
What's more, nearly everybody would have enjoyed a good laugh
at the expense of those people !

--
Wolfgang Schelongowski
w...@xivic.bo.open.de or ...!uunet!Germany.EU.net!xivic.bo.open.de!ws
Well I've always had a deep respect, and I mean that most sincerely !
-- Roger Waters, Have a Cigar

Juergen Nickelsen

unread,
Jul 4, 1993, 4:16:41 PM7/4/93
to

> you can face getting sued by USL by saying `unix' the wrong way.

Perhaps we should try to establish another name for the BSD line of
OSs. My suggestion: ``Berkeley Tradition *nix'', pronounced
``Beetnix''. :-)

--
Juergen Nickelsen

J Greely

unread,
Jul 6, 1993, 5:07:39 PM7/6/93
to
In article <ROB.93Ju...@gangrene.berkeley.edu> r...@agate.berkeley.edu
(Rob Robertson) writes:
>you can face getting sued by USL by saying `unix' the wrong way.

Funny that they're rather selective about this. Every bookstore I've
been in that has much in the way of computer books has a "Unix" (no
trademark) section, in which they file books on SCO, Xenix, Solaris,
NextStep, etc. Why, you might even find a copy of "The UNIX
Programming Environment", which has no external (R) or TM decorations,
on front, back, or spine. Of all the Unix books on my shelf, the only
one that doesn't have an (R) on it came from Bell Labs. Go figure.

As a consumer, I've certainly been lead to believe that "Unix" is a
generic term for a class of operating systems sharing certain
features...
--
J Greely (jgr...@cis.ohio-state.edu; osu-cis!jgreely)

Michael I Bushnell

unread,
Jul 6, 1993, 7:42:30 PM7/6/93
to

Wellp, you're wrong in this case. All of those things: SCO, Xenix,
Solaris, NextStep, BSD 4.3, etc., are in fact Unix. They all use the
AT&T code, and all have the right to call themselves Unix. Some other
thing (GNU, for example, or Linux, or 386 BSD) which don't include the
AT&T Unix code, nor are derived from it, cannot call themselves Unix.

One of the things that started the USL v. BSDI lawsuit was BSDI's
foolish use of the phone number `1-800-ITS-UNIX'; this was incorrect
and pretty clearly trademark infringement.

--
+1 617 623 3248 (H) | The LORD is gracious and full of compassion,
+1 617 253 8568 (W) -+- slow to anger and of great kindness.
1105 Broadway | The LORD is loving to everyone
Somerville, MA 02144 | and his compassion is over all his works.

Sean Eric Fagan

unread,
Jul 6, 1993, 9:05:53 PM7/6/93
to
In article <MIB.93Ju...@geech.gnu.ai.mit.edu> m...@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>Wellp, you're wrong in this case. All of those things: SCO, Xenix,
>Solaris, NextStep, BSD 4.3, etc., are in fact Unix. They all use the
>AT&T code, and all have the right to call themselves Unix. Some other
>thing (GNU, for example, or Linux, or 386 BSD) which don't include the
>AT&T Unix code, nor are derived from it, cannot call themselves Unix.

Actually, XENIX cannot be called UNIX, which is why, as one might
guess, it is called XENIX instead of UNIX. Same for IRIX, etc. Just
getting a source license and binary distribution license from AT&T/USL
did not give one the right to call the product "UNIX"; I know that
SCO paid for the right to call their product UNIX, and paid pretty
dearly.

Also, NeXTStep does not have the right to call itself UNIX, I believe,
and Solaris might or might not.

In addition, the fact is, the trademark on "UNIX" *is* disputed. Just
one person saying he believed otherwise is enough to cause some suspicion,
and there are undoubtedly many, many others who feel the same, just as
there are almost certainly some who do not associate "UNIX" with USL.

Rahul Dhesi

unread,
Jul 6, 1993, 10:03:05 PM7/6/93
to
In <MIB.93Ju...@geech.gnu.ai.mit.edu> m...@geech.gnu.ai.mit.edu
(Michael I Bushnell) writes:

>Wellp, you're wrong in this case. All of those things: SCO, Xenix,
>Solaris, NextStep, BSD 4.3, etc., are in fact Unix. They all use the
>AT&T code, and all have the right to call themselves Unix. Some other
>thing (GNU, for example, or Linux, or 386 BSD) which don't include the
>AT&T Unix code, nor are derived from it, cannot call themselves Unix.

Michael, sorry to be so blunt, but you are very confused. You are
confusing between the generic term UNIX, which is descriptive and
refers to a broad class of operating systems, and the specific term
UNIX, which refers to products from AT&T and USL. A little research
will show you that the uses of UNIX as a generic term far outnumber its
uses to refer to a specific trade-marked product.
--
Rahul Dhesi <dh...@rahul.net>
also: dh...@cirrus.com

Terry Kennedy, Operations Mgr.

unread,
Jul 6, 1993, 11:11:10 PM7/6/93
to
In article <C9rsE...@kithrup.com>, s...@kithrup.com (Sean Eric Fagan) writes:
> Actually, XENIX cannot be called UNIX, which is why, as one might
> guess, it is called XENIX instead of UNIX. Same for IRIX, etc. Just
> getting a source license and binary distribution license from AT&T/USL
> did not give one the right to call the product "UNIX"; I know that
> SCO paid for the right to call their product UNIX, and paid pretty
> dearly.

Yup - this is one of the things that hurt the AT&T/USL/whatever "Unix"
effort. For many years, if you were a commercial vendor with lots of money,
you could hand some of that money to AT&T (no USL yet) and get the right
to sell copies of AT&T's Unix as long as you didn't call it Unix. Thus we
had Genix (National Semiconductor), etc. - probably hundreds of assorted
*ix (and a few *yx) products from as many vendors.

Now, an end-user-style customer with a system running "Fooix" doesn't
necessarily associate Fooix with AT&T/USL and any other *ix system. This
did a *lot* to fragment the Unix marketplace.

In fact, I remember when Microsoft got the rights to what they called
Xenix, which at that time ran on a PDP-11 system. This was in 1980 or so.
We had a Microsoft Xenix system running on a PDP-11/34 and all the manuals
were AT&T/Bell Labs manuals with "Unix" magic-markered out and a sticker
on the cover saying something like "All references to AT&T Unix within are
actually to Microsoft Xenix, a software product licensed from AT&T". I
remember seeing Microsoft delaying Xenix for PC's again and again, and
wondering why. When I asked, I was told that they were rewriting large
portions of the code. I thought this was pretty bizarre, as I had seen it
happily running on an 8086-based Zenith system many months ago. To this
day I don't know why Microsoft waited so long to deliver product.

Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA
te...@spcvxa.spc.edu +1 201 915 9381

Casper H.S. Dik

unread,
Jul 7, 1993, 4:28:37 AM7/7/93
to
s...@kithrup.com (Sean Eric Fagan) writes:

>Also, NeXTStep does not have the right to call itself UNIX, I believe,
>and Solaris might or might not.

Solaris does have that right:

telnet solaris-host
.....
UNIX(r) System V Release 4.0 (...)

login:

Casper

J Greely

unread,
Jul 7, 1993, 1:14:51 PM7/7/93
to
In article <MIB.93Ju...@geech.gnu.ai.mit.edu> m...@geech.gnu.ai.mit.edu

(Michael I Bushnell) writes:
>Some other thing (GNU, for example, or Linux, or 386 BSD) which don't
>include the AT&T Unix code, nor are derived from it, cannot call
>themselves Unix.

Really? So what section of the bookstore would you go looking in for
a book on GNU or Linux? The "strongly resembles UNIX(R), but is not a
USL product" section or the "Unix" section?

Doug Gwyn

unread,
Jul 7, 1993, 12:01:48 PM7/7/93
to
In article <C9rv1...@rahul.net> dh...@rahul.net (Rahul Dhesi) writes:
>Michael, sorry to be so blunt, but you are very confused. You are
>confusing between the generic term UNIX, which is descriptive and
>refers to a broad class of operating systems, and the specific term
>UNIX, which refers to products from AT&T and USL.

Saying so doesn't make it so.

It has been very clear all along to anyone who paid attention that
"UNIX" was not only a registered trademark (of Bell Labs, AT&T, USL,
or whatever) but also that licensing was required to use the product,
and UNIX source licensing has always involved a contract to protect
the proprietary interests of the producer. Bell/AT&T/USL lawyers
frequently contacted people who neglected to properly credit "UNIX"
as a trademark.

I've been riding herd over the vast array of BRL/APG UNIX licenses
for several years; we are one of the largest "end user" (as opposed
to VAR) licensees of UNIX and related software. And in order to
acquire source to Irix and SunOS we've had to exhibit our source
license(s) for UNIX.

The fact is, trademarked/licensed UNIX (in any of its several
varieties) has served as the base for the majority of UNIX look-
alikes, which have "added value" (usually in the form of vendor-
specific extensions) to the official UNIX release. There have been
some notable exceptions, the first being Idris and later Coherent.
I can't attest to "4.4BSD-lite", but previous releases of BSD have
definitely been derived from the licensed UNIX product.

Independently developed systems like Coherent have typically been
engineered to provide interfaces compatible with those documented
in the (publicly available) UNIX reference manuals; this made sense
so long as it was UNIX functionality that customers wanted, not
necessarily the official UNIX software release itself. There was
one important reason why one might want an official UNIX-derived
product, namely to track the official product as it evolved. The
divergence of the BSD variants from the official version of UNIX
caused untold porting difficulty and unnecessary expense; as of
SVR4 all three major UNIX variants (Xenix, BSD, and official UNIX)
were merged into one product, which was a significant achievement.
(Then OSF started another variant, alas. Fortunately OSF's AES
has been tracking POSIX, SVID, and XPG amazingly closely, so there
hasn't been another big porting problem so far.)

Products that are built to emulate UNIX but are not based on the
licensed UNIX system software itself should be called "UNIX clones"
or "UNIX look-alikes", not simply "UNIX" which is a trademark. Just
as Scott facial tissues should not be called "Kleenex" and Pepsi-
Cola should not be called "Coke".

Rahul Dhesi

unread,
Jul 7, 1993, 2:26:34 PM7/7/93
to
In <20...@smoke.brl.mil> gw...@smoke.brl.mil (Doug Gwyn) responds to me
as follows:

>Saying so doesn't make it so.

>Products that are built to emulate UNIX but are not based on the


>licensed UNIX system software itself should be called "UNIX clones"
>or "UNIX look-alikes", not simply "UNIX" which is a trademark.

The last sentence in the paragraph that I posted was:

A little research will show you that the uses of UNIX as a generic
term far outnumber its uses to refer to a specific trade-marked
product.

I'm sure there is room to disagree about how the word UNIX *should be*
used (depending on how closely one is tied to USL). However, are you
also disagreeing about how the word 'UNIX' *is actually used*? It
appears to me that it has taken on a generic meaning that is far more
common than its uses as a trade-marked term. Some people may consider
it regrettable that this is the case, and may need some Aspirin (TM) to
relieve the headache this might cause them, but, as you say, "saying so


doesn't make it so".

Have you see the word 'Unices' used to refer to Unix in plural? When
you see a word used often in a plural form, you can be reasonably sure
that it is no longer being used as an adjective and, therefore, not
being used as a trade mark.

Here's a second opinion.

===== begin saved posting =====
Date: Wed, 07 Jul 1993 04:17:23 GMT
From: vl...@epimbe.com (James C. Vlcek)
Newsgroups: comp.os.ms-windows.programmer.win32,comp.unix.misc
Subject: Gates says Windows NT is a form of UNIX (TM)

>From the July 5, 1993 ComputerWorld (p 15):

Gates says Windows NT is a form of Unix

Windows NT came full circle last week - from snubbing to becoming Unix -
when Microsoft Corp. Chariman Bill Gates used his PC Expo address to
proclaim "Windows NT will be the most popular form of Unix ever."

Well, I guess imitation _is_ the sincerest form of flattery.

But be forewarned: that old argument - "NT isn't Unix" - isn't going
to wash any more when we UNIX weenies complain about one of the myriad
of things that have been left out of thes "most popular form of Unix
ever."

Jim Vlcek
vl...@epimbe.com
===== end saved posting =====

Doug Gwyn

unread,
Jul 1, 1993, 6:22:20 PM7/1/93
to
In article <iss...@rhyolite.wpd.sgi.com> v...@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>The SVR3 and SVR4 source includes a lot of BSD source, but not
>a lot of references to the Regents of the University of California.

As I heard it, this was the result of an earlier deal worked
out between UCB and AT&T, giving the latter rights to the
former's software as compensation for some infringement on
the rights of the latter. Somebody will undoubtedly correct
me if this is not the case..

Jordan Hayes

unread,
Jul 8, 1993, 10:05:08 AM7/8/93
to
I remember getting a memo from AT&T when I was at Berkeley that
detailed (3 pages at least) "proper" and "improper" usage of the term
"UNIX" ... for instance, it's never correct to say "UNIX-like" since it
must never be hyphenated.

/jordan

Keith Bostic

unread,
Jul 9, 1993, 10:13:35 AM7/9/93
to

I've never heard of any such arrangement. I believe that
USL/AT&T/Novell is required to credit the University of
California for the 4BSD software that they ship, and I don't
think that they do.

My favorite is the System V ABI that includes a member of the
CSRG's birthday (as a file system magic number), but fails to
mention the University of California in any way.

--keith

Raymond Shwake

unread,
Jul 8, 1993, 10:06:33 PM7/8/93
to
s...@kithrup.com (Sean Eric Fagan) writes:

>In addition, the fact is, the trademark on "UNIX" *is* disputed. Just
>one person saying he believed otherwise is enough to cause some suspicion,
>and there are undoubtedly many, many others who feel the same, just as
>there are almost certainly some who do not associate "UNIX" with USL.

In fact, the UNIX trademark *is* legally sanctioned and recognized
in most countries through the appropriate national authorities. Most, but
not Japan. (I seem to recall a legal fight in Japan involving a boom box
carrying the UNIX label.)

According to "UNIX(R) SYSTEM TRADEMARK GUIDELINES" published some
years back by AT&T:

"The following notice, rather than a trademark notice, should be
used in Japan as a footnote in association with the first
appearance of the trademark:

"Developed and Licensed by AT&T"

No material should be used in Japan which carries any of the
trademark notices discusse above. Any existing trademark
identification must be expunged from all material before
being used in Japan."
--

uunet!media!irscscm!nearside!shwake shwake@rsxtech

Rick Kelly

unread,
Jul 12, 1993, 2:23:12 AM7/12/93
to


All the OS packages sold as UNIX (SCO,Dell,ISC,ESIX,SUN,etc) are sold
by companies who have paid USL the approximately $150000 in license
fees to get the source and use the name. This also includes OSF, NeXT,
and other Mach based systems.

--

Rick Kelly rmk%rmk...@merk.com merk!rmkhome!rmk r...@frog.UUCP

Rick Kelly

unread,
Jul 12, 1993, 2:39:37 AM7/12/93
to

Ah, but some of the SVR4 stuff snuck in under a Sun copyright.

Gordon Burditt

unread,
Jul 12, 1993, 8:44:31 PM7/12/93
to

So what are the consequences of "improper" usage?

(1) The Phone Police come and take you away.

(2) Your high-school English teacher takes back your diploma.

(3) "UNIX-like" is NOT a trademark of anything and I can use it any
way I darn please regardless of what anyone's lawyers say.

Can I trademark "UNIX is a trademark of USL", "UNIX is a trademark of
AT&T", "UNIX is a trademark of Western Electric" and '"Unix is a trademark
of USL" is a trademark of Gordon Burditt' ?

Incidentally, the last license I actually was required to sign (V6 or
V7), or for that matter, even saw, required me to note that "UNIX is a
trademark of Western Electric". They have not notified me that anything
changed, so what's this "AT&T" and "USL" crap? :-) If the contract says
that in writing, am I supposed to violate it on rumors that the trademark
has changed hands?

Gordon L. Burditt
sneaky.lonestar.org!gordon

J Greely

unread,
Jul 13, 1993, 5:26:32 PM7/13/93
to
In article <9307120123.17@rmkhome.UUCP> r...@rmkhome.UUCP (Rick Kelly) writes:
>All the OS packages sold as UNIX (SCO,Dell,ISC,ESIX,SUN,etc) are sold
>by companies who have paid USL the approximately $150000 in license
>fees to get the source and use the name. This also includes OSF, NeXT,
>and other Mach based systems.

So what does that have to do with the price of sausage? My point is
that the general public (those that use bookstores, anyway) sees books
on a whole bunch of different products (some involving USL licenses,
some not), all filed under the general category of "Unix", with no
trademark symbol in evidence. At least one extremely popular (and
often referenced) "Unix" book carries no external declaration of
trademark status. What are bookstore employees and customers supposed
to think?

Dick Dunn

unread,
Jul 14, 1993, 3:59:29 AM7/14/93
to
bos...@toe.CS.Berkeley.EDU (Keith Bostic) writes:
[discussion of copyright stuff--Vern Schryver, Doug Gwyn]
>...I believe that

>USL/AT&T/Novell is required to credit the University of
>California for the 4BSD software that they ship, and I don't
>think that they do.

One wonders if AT&T has some generic problem in respecting other folks'
copyrights. I remember a former office-mate working on some X joint
project with AT&T, and nearly going ballistic when he saw the AT&T folks
yanking MIT copyrights out of source files as they moved them around. I
don't want to paint AT&T with a broad brush...there are good folks and bad
folks, but it seems not too difficult to find sleazy subcultures.

It's not as if it's a big deal to retain either Berkeley or MIT copyright
notices; they don't require anything more than acknowledgment and common
decency. I wonder what the folks who were trashing copyright notices were
afraid of...and yes, the hypocrisy is pretty blatant.
--
Dick Dunn r...@eklektix.com -or- raven!rcd Boulder, Colorado USA
...Simpler is better.

David E. Wexelblat

unread,
Jul 14, 1993, 1:40:04 PM7/14/93
to

Please don't generalize like this. For one thing, AT&T policy on such things
make this a dismissable offence, as far as I know.

Second, even if AT&T allowed people to get away with such things, NOT all
AT&T employees think this way. Take a look at XFree86. We are extremely
careful with both copyright issues and author/originator credit. And the
policies that keep this happening were largely at MY insistence, an AT&T
employee.

If I worked in a culture where ripping off other people's work was condoned,
do you think I'd be so careful about preserving copyrights? Or, if you
want to say "that's you, not AT&T", that I would continue to work at a
company that condones such things? Take a look at our code. XFree86 is
derived from Thomas Roell's X386, but it has evolved in many, many areas.
Yet all of Thomas' code retains his copyright. And derivative code lists
Thomas and the new author(s) as copyright holders.

Just because companies sometimes employee people with, ummm, "loose" ethics
doesn't mean that the company itself, or everyone who works for it, has
the same ethical problems.

--
David Wexelblat <dw...@mtgzfs3.att.com> (908) 957-5871 Fax: (908) 957-5305


AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ 07748

XFree86 requests should be addressed to <xfr...@physics.su.oz.au>

"Just remember that the gold's for us to capture all we want" -- Yes, Your Move

Rick Kelly

unread,
Jul 17, 1993, 5:07:14 PM7/17/93
to

I have never seen a commercially published Unix/UNIX book that didn't
have a declaration of the USL/AT&T trademark on the same page as the
publishing copyright.

Obviously, USL needs to be more strident about protecting their rights.

J Greely

unread,
Jul 20, 1993, 1:59:05 AM7/20/93
to
In article <9307171607.14@rmkhome.UUCP> r...@rmkhome.UUCP (Rick Kelly) writes:
>I have never seen a commercially published Unix/UNIX book that didn't
>have a declaration of the USL/AT&T trademark on the same page as the
>publishing copyright.

I have: the V10 manuals. Also, as with _The UNIX Programming
Environment_, the cover and spine have no (R) or TM. The interior
title page does have an (R), but does not say who owns it. Gosh, if
we can't trust the folks at Bell Labs to get it right, who *can* we
trust?

>Obviously, USL needs to be more strident about protecting their rights.

...or at least more consistent.

Reply all
Reply to author
Forward
0 new messages