UNIX began as source code. The operating system developed at Bell Labs spread because that source could be studied, modified, and adapted to new machines. That freedom to modify UNIX helped produce a growing family of related systems, with different branches developing for different machines, markets, and purposes. By the 1980s, UNIX was no longer a single operating system moving along a single path.

That fragmentation also complicated what it meant for an operating system to be UNIX. Some systems could trace their development directly back to Bell Labs UNIX. Others could implement interfaces defined by standards such as POSIX without sharing that ancestry. UNIX would also become a certification and trademark applied to systems meeting a defined specification. Source lineage, compatibility, and the UNIX name were becoming separate questions.

There was another possibility. If the important interfaces and behavior of UNIX could be described, developers could reproduce them without using UNIX source code at all. Such systems could be Unix-like: built around many of the same concepts and interfaces without becoming another branch of the original UNIX source tree. That distinction became increasingly important as UNIX ideas spread beyond systems descended directly from Bell Labs.

Commercial UNIX systems continued the original source lineage. Standards increasingly defined what software could expect from a Unix environment, and independent projects could pursue Unix compatibility without UNIX ancestry at all. Following these paths separately helps explain how UNIX became both a family of operating systems and a model that extended far beyond its original source code.

UNIX by Code

The oldest meaning of UNIX is also the most straightforward: an operating system belongs to the UNIX family because its development can be traced back to the operating system created at Bell Labs. This is UNIX as a source-code lineage. Later systems may differ substantially from early UNIX, but there is still a historical path connecting their development.

That lineage began branching early. UNIX source moved to universities, computer manufacturers, and other organizations, where it was adapted to different hardware and different needs. Changes accumulated, features moved between branches, and vendors eventually developed distinct commercial products. UNIX became less like a single operating system with successive versions and more like a family whose members shared an ancestor.

Source ancestry does not mean that a later system must still contain some particular percentage of the original Bell Labs code. Operating systems are continually maintained and rewritten. Drivers disappear with obsolete hardware, subsystems are replaced, interfaces are redesigned, and old implementations give way to new ones. After decades of development, asking how much original code remains can tell us less about the relationship than asking how the system developed.

A family tree tells us where a system came from; it does not mean that everything in that system came exclusively from one branch.

The branches did not remain isolated either. Commercial UNIX systems could incorporate ideas and technology associated with both AT&T UNIX and BSD. Later standards encouraged common interfaces across systems with increasingly different internals. A family tree tells us where a system came from; it does not mean that everything in that system came exclusively from one branch.

System V and Commercial UNIX

One of the most important lines ran through AT&T’s System V. As AT&T moved UNIX further into the commercial market, System V became a major branch of UNIX development and an important foundation for commercial UNIX systems during the 1980s and 1990s.

Computer manufacturers of this period commonly developed operating systems around their own hardware. UNIX gave vendors an established operating model and software environment while leaving room to optimize the system for particular machines and customers. The result was not one commercial UNIX, but an ecosystem of related products.

Some of the most important commercial UNIX systems included:

• AIX
• SunOS and Solaris
• HP-UX
• IRIX
• Tru64 UNIX
• SCO UNIX and OpenServer

These systems shared UNIX ancestry, but they were not interchangeable releases of the same operating system. Vendors differentiated them through administration tools, filesystems, networking, graphical environments, hardware support, and features aimed at their particular markets. UNIX on a graphics workstation could look quite different from UNIX running business applications on a large enterprise server.

The commercial UNIX market eventually contracted, but its branches did not all meet the same fate. Some continued as specialized enterprise systems. Others passed through acquisitions into new companies or disappeared along with the hardware platforms and companies that had supported them.

AIX

IBM’s AIX became closely associated with IBM’s workstation and enterprise hardware. Rather than disappearing as UNIX declined on general-purpose computers, AIX remained in the enterprise market and eventually became centered on IBM’s POWER systems.

UNIX did not need to dominate the broader operating-system market for AIX to remain useful. Customers with established systems could value stability, compatibility, vendor support, and the ability to continue running existing workloads already built around the platform.

SunOS and Solaris

Sun Microsystems followed a different path. Its early SunOS releases were strongly connected to BSD. Solaris represented Sun’s move toward System V and eventually combined technology and ideas from both sides of the UNIX family.

Solaris became one of the most visible commercial UNIX systems of the workstation and server era. Sun paired the operating system closely with its SPARC hardware while also supporting other architectures, including x86.

Sun was eventually acquired by Oracle, bringing Solaris with it. The Solaris story also continued outside its commercial owner. Open-source work surrounding OpenSolaris contributed to illumos, from which several operating systems continue the Solaris-derived tradition.

Other Commercial UNIX Systems

Not every important commercial UNIX needs its own complete history here. HP-UX, IRIX, and Tru64 UNIX show how closely commercial UNIX could become tied to a manufacturer’s hardware and business.

These included:

• HP-UX
• IRIX
• Tru64 UNIX

Their histories differ, but they shared a problem as the market changed. Proprietary workstation architectures declined and the computer industry consolidated, making separate UNIX implementations harder to justify. Some systems retained specialized customers for years. Others eventually reached the end of active development.

SCO and UNIX on Intel

The Santa Cruz Operation occupied another interesting part of the commercial UNIX market. SCO concentrated heavily on bringing UNIX to comparatively inexpensive Intel-based systems. Businesses could run multiuser UNIX applications without purchasing one of the proprietary workstation or server platforms associated with many other UNIX vendors.

SCO’s UNIX business eventually passed to Caldera, a company already known for selling Linux. Caldera had also experimented with making Linux installation friendlier: one of its graphical installers let you play Tetris while waiting for the installation to finish.

Sometimes computing history includes waiting for Linux to install while playing Tetris.

Caldera later renamed itself The SCO Group. For the UNIX lineage we are following here, that is where we can leave the branch.

UNIX by Standards

Source lineage tells us where an operating system came from. It does not necessarily tell us how software written for that system will behave. As UNIX divided into competing implementations, differences between those systems created a practical problem. Software developers needed a common set of interfaces they could rely upon even when the underlying operating systems came from different branches.

Standards addressed that problem without requiring common source code. They could define the interfaces and behavior an operating system was expected to provide. Different operating systems could then implement those interfaces in their own ways.

UNIX ancestry and UNIX compatibility are not the same thing.

UNIX ancestry and UNIX compatibility are not the same thing. A system descended from Bell Labs UNIX could have genuine UNIX ancestry while differing from later standards. Another system could implement standardized Unix interfaces without containing UNIX source code at all.

POSIX

POSIX, the Portable Operating System Interface, developed as an effort to define a common interface that software could expect across operating systems. Rather than defining how an operating system had to work internally, POSIX concentrated on interfaces visible to programs and users. Software could rely upon defined behavior instead of the peculiarities of a particular vendor’s UNIX.

Among the areas standardized by POSIX are:

• Process management
• Files and directories
• Signals
• Shell behavior
• Command-line utilities
• Programming interfaces

Two operating systems can implement the same POSIX interfaces while using very different code internally. POSIX could therefore improve portability across an increasingly diverse UNIX family without requiring every implementation to descend from UNIX source.

Windows NT provides an interesting example. I remember wondering why Microsoft cared about including POSIX support in Windows NT. I also remember people describing Windows NT as a UNIX because it supported POSIX. That never seemed quite right. The difference between lineage and standards explains why.

Microsoft could implement a POSIX environment without turning Windows NT into a descendant of UNIX. POSIX described interfaces an operating system could provide; it did not prescribe where the operating system’s source code had to come from. Windows NT shows just how far the Unix interface had traveled beyond the UNIX family itself.

Microsoft continued experimenting with ways to support Unix and, later, Linux software on Windows. We will return to that history when we follow the Windows branch. For now, POSIX shows how Unix compatibility could extend beyond the UNIX family.

From POSIX to the Single UNIX Specification

POSIX was part of a broader effort to bring consistency to an increasingly fragmented Unix world. Other standards efforts were also trying to define a common operating environment, and over time those efforts converged.

POSIX and the Single UNIX Specification should not be treated as competing definitions of Unix. Today, the core volumes of the Single UNIX Specification are simultaneously the IEEE POSIX standard and the ISO/IEC 9945 standard. Much of the standardized Unix programming environment is shared between them.

The Single UNIX Specification extends that foundation into the standard used to measure conformance for UNIX systems. It encompasses the base operating-system environment along with the additional requirements needed to provide a consistent UNIX environment.

Source ancestry tells us how an operating system developed. Standards tell us whether the environment it provides meets an established specification.

Source ancestry and standards can now answer different questions. One tells us how an operating system developed. The other tells us whether the environment it provides meets an established specification.

UNIX as a Trademark

UNIX is also a trademark. The Open Group administers the UNIX trademark and operates the certification program associated with the Single UNIX Specification.

Certification is based upon conformance rather than genealogy. A product must demonstrate that it passes the applicable certification tests, and its supplier must agree to the requirements of the certification program. The Open Group can then grant the supplier a license to use the UNIX trademark with that product.

A system can have historical UNIX ancestry without currently being a certified UNIX product. Tracing source code back to Bell Labs is not what certification establishes. Certification tells us that a particular product conforms to a defined UNIX specification.

The word UNIX can describe several related but distinct relationships:

Term	Meaning
UNIX-derived	Historical or source ancestry
POSIX conforming	Implements the applicable POSIX interfaces
UNIX certified	Certified to the applicable UNIX specification and licensed to use the UNIX trademark
Unix-like	Resembles or implements the broader Unix operating model

Keeping these meanings separate clears up otherwise confusing descriptions of operating systems. Standards allowed Unix compatibility to extend beyond the original source tree. Certification gave the UNIX name a definition that did not depend solely upon tracing code back to Bell Labs.

Unix-Like Without UNIX Source

Unix interfaces could be described independently of the source code that originally implemented them. An operating system therefore did not have to descend from Bell Labs UNIX to provide a familiar Unix environment. Developers could create their own implementations of the same ideas and interfaces.

The term Unix-like is useful for this broader family. It can describe systems that follow Unix conventions, provide similar tools and interfaces, or deliberately seek compatibility without claiming UNIX source ancestry or certification. The boundary is less precise than either a source lineage or a formal standard, but the term helps separate the influence of Unix from the narrower history of UNIX itself.

Independent implementation also mattered because UNIX source was proprietary. Reproducing Unix behavior without copying that source made it possible to pursue goals that commercial UNIX vendors were not necessarily trying to achieve. One of the most consequential attempts began with the GNU Project.

GNU’s Not Unix

Richard Stallman announced the GNU Project in 1983 with the goal of developing a complete free Unix-compatible operating system. Its name, GNU’s Not Unix, deliberately captured the distinction. GNU was intended to behave like Unix, but it would be independently implemented rather than another version of UNIX.

Unix compatibility gave the project an existing model to work from. Developers did not need to invent an entirely new operating environment simply because they were writing new code. Programs, commands, programming interfaces, and established Unix practices provided a familiar target while GNU’s implementation could remain independent.

The goal also connected compatibility with software freedom. The freedoms to use, study, modify, and redistribute software were central to the GNU Project. A free Unix-compatible operating system could preserve a useful operating model without depending upon the proprietary software that implemented UNIX.

GNU was intended to behave like Unix, but it would be independently implemented rather than another version of UNIX.

GNU was not another branch of the Bell Labs source tree, and its purpose did not depend upon permission to use the UNIX trademark. The goal was to build a new operating system that provided a compatible Unix environment using freely available source code.

That is where we can leave GNU for now. The project had established its goal and shown that a Unix-like system could be built independently. How GNU attempted to complete that operating system is the next part of its story.

Summary

UNIX continued after its early fragmentation as a genuine source-code family. System V and the commercial UNIX systems carried that lineage into workstations, servers, and enterprise computing. Some branches survived in specialized markets, while others disappeared or passed through acquisitions as the commercial UNIX market contracted.

Source ancestry was no longer the only way an operating system could be related to UNIX. POSIX defined interfaces that could be implemented independently. The Single UNIX Specification and UNIX certification provided a standards-based meaning for the UNIX name. A system could share UNIX ancestry, provide standardized Unix interfaces, qualify to use the UNIX trademark, or combine those relationships in different ways.

Unix ideas could also spread without the original source code. A Unix-like system could reproduce familiar interfaces, tools, and conventions through an independent implementation. The GNU Project made that distinction explicit in its own name: GNU’s Not Unix. Its goal was not another proprietary UNIX descendant, but a complete free operating system compatible with Unix.

UNIX had become more than a line of source code descending from Bell Labs. It was a historical family, a standardized environment, a certified name, and a model for independently developed Unix-like systems. Keeping those meanings separate gives us a clearer way to follow the operating-system families that developed from them.