Last week, we looked at how software distribution and licensing shape what can be done with software after it has been written. Proprietary software, shareware, free software, permissive licenses, and copyleft licenses provide different answers to questions about who can use, modify, and redistribute code. Those choices can affect not only individual programs, but the communities and systems that grow around them.

UNIX gives us an opportunity to see those effects across an entire family of operating systems. AT&T licensed UNIX source code to universities and computer companies, allowing different organizations to study, modify, and adapt the system under the terms of those licenses. That helped UNIX spread, but it also helped create distinct branches as licensees developed UNIX for different hardware, customers, and purposes. Licensing continued shaping those branches: Berkeley eventually worked to remove AT&T-controlled code from BSD so that its own work could be distributed more freely. Licensing did not merely determine who could receive UNIX. It helped shape what the UNIX family became.

The code did not travel alone. As the UNIX family grew, ideas and capabilities moved between its branches, and eventually UNIX concepts traveled beyond systems descended from AT&T source. New operating systems could reproduce UNIX interfaces and conventions without containing UNIX code. The ideas had begun to spread farther than the code.

That success created a new problem. If UNIX could refer to descendants of the original source, systems assembled from different UNIX traditions, and independently developed systems that behaved like UNIX, what did it mean for an operating system to be UNIX? Standards such as POSIX emerged as part of the answer, defining common interfaces across an increasingly diverse UNIX and Unix-like world.

UNIX Leaves Bell Labs

UNIX began at Bell Labs, but it did not stay there. During its early development, AT&T operated under restrictions that limited its ability to enter the computer business. Instead of treating UNIX like a conventional commercial software product, AT&T made it available under license to universities, government organizations, and eventually commercial organizations. Many of those licenses provided access to the source code.

That gave UNIX an unusual path outward. Organizations receiving the source did not merely receive an operating system they could run. They could study it, adapt it to their computers, and develop it for their own purposes. As more organizations did so, UNIX was becoming something larger than the system being developed at Bell Labs.

Licensing Lets the Code Travel

Source access became particularly useful because UNIX had already gained another important characteristic: portability. Rewriting much of UNIX in C reduced its dependence on the assembly language of one particular computer. Moving UNIX to another architecture still required work, but it no longer meant rewriting the entire operating system for every new machine.

Licensing and portability solved different parts of the same problem. Portability allowed UNIX to move between computers; licensing allowed its code to move between organizations. Together, they made it possible for UNIX to appear on hardware and in institutions far removed from Bell Labs.

Portability allowed UNIX to move between computers; licensing allowed its code to move between organizations.

Those organizations did not all need the same operating system. Universities could experiment with UNIX and develop new capabilities. Computer manufacturers could adapt it to their own hardware and customers. Other organizations could modify it around their particular requirements. Once those changes began accumulating independently, UNIX no longer had to develop in only one direction.

The licenses that helped UNIX spread also created the conditions for different branches to develop. Organizations could begin with related AT&T code and produce increasingly different systems. UNIX was becoming a family because its source had been allowed to travel.

Berkeley Builds on UNIX

One of the most important destinations was the University of California, Berkeley. Berkeley began working with licensed UNIX in the 1970s and distributed additions and modifications as the Berkeley Software Distribution, or BSD. Over successive releases, those changes became increasingly substantial.

Berkeley contributed tools and operating-system capabilities that would become important well beyond the university. Its networking work became particularly influential as UNIX systems became connected to networks and eventually to the growing Internet. BSD was no longer simply a few local modifications to UNIX; it had become a major branch of UNIX development.

At this stage, however, BSD was still a branch in the literal sense. It had grown from licensed UNIX source, and its distributions contained AT&T-controlled code. Receiving Berkeley’s additions did not erase the licensing requirements attached to the UNIX code underneath them.

That distinction will become increasingly important as we follow the UNIX family. BSD was not merely an operating system designed to resemble UNIX. Its history ran directly through the original UNIX source tree.

Licensing Pushes BSD Toward Independence

The same licensing arrangement that allowed Berkeley to build on UNIX also placed limits on how Berkeley could distribute the resulting system. Berkeley could make its own work available under its own terms, but it could not simply treat AT&T’s portions of the operating system as Berkeley code.

That gave Berkeley a reason to separate the two. Developers progressively replaced AT&T-controlled portions of BSD with implementations that could be distributed under Berkeley’s terms. What had begun as modifications to licensed UNIX gradually moved toward a system that no longer required the original AT&T source to function.

Licensing gave Berkeley access to UNIX code. The restrictions attached to that code later gave Berkeley a reason to replace it.

The process took years and eventually became part of a larger legal dispute over UNIX and BSD code. We will return to that history when we follow the BSD family itself. Here, the important point is the relationship between the two developments: AT&T’s licensing helped create the BSD branch, while the restrictions attached to AT&T code helped give Berkeley a reason to remove that code.

BSD therefore shows why the UNIX family cannot be understood as a simple tree. UNIX source traveled outward and created a new branch, but that branch began replacing parts of the code from which it had grown. Meanwhile, AT&T and commercial vendors continued UNIX development along other paths. The code had spread, and the branches were beginning to take on lives of their own.

AT&T Builds the Commercial UNIX Line

While Berkeley was developing BSD, UNIX continued changing at AT&T. Changes in AT&T’s business environment opened the way for the company to treat UNIX more directly as a commercial product. That created another major path for the code that had begun at Bell Labs.

The result was not simply an AT&T operating system competing with BSD. Computer manufacturers wanted UNIX for their own hardware, and AT&T’s commercial UNIX became a foundation on which vendors could build. The UNIX family expanded across machines ranging from workstations to larger commercial systems.

From Research UNIX to System V

The UNIX developed at Bell Labs had gone through a series of Research UNIX editions, but AT&T increasingly consolidated work intended for commercial use. UNIX System III, released outside Bell Labs in 1982, brought together development from several earlier AT&T UNIX efforts. It was followed in 1983 by UNIX System V.

System V became the principal commercial UNIX line associated with AT&T. It continued through several releases, adding capabilities while providing a common starting point for commercial UNIX implementations. Vendors could license AT&T technology and adapt UNIX to the computers and markets they served.

This produced another kind of UNIX branch. Berkeley had grown from a university research environment, while commercial vendors built systems around particular hardware platforms and customers. The underlying UNIX code could be related even when the resulting operating systems were sold by different companies for very different machines.

IBM Builds AIX

IBM entered the UNIX family with AIX. Like other vendor UNIX systems, AIX was not simply AT&T UNIX with a different name. IBM developed it around its own hardware and enterprise requirements while drawing from established UNIX traditions.

AIX 3 shows how those traditions were already beginning to overlap. Its foundation drew from AT&T System V while incorporating features associated with BSD. IBM could build a commercial UNIX whose source history ran through the AT&T line while also adopting capabilities developed elsewhere in the UNIX family.

AIX also demonstrates how far UNIX had moved into commercial computing. AT&T code could provide the foundation, while a major computer manufacturer developed that foundation into its own long-lived operating system.

Hewlett-Packard Builds HP-UX

Hewlett-Packard followed a similar path with HP-UX. Early HP-UX development drew from AT&T UNIX, including System III and later System V, as Hewlett-Packard adapted UNIX to its own computer systems.

HP-UX also incorporated capabilities associated with BSD, including networking interfaces that had become important in the Berkeley branch. Its history therefore cannot be understood simply by drawing a line from AT&T and ignoring the rest of the UNIX family.

AIX and HP-UX show why the spread of UNIX was different from distributing identical copies of one operating system. Vendors received UNIX technology, adapted it to their hardware, selected capabilities useful to their customers, and continued developing their systems over many years. The AT&T code provided ancestry, but it did not require every descendant to remain the same.

Sun Crosses the Major UNIX Traditions

Sun Microsystems makes the relationship between the major UNIX branches even clearer. Early SunOS was strongly rooted in the BSD tradition. Sun became an important commercial home for technology that had developed through Berkeley rather than primarily through AT&T’s System V line.

Sun later worked with AT&T as the major UNIX traditions began moving back toward one another. Its operating-system line would eventually move from the earlier BSD-derived foundation to one based on System V Release 4.

Sun therefore crossed between two of the most important UNIX traditions. A company whose operating system had been rooted primarily in BSD became directly involved in bringing BSD and System V technology together.

The same pattern was already visible in AIX and HP-UX. UNIX systems had distinct histories, but those histories no longer developed in isolation. The family tree was beginning to acquire connections between its branches.

The UNIX Tree Becomes a Web

A family tree is useful for showing where an operating system came from. AT&T UNIX led to multiple lines of development, Berkeley built BSD from licensed UNIX source, and vendors developed their own commercial systems. If each branch had continued independently, a tree might be enough to describe the UNIX family.

That is not what happened. Once different groups began improving UNIX for their own purposes, useful work could travel between them. The UNIX source had created branches, but the branches began contributing back to the larger UNIX world. Ancestry still mattered, but ancestry alone could no longer explain what was inside a particular UNIX system.

BSD Technology Travels Back Out

Berkeley had received UNIX code through AT&T licensing, but Berkeley did not simply consume what Bell Labs produced. Researchers and developers added their own tools and capabilities, and some of that work became valuable to UNIX users outside Berkeley.

Networking is one of the clearest examples. BSD became an important home for the development and implementation of TCP/IP networking, along with the sockets interface applications could use to communicate over networks. As networking became increasingly important, BSD-derived networking technology appeared in commercial UNIX systems as well.

The direction had reversed. AT&T code traveled outward to Berkeley, where it helped create BSD. Technology developed in the BSD branch then traveled outward again and became part of systems whose primary lineage ran through commercial UNIX.

AIX and HP-UX already gave us examples of that mixture. Both belonged to the commercial UNIX world while incorporating capabilities associated with BSD. A system could have one primary ancestry while containing technology that had traveled through another branch of the family.

A UNIX family tree can show ancestry. It cannot show every movement of technology between the branches.

Xenix Adds Another Path

Microsoft also participated in the early commercial UNIX world. It licensed UNIX from AT&T and developed Xenix, which was adapted to several hardware platforms and eventually became closely associated with the growing market for microcomputers.

Xenix developed along its own commercial path and incorporated technology from more than one UNIX tradition. Microsoft eventually shifted its operating-system attention elsewhere and transferred ownership of Xenix to the Santa Cruz Operation in 1987. Xenix nevertheless remained part of the larger UNIX story because UNIX technology had continued developing there outside AT&T.

That became important when several of these paths met again. Xenix was not a dead branch disconnected from the rest of the UNIX family. Technology associated with it became one of the ingredients considered when AT&T and Sun attempted to bring major UNIX traditions back together.

System V Release 4 Recombines the Family

By the late 1980s, the existence of competing UNIX variants had become a problem as well as a sign of UNIX’s success. Different vendors and development traditions had produced systems with different capabilities and interfaces. Shared ancestry did not guarantee that software or administrative knowledge would transfer cleanly between every member of the UNIX family.

AT&T and Sun collaborated on System V Release 4, released in 1989. SVR4 brought together technology from several important UNIX traditions, including AT&T System V, BSD, and Xenix. Rather than representing another clean split in the family tree, it deliberately recombined work that had developed along different paths.

Sun’s operating-system history makes that crossing particularly visible. Earlier SunOS had been rooted primarily in BSD. The later SunOS 5 foundation used for Solaris 2 was based on SVR4, moving Sun onto a system that combined the AT&T System V tradition with technology that had traveled through BSD and other UNIX branches.

A simple family tree was no longer enough. A tree can still tell us something important about ancestry, but it cannot show every movement of code between related systems. UNIX had become a web: code traveled outward, branches developed independently, and useful work could cross between those branches or be brought together again.

Where Did the Original AT&T UNIX Go?

With UNIX code spreading through so many branches, it is easy to lose track of the line AT&T itself continued developing. That line did not disappear with System V Release 4. Instead, the UNIX business and the rights associated with it began passing between companies.

AT&T placed its UNIX business in Unix System Laboratories, or USL, which continued developing and licensing System V. UnixWare emerged from Univel, a joint venture between USL and Novell, and was built on the System V Release 4 lineage. Novell acquired USL in 1993, bringing both the AT&T commercial UNIX business and UnixWare under Novell.

In 1995, Novell transferred its UnixWare operating-system business to the Santa Cruz Operation, commonly known as SCO. The transaction did not amount to a simple transfer of everything associated with the word UNIX. Novell retained important rights and continued receiving revenue associated with older UNIX System V source licenses, while SCO received the UnixWare business and continued developing and selling UNIX systems. Those distinctions would become important years later when ownership of UNIX copyrights became part of the SCO litigation.

The business changed hands again. The original Santa Cruz Operation sold its server software and services divisions, including UnixWare and OpenServer, to Caldera Systems in 2001. Caldera later adopted the SCO name. After bankruptcy and further transfers, the UnixWare and OpenServer product line eventually reached Xinuos, which continues that commercial operating-system lineage today.

The UNIX name followed a different path. UNIX became increasingly defined through standards rather than ownership of AT&T’s operating-system source, and responsibility for the UNIX trademark passed from Novell to X/Open in the 1990s. X/Open later became part of The Open Group. Ownership of a particular UNIX-derived codebase, historical rights associated with System V code, and the right to certify an operating system under the UNIX trademark are therefore different things.

When following UNIX history, ask which relationship you mean: source ancestry, ownership of a particular codebase, compatibility with a standard, or the right to use the UNIX trademark. They are not the same thing.

AT&T left the UNIX operating-system business without bringing the UNIX story to an end. Its code had already spread throughout the family, its own commercial lineage continued through other companies, and the UNIX name was becoming separated from any single implementation. There was no longer one piece of code we could point to and say that everything called UNIX had to descend from it.

UNIX Ideas Spread Beyond UNIX Code

By the 1980s, UNIX had spread far beyond Bell Labs. AT&T source could be found in university systems, commercial UNIX products, and vendor-specific branches. Code developed in one branch could cross into another, making the UNIX family increasingly difficult to describe as a simple tree.

But source code was no longer the only thing spreading. UNIX had been studied, taught, documented, and used for years. Developers understood many of its interfaces and conventions, and programmers had learned to expect a particular kind of operating environment. It was becoming possible to reproduce the ideas behind UNIX without inheriting the original AT&T code.

That creates a different relationship to UNIX. BSD, System V, AIX, and HP-UX can be followed through source ancestry. Other systems could instead connect to UNIX through compatible interfaces, familiar tools, architectural ideas, documentation, education, or influence.

MINIX Recreates a Unix-like System

Andrew Tanenbaum developed MINIX as a small Unix-like operating system for teaching operating-system concepts. Earlier UNIX source had been used in university operating-systems courses, but AT&T licensing restrictions eventually made that increasingly difficult. Tanenbaum responded by writing a new system from scratch that could provide a Unix-like environment without using AT&T’s UNIX source.

MINIX was therefore fundamentally different from early BSD. Berkeley began with licensed UNIX code and gradually worked toward replacing the portions controlled by AT&T. MINIX was a complete rewrite: neither its kernel nor its utility programs contained AT&T code. Its source could be studied without inheriting the licensing restrictions attached to UNIX source.

The distinction matters because it shows another way UNIX could spread. A developer no longer needed the Bell Labs implementation itself to reproduce important parts of the UNIX operating model. UNIX had become an idea that could be independently implemented.

Similar behavior does not establish source ancestry. A system can reproduce UNIX interfaces and ideas without containing UNIX code.

MINIX also became important for another reason. Its availability on personal computers put a Unix-like operating system in the hands of students and programmers who might never have had access to a commercial UNIX workstation or institutional UNIX system. One of those users was a Finnish computer-science student named Linus Torvalds.

GNU Sets Out to Replace UNIX Without Copying It

MINIX was not the only project demonstrating that UNIX ideas could exist independently of UNIX source. In 1983, several years before MINIX appeared, Richard Stallman announced the GNU Project. His goal was ambitious: build a complete free software system that would be compatible with UNIX without simply being UNIX.

The distinction was deliberate. GNU stands for “GNU’s Not Unix.” Stallman’s original announcement described a system intended to run UNIX programs while remaining its own implementation. Instead of requiring users to depend on proprietary UNIX software, GNU would recreate the operating environment with software that users could run, study, modify, and redistribute.

UNIX compatibility made that goal practical. Developers did not have to invent every interface from scratch or design an entirely new operating environment before separate pieces could work together. UNIX already provided a model for shells, compilers, utilities, libraries, and other components. Compatible replacements could be developed independently while still following expectations established by UNIX.

GNU therefore represents another way UNIX spread without AT&T source. The project was not trying to continue AT&T’s UNIX product line. It was building a different implementation around many of the same interfaces and expectations.

By 1990, GNU had found or written all of the major components it needed except the operating-system kernel. GNU’s operating environment was already well developed, but its own kernel was not yet ready to complete the system. GNU had nearly recreated the UNIX operating environment without inheriting UNIX itself.

From MINIX to Linux

Meanwhile, Linus Torvalds was using MINIX on an Intel 386 computer. He began experimenting with the processor and gradually developed what became an independent operating-system kernel. MINIX provided the environment in which that early work took place, but Torvalds was not modifying MINIX into a new operating system.

The distinction is important: influence is not ancestry. MINIX provided Torvalds with a Unix-like environment, tools, documentation, and a community in which early Linux development could take place. Linux itself was independently written rather than a new branch of the MINIX source tree.

Influence is not ancestry.

On August 25, 1991, Torvalds announced his new operating-system project to the comp.os.minix community. He described a free operating system for 386 and 486 computers and asked MINIX users what features they would like to see. He also made clear that the new system contained no MINIX code. The relationship between MINIX and Linux was real, but it was a relationship of environment and influence rather than inherited source.

Torvalds initially considered the name Freax for the project. When the early files were placed on an FTP server, Ari Lemmke instead used Linux for the directory, and that was the name that survived. The kernel would soon grow far beyond the experiments that produced it, but that belongs to a later part of our story.

For now, GNU and Linux should remain separate. GNU was an established effort to build a complete free Unix-compatible operating system. Linux was a newly written Unix-like kernel emerging from experiments performed in a MINIX environment. Neither needed AT&T UNIX source for UNIX ideas to reach it.

UNIX had first spread because organizations could obtain its code. Now systems could join the broader Unix-like world without inheriting that code at all. The code had created a family; the ideas had escaped the family tree.

What Is UNIX?

By the beginning of the 1990s, the question “What is UNIX?” no longer had a simple answer. Some operating systems descended directly from AT&T source. Others combined code and capabilities from several UNIX branches. Still others, such as MINIX, GNU, and Linux, were being independently developed around UNIX interfaces and ideas without inheriting the original UNIX source.

Shared ancestry was no longer enough to describe the larger UNIX world. Two systems could descend from UNIX and behave differently, while another system could contain no original UNIX code and deliberately provide many of the same interfaces. If software developers wanted their programs to move between these systems, they needed something more useful than a family tree.

They needed agreement about how a Unix-like operating system should behave.

POSIX Defines Common Interfaces

Efforts to standardize UNIX interfaces had already begun while the commercial UNIX branches were developing. One of the most important results was POSIX, the Portable Operating System Interface. The first POSIX.1 standard was published in 1988.

POSIX approached the problem through interfaces rather than ancestry. Instead of requiring an operating system to contain a particular body of UNIX source code, the standard defined interfaces and behavior that software could expect an operating system to provide.

That made POSIX useful beyond systems descended directly from AT&T UNIX. The standard was intended to apply not only to systems derived from original UNIX code, but also to compatible systems developed independently, emulations hosted on other operating systems, and systems running across a broad range of hardware.

POSIX therefore provided a way to describe UNIX compatibility without requiring UNIX ancestry.

That mattered for portability. A programmer targeting standardized interfaces could depend less on the peculiarities of one vendor’s UNIX implementation. Standards could not make every UNIX and Unix-like system identical, but they could establish common ground between systems whose source histories were becoming increasingly different.

UNIX Becomes a Standard as Well as a Lineage

POSIX did not completely answer the question of what could officially be called UNIX. During the 1990s, control of the UNIX trademark became separated from the commercial operating-system code that had descended from AT&T.

As Novell moved away from the UNIX business, the UNIX trademark passed to X/Open, which later became part of The Open Group. In 1994, X/Open introduced the Single UNIX Specification, establishing a common specification against which operating systems could be measured.

This changed what UNIX could mean. An operating system no longer had to descend from a particular AT&T code stream to qualify as UNIX. What mattered for use of the UNIX trademark was conformance with the specification and certification under the UNIX branding program.

The family name had effectively separated from the family tree.

That does not make ancestry irrelevant. System V, BSD, AIX, HP-UX, Solaris, and other systems still have histories that can be traced through actual UNIX code. Source ancestry and the UNIX trademark now answer different questions. One tells us where a system came from; the other tells us whether a product has demonstrated the conformance required to use the UNIX name.

Why GNU and Linux Are Not UNIX

This helps explain something that can otherwise sound contradictory. GNU and Linux are deeply connected to the UNIX tradition, but that does not make either one a descendant of UNIX source.

In 1983, Richard Stallman announced his intention to build a complete Unix-compatible software system called GNU. GNU stands for “GNU’s Not Unix,” a recursive acronym deliberately emphasizing that the project was building a Unix-compatible system rather than continuing UNIX itself.

The distinction was practical as well as linguistic. UNIX was proprietary software, and Stallman’s purpose in creating GNU was to build a system that could be used, studied, modified, and shared without accepting the restrictions attached to proprietary UNIX. GNU could reproduce useful UNIX interfaces, tools, and behavior while implementing them independently. GNU wanted UNIX compatibility without UNIX’s licensing restrictions.

Linux reached a similar technical position by a different route. Torvalds developed Linux in a Unix-like environment and deliberately implemented interfaces associated with UNIX and POSIX, but Linux was independently written rather than derived from AT&T UNIX source. When Linux was combined with GNU tools and other software into complete operating systems, those systems could provide a Unix-like environment without acquiring a commercial UNIX source license.

By then, however, UNIX had also become a certification and trademark. A Linux-based operating system could potentially become an official UNIX system by demonstrating conformance with the Single UNIX Specification and completing The Open Group’s certification process. A small number of Linux-based systems eventually did. Most Linux distributions did not need the UNIX name badly enough to take on the cost and work of certification. Unix-like, Unix-compatible, and POSIX compatibility could describe the relationships that mattered without acquiring the right to market the product as UNIX®.

Linux can therefore follow the UNIX tradition closely without being UNIX in either of the senses we have been discussing. Linux did not inherit AT&T UNIX source, and most Linux distributions have not sought certification for the UNIX trademark. What reached Linux instead were the interfaces, conventions, tools, and ideas of the UNIX environment.

GNU and Linux therefore have a different relationship to UNIX than BSD does. BSD can point backward through source ancestry. GNU and Linux point backward through interfaces, conventions, standards, and ideas. All belong to the broader history of UNIX’s influence, but they arrived there by different paths.

UNIX, POSIX, and Unix-like Are Not the Same Thing

That history leaves several related ideas that are easy to collapse into the single word UNIX.

A system can have UNIX ancestry because its source history ultimately descends from the original UNIX code. That is the family tree we have followed through much of this article.

A system can be POSIX-conformant by implementing standardized interfaces. That relationship does not require the system to contain original UNIX source.

A product can be certified UNIX by demonstrating conformance with the applicable Single UNIX Specification and meeting the requirements for use of the UNIX trademark. UNIX in this formal sense is a certification, not simply a description of ancestry.

Finally, a system can be described more generally as Unix-like because it follows UNIX interfaces, conventions, tools, or design ideas without necessarily being descended from UNIX source or certified to use the UNIX trademark.

UNIX ancestry, POSIX conformance, UNIX certification, and being Unix-like describe different relationships. They can overlap, but they are not interchangeable.

These categories can overlap, but they are not interchangeable. A system’s source can tell us one story, its interfaces another, and its certification status another still. As UNIX spread, the meaning of the word had to expand beyond the history of one body of source code.

UNIX first spread because its code could travel. Its branches then exchanged code and capabilities with one another. Eventually its ideas and interfaces traveled beyond systems containing UNIX code at all. Standards provided a way for those increasingly different systems to share a common operating environment.

The UNIX family had become more than a family tree.

Summary

UNIX did not become a family simply because people liked the operating system and decided to imitate it. Its source code was allowed to travel. AT&T licensing gave universities and computer companies access to UNIX code they could study and adapt, while the portability UNIX gained from C made those adaptations practical across different hardware. The same licensing system also placed limits on what recipients could do with that code. Berkeley demonstrates both sides particularly well: licensing gave Berkeley access to UNIX, while licensing restrictions eventually gave Berkeley a reason to replace the AT&T-controlled portions of BSD.

Once UNIX had spread, its branches did not remain isolated. Berkeley-developed technology moved into commercial UNIX systems, vendors combined AT&T and BSD traditions with their own work, and System V Release 4 deliberately brought together technology from System V, BSD, and Xenix. The UNIX tree became a web. Even as AT&T left the UNIX business and its commercial operating-system lineage passed through other companies, UNIX technology had already spread too widely to belong to one development path.

Eventually, the ideas traveled farther than the code. MINIX demonstrated that a Unix-like system could be independently implemented for teaching. GNU deliberately pursued a free Unix-compatible system without becoming UNIX, and Linux emerged as another independent implementation shaped by the Unix-like environment around it. POSIX and the Single UNIX Specification helped separate compatibility and the UNIX name from any requirement that a system descend from one particular body of source code. UNIX ancestry, POSIX compatibility, UNIX certification, and being Unix-like could now describe related but different relationships.

That leaves us with more than one path through the UNIX tradition. Some systems can trace their history through the original UNIX source tree; others joined that tradition through interfaces, conventions, standards, and ideas instead. Over the next articles, we can follow those paths individually. We will begin with BSD, the branch that started with licensed AT&T UNIX, grew into one of the major centers of UNIX development, and eventually became independent enough to produce a family of operating systems of its own.