Last week, we followed UNIX as it grew from a Bell Labs system into a family of related systems. Portability helped UNIX cross hardware boundaries, while licensing and access to source code helped it cross organizational boundaries. Universities could study and modify the system, Berkeley could develop BSD, and commercial vendors could carry UNIX in still other directions. That leaves an important part of the story unexplained: what does it actually mean to have permission to use, copy, study, modify, or redistribute someone else’s software?

Those are not all the same permission. A program might be available without charge but prohibit modification. Another might include its source code but restrict what can be done with it. A company might sell software while allowing its customers to study, modify, and redistribute it. A developer might even encourage people to copy a commercial program as widely as possible while keeping its source code proprietary. Price, source-code availability, copying, modification, redistribution, and commercial use are related, but they describe different things.

Those distinctions are behind terms such as commercial software, shareware, Free Software, Open Source, proprietary software, permissive licensing, and copyleft. They do not describe mutually exclusive categories. Free Software can be sold, Open Source software can use a copyleft license, and shareware can encourage copying while remaining proprietary. Even two Open Source projects can use licenses that affect how easily code can move between them.

Rather than treating those distinctions only as definitions, we are going to follow them through the histories of real software. Doom will take us from proprietary commercial software through shareware and eventually into Open Source. GNU Emacs will bring us into the GNU Project, Free Software, and copyleft. BSD will show what permissive licensing allows code to become downstream. Red Hat and Debian will demonstrate different ways of building systems from freely available software. Finally, StarOffice, OpenOffice.org, and LibreOffice will show what happens when ownership and stewardship change, a community forks the code, and different licenses affect what happens afterward.

What Kind of Software is it?

Software licensing uses several terms that are often treated as though they describe mutually exclusive kinds of software. They do not. A program can be commercial and Open Source, or noncommercial and proprietary. Understanding the differences requires separating the business surrounding software from the rights its license gives to users.

Commercial Software

Commercial software is software developed, distributed, or supported as part of a commercial activity. A company might sell copies of the program, charge for subscriptions or support, bundle it with another product, or use the software as part of a larger business.

The opposite is noncommercial software: software developed or distributed without a commercial purpose. Universities, hobbyists, volunteer communities, and individual programmers have all produced noncommercial software.

Neither term tells us what users are permitted to do with the software. Commercial software does not have to be proprietary, and noncommercial software does not have to be Free or Open Source. Commercial and noncommercial describe the economic activity surrounding software, not the rights granted by its license.

Proprietary Software

Proprietary software is software whose owner retains rights that are not granted to its users. A license might permit someone to run a program while restricting copying, modification, access to source code, redistribution, or some combination of those activities.

Proprietary software is frequently commercial, which is why the two terms are sometimes treated as synonyms. They are nevertheless different concepts. A developer can distribute proprietary software without charging for it, just as a company can make money from software that gives its users much broader rights.

Free Software

Free Software describes software in terms of the freedoms given to its users. The Free Software movement defines those freedoms around the ability to run a program for any purpose, study how it works, modify it, redistribute copies, and distribute modified versions.

The word free refers to freedom, not necessarily price. Free Software can be given away, but it can also be sold. A business can charge for copies, packaging, support, integration, or other services without making the underlying software cease to be Free Software.

Source code is important because some of these freedoms cannot practically exist without it. Studying or modifying a program requires access to the human-readable code from which it was built. Merely making source code visible, however, does not automatically give someone permission to modify or redistribute it.

Open Source Software

Open Source Software overlaps substantially with Free Software. Open Source licenses make source code available and provide rights to use, modify, and redistribute the software under defined conditions. As a result, much of the software we encounter can correctly be described as both Free Software and Open Source Software.

The two terms nevertheless come from different movements and emphasize different ideas. Free Software places the freedoms of software users at the center of the discussion. Open Source places greater emphasis on licensing and the development model that allows source code to be examined, modified, and redistributed. The distinction is often one of philosophy and emphasis rather than two completely separate bodies of software.

We can use Free and Open Source Software, or FOSS, when the distinction between the two movements is not important to what we are discussing. When it does matter, as it will when we reach GNU Emacs, we will use the more precise term.

None of these terms tells us how someone actually receives a copy of the software. A proprietary commercial program might be deliberately passed from user to user, while Free and Open Source Software can be sold as part of a commercial product. How software is distributed is a separate question.

Price, source availability, distribution, and licensing answer different questions about the same software.

How Proprietary Software is Distributed

How much software costs and how it reaches a user are separate from what its license allows the user to do afterward. Software can be sold, given away, or deliberately passed from one user to another while remaining proprietary. Free and Open Source Software can likewise be given away or sold. Several distribution models became particularly important during the personal-computer era.

The most familiar model is to obtain software by paying for a copy or a license to use it. During much of the personal-computer era, that often meant buying a boxed package containing disks and documentation. Software later moved increasingly toward electronic distribution, but the basic relationship remained familiar: payment was part of obtaining the software.

Paying for software does not make it proprietary. Commercial Free and Open Source Software can also be sold. The transaction tells us how the software was distributed, not what rights came with it.

Freeware

Freeware is software distributed for use without requiring payment. It became common for developers and companies to make useful programs available at no charge, whether as complete products, promotional tools, companion utilities, or software maintained for other reasons.

The important word here is price. Freeware does not necessarily give users access to source code or permission to modify and redistribute it. A freeware program can remain completely proprietary.

This is one reason freeware and Free Software should not be confused. Freeware means that the software is available without charge. Free Software refers to freedoms granted to its users.

Shareware

Shareware uses copying and evaluation as part of the distribution model. Instead of requiring a potential customer to purchase the software before trying it, developers encouraged users to obtain copies, try the program, and pass copies to other potential users. Payment or registration could then provide additional features, additional software, documentation, support, or continued authorized use, depending on the program.

Bulletin Board Systems made this model particularly powerful. A developer did not have to manufacture and ship every copy. A shareware program could be uploaded to a BBS, downloaded by its users, passed between friends, and uploaded elsewhere. The users themselves became part of the distribution network.

Permission to copy the distributed program did not make shareware Free or Open Source Software. Shareware was commonly proprietary. Its developer could encourage thousands of people to copy a program while still withholding its source code and restricting modification.

That combination will become important when we reach Doom. It was commercial software, it was proprietary, and its shareware release was deliberately designed to be copied. None of those descriptions contradicts the others.

How Free and Open Source Software is Distributed

Free and Open Source Software created a different distribution problem. Giving users permission to copy, modify, and redistribute software made it possible for copies to travel freely, but obtaining one program was only part of the problem. A useful computer system might depend on software produced by hundreds or thousands of independent projects.

Individual Projects

Early Free and Open Source projects could distribute their own software directly. Source code might be obtained from another user, copied from physical media, or downloaded from an FTP server or project site. Because redistribution was permitted, copies did not necessarily have to come from the original developer.

This decentralized distribution was powerful, but it also left users responsible for obtaining, building, configuring, and updating software from many different sources.

Packages and Repositories

Packaging systems made that collection of independent software easier to manage. Instead of every user finding and installing each program directly from its original developer, software could be prepared as packages that described what was being installed and what other software it required.

Repositories took that idea further by collecting packages into maintained sources from which users could install and update software.

Distributions

A software distribution goes beyond simply making copies available. It selects software from many projects, integrates it, packages it, establishes defaults, provides installation and update mechanisms, and presents the result as a usable system.

This becomes especially important with GNU/Linux. Linux is the kernel, but what someone installs as a Linux distribution contains software from many independent projects: the Linux kernel, GNU utilities, libraries, shells, servers, desktop environments, applications, and thousands of other components.

The ability to redistribute Free and Open Source Software makes those larger systems possible, but it does not dictate who must assemble them or why. A volunteer community can build a distribution, and so can a commercial company. Debian and Red Hat will let us see both approaches using much of the same larger pool of software.

Source Code and the Rights That Come With It

So far, we have repeatedly mentioned access to source code, but source code is not always included when software is distributed. Most users receive a compiled program: the machine-executable form produced from source code written by programmers. They can run the program without possessing the original human-readable code used to create it.

With proprietary software, the source code is commonly kept by its developer or owner. Users receive the compiled program and whatever rights its license grants them. Even if they are permitted to copy the program—as they might be with freeware or shareware—that permission does not necessarily include access to its source.

Free and Open Source Software works differently because the ability to study and modify a program requires access to its source code. The source therefore has to be available to users entitled to those rights. This does not mean every copy must arrive with a folder full of source files beside it. A distribution can provide ready-to-run binary packages while making the corresponding source available separately.

A developer can also publish source code without granting the rights required for the software to be Free or Open Source. The code may be source available—people can read it—but its license may restrict modification, redistribution, commercial use, or other activities.

Being able to read the source is not the same thing as having permission to modify or redistribute it.

Permissive Licenses

Making software Free or Open Source does not mean giving up copyright or placing the code into the public domain. The copyright holder instead uses a license to grant other people rights to use, study, modify, and redistribute the software. Different licenses can grant those rights under different conditions.

A permissive license, such as the licenses associated with BSD, grants broad rights with relatively few requirements on what happens to modified or redistributed versions. Copyright and license notices generally have to be preserved, but the code can often be incorporated into software distributed under different terms, including proprietary commercial products.

That flexibility helps explain why BSD code has traveled so widely. A company can take permissively licensed code, modify it, combine it with its own code, and distribute the resulting product without necessarily having to release its modifications under the original BSD license.

Copyleft Licenses

A copyleft license takes a different approach. It also grants broad rights to use, study, modify, and redistribute software, but it places requirements on certain forms of redistribution so that the freedoms granted by the original license are preserved downstream.

The GNU General Public License, or GPL, is the best-known example. If GPL-covered software is modified and a covered derivative work is distributed, the GPL requires the corresponding source to be made available under the GPL’s terms. Someone can modify the software, sell it, and build commercial products with it, but cannot simply take the covered code, distribute a proprietary version of that covered work, and withhold the freedoms the GPL was designed to preserve.

Permissive and copyleft licenses therefore protect different goals. A permissive license emphasizes giving downstream developers broad freedom over what they build from the code. Copyleft emphasizes preserving particular software freedoms as the code moves downstream. Neither approach makes software inherently more or less Open Source; both permissive and copyleft licenses can qualify as Free and Open Source licenses.

Doom: From Shareware to Open Source

When id Software released Doom in December 1993, it was unquestionably a commercial product. id Software intended to make money from the game, and the complete game was proprietary software. Yet the company did something that might sound strange if commercial and proprietary software are assumed to mean tightly controlled distribution: it encouraged people to copy Doom.

What people were encouraged to copy was the shareware version. The first episode, Knee-Deep in the Dead, could spread from one player to another and across Bulletin Board Systems, while the remaining episodes were part of the registered commercial product. Instead of treating every freely copied disk or download as a lost sale, the shareware model turned those copies into advertising. Someone could play a substantial portion of Doom, give it to a friend, and potentially create another customer.

Doom was commercial because id Software was selling a product. It was proprietary because id retained control over the software and its source code. It was shareware because id deliberately permitted and encouraged redistribution of the shareware release. None of those descriptions conflicts with the others.

But Doom did not remain in that state forever.

On December 23, 1997, John Carmack released the source code for the Doom engine. The release used the Linux version rather than the original DOS code because the DOS sound support depended on the third-party DMX sound library, which was not publicly available and therefore could not be included. The game data—the levels, graphics, sounds, and other assets that made Doom the game—also remained copyrighted and were not simply given away with the engine source.

Publishing the source did not initially make Doom Free or Open Source Software in the sense we use those terms today. The original Doom Source Code License released the code for non-profit use and permitted people to examine and modify it, but it prohibited commercial exploitation and did not permit redistribution of the source itself. The source was available, but the rights attached to it were still restricted.

That changed again in October 1999, when id Software rereleased the Doom source under the GNU General Public License. The GPL allowed the engine to be used, modified, and redistributed under a copyleft license. The commercial game released in 1993 had therefore traveled through several different arrangements: proprietary software distributed partly through shareware, source code made publicly available under restrictions, and finally an engine released as Free and Open Source Software.

The results outlived the original computers for which Doom was written. Developers could port the engine to new operating systems and hardware, fix limitations, add features, and create new source ports. The original game assets still had their own copyright restrictions, so an Open Source Doom engine did not mean that the complete commercial game had suddenly become free to redistribute.

One result has become something of a tradition among programmers and hardware hackers: the Doom Test. If a device contains a processor and a display—or sometimes anything that can be persuaded to act like one—someone will eventually try to make it run Doom. The game has appeared on calculators, watches, cameras, printers, and other devices that were never intended to be gaming machines. Some of these ports are serious demonstrations of hardware and software capabilities; others exist largely because getting Doom to run somewhere unexpected is fun. The availability of the engine’s source code helped make that experimentation possible. A commercial game from 1993 became not only something people continued to play, but a familiar challenge for demonstrating what an unusual piece of hardware could be made to do.

Doom gives us a useful first lesson because the software itself changed categories while remaining recognizably the same project. How software is sold, how copies are distributed, whether its source can be seen, and what its license permits are separate properties—and each of them can change over the life of a program.

A program can change its distribution model, source availability, and license without ceasing to be the same software project.

GNU Emacs: An Editor and the Freedom to Modify It

The story of GNU Emacs begins before GNU. Its ancestry reaches back to the MIT Artificial Intelligence Laboratory in the 1970s, where Richard Stallman worked on an extensible editor built around TECO. Rather than treating an editor as a fixed collection of commands, Emacs could be customized and extended. Users could change how the editor behaved and add new capabilities instead of waiting for the original developer to provide them.

That extensibility became one of Emacs’s defining characteristics. GNU Emacs would eventually use Emacs Lisp as its extension language, allowing the editor to become considerably more than a place to type text. Email, calendars, games, development tools, and other applications could live inside Emacs. It even includes M-x doctor, a conversational psychotherapist program in the tradition of ELIZA.

By then, however, Stallman was confronting a larger problem than how a text editor should work. The cooperative software culture he had known at MIT was changing as software increasingly became proprietary and source code became less freely shared. In September 1983, he announced the GNU Project: an effort to create a complete Unix-compatible operating system whose users would be free to use, study, modify, and share its software. Development began in 1984.

GNU needed an editor, and Stallman already knew what kind of editor he wanted. He began writing GNU Emacs in September 1984. By early 1985 it was usable, and other people wanted copies.

That created an interesting distribution problem. People connected to the Internet could obtain GNU Emacs through anonymous FTP, but many potential users were not online. Stallman offered another option: for $150, he would mail GNU Emacs on tape. The software remained Free Software, and recipients remained free to copy it for someone else. What Stallman charged for was the service of providing a physical copy.

GNU Emacs therefore gives us an early example of something our terminology already allows: Free Software could also be commercial software. Charging money for a copy did not determine whether the software was Free. The freedoms accompanying that copy did.

From Sharing to Copyleft

There was still another problem. Giving someone permission to modify and redistribute software did not necessarily guarantee that those freedoms would survive into later versions. A developer could take freely available code, modify it, and distribute the resulting program under proprietary terms if the original license permitted it.

Stallman’s answer was copyleft. Instead of abandoning copyright, copyleft uses copyright and a software license to grant users broad freedoms while placing conditions on redistribution intended to preserve those freedoms downstream. Someone can use the software, study it, modify it, share it, and even sell it, but covered derivative works that are distributed must remain available under the required copyleft terms.

GNU Emacs became an important early application of that idea. Early versions used a program-specific GNU Emacs General Public License, while the licensing work surrounding GNU software eventually developed into the GNU General Public License, or GPL. GPL version 1 appeared in 1989 and provided a reusable copyleft license for GNU software and other projects. Rather than every GNU program needing its own separately written licensing arrangement, the GPL could express the same basic set of downstream requirements across many programs.

This is the central difference between simply releasing source code and using copyleft. Source availability makes it possible to examine code. Permission to modify it makes further development possible. Copyleft adds the requirement that particular freedoms accompany covered code as it continues downstream.

Copyleft is not merely permission to modify code. It is a way of making particular freedoms travel downstream with covered code.

Emacs and vi

GNU Emacs also entered one of computing’s longest-running arguments: Emacs versus vi. The two editors grew from different traditions. vi came from Bill Joy’s work at Berkeley and the BSD world, while GNU Emacs became closely associated with GNU and Free Software. Their different interfaces and philosophies inspired decades of arguments over which editor programmers ought to use.

Plenty of users simply found something that worked for them. I largely avoided the Emacs-versus-vi argument by using Pico. As GNU/Linux distributions became more important, however, Pico’s license became a problem. Debian treated Pine and Pico as non-free, and the license did not permit Debian to distribute modified binaries, so users had to build the software from source and Debian’s patches rather than install it as a normal binary package. I moved to JOE instead.

By the time nano appeared as a GPL-licensed Free Software replacement for Pico, I had already moved on from that family of editors. The appearance of nano nevertheless demonstrates the practical effect of the licensing problem. Pico remained a useful editor, but its license affected whether distributions could package and redistribute it under their rules, and the resulting gap helped create demand for a Free Software replacement.

The editor war is mostly computing culture, but the histories behind the editors bring us back to licensing. GNU Emacs shows one answer to the question of what should happen when freely modifiable software moves from one developer to another: the freedom to modify the code should travel with the code. BSD, coming from the other side of the old editor rivalry, will give us a different answer.

BSD: Code That Was Free to Travel

The other side of the old Emacs-versus-vi rivalry brings us back to Berkeley. vi was created by Bill Joy as part of the software work surrounding the Berkeley Software Distribution, or BSD. As we saw last week, BSD began as modifications and additions to AT&T UNIX at the University of California, Berkeley, and eventually became one of the major branches of the UNIX family.

BSD’s influence spread well beyond the systems that carried its name. Berkeley developed important UNIX tools and, especially with 4.2BSD, helped establish the TCP/IP networking software that became enormously influential. Commercial UNIX systems incorporated Berkeley software, while BSD itself continued developing at the university.

There was a complication, however. BSD had grown from UNIX, and early BSD distributions still contained AT&T-owned UNIX code. Receiving those distributions therefore required an appropriate UNIX source license. Berkeley could distribute the software it had written, but it could not simply give everyone the proprietary AT&T portions of the system.

By the late 1980s and early 1990s, Berkeley’s Computer Systems Research Group began separating its own work from the AT&T code. Networking Release 1 made Berkeley’s networking code separately redistributable, and Networking Release 2 pushed much farther toward a complete system. A legal dispute over portions of Net/2 was settled in 1994, after which Berkeley released 4.4BSD-Lite as an unencumbered codebase. The BSD descendants could then continue developing without depending on proprietary AT&T UNIX code.

The license Berkeley used for its own code took a different approach from the copyleft we just encountered with GNU Emacs. A BSD-style license is permissive. It grants broad permission to use, modify, and redistribute the code while imposing relatively few requirements on what a downstream developer must do with a resulting product.

Copyleft is designed to ensure that particular freedoms continue downstream when covered derivative works are distributed. A permissive BSD license allows a downstream developer considerably more discretion. BSD-licensed code can remain in an Open Source project, but it can also be incorporated into a proprietary product without requiring that all of the resulting proprietary code be released under the BSD license.

The code is not in the public domain. Copyright still exists, and BSD licenses still impose conditions, such as preserving copyright notices and disclaimers. What the license does not generally require is that someone who incorporates the code into a larger product must release that larger product’s source code under the same terms.

That choice helped BSD technology travel into some very different systems.

Product / System BSD Connection
OPNsense Built on FreeBSD
OpenBSD Forked from NetBSD
DragonFly BSD Forked from FreeBSD 4.8
macOS / Darwin BSD layer derived primarily from FreeBSD
Force10 FTOS Built on NetBSD

These are not all the same kind of system. OpenBSD and DragonFly BSD became independent Free and Open Source operating systems. OPNsense uses FreeBSD as the foundation for a specialized firewall and routing platform. Apple’s Darwin combines BSD technology with other components as the foundation beneath macOS, while Force10 used NetBSD as the foundation for a commercial network operating system.

The table only shows the immediate connection. The BSD family has a much larger and more complicated family tree, which deserves its own story. What matters here is what happened to the code after it was released under permissive terms. It could remain within Free and Open Source projects, become the foundation of new operating systems, power specialized appliances, or become part of larger commercial and proprietary products.

This is the other major answer to the downstream question. GNU’s copyleft approach says, in effect, you may build on this code, but the freedoms attached to covered code must continue with it. The permissive BSD approach says, you may build on this code, and you have broad freedom to decide how your own resulting work will be distributed.

Both approaches produce Free and Open Source Software. They differ in what kind of freedom they emphasize downstream. BSD’s history shows one consequence of the permissive choice particularly well: the code was free to travel, even into systems whose developers chose a very different licensing model for what they built around it.

Permissive licensing gives downstream developers broad freedom over what they build. Copyleft puts more emphasis on preserving freedoms as covered code moves downstream.

Debian: Building a System as a Community

The software freedoms we have been following do more than allow an individual program to be modified or redistributed. They also allow people to assemble software from many independent projects into something larger. Debian shows what can happen when a community takes responsibility for doing exactly that.

Ian Murdock founded the Debian Project in August 1993, when the idea of a Linux distribution was still relatively new. Linux provided a kernel, GNU provided many of the tools needed around it, and other Free Software projects supplied still more pieces. Turning all of those pieces into a usable operating system required someone to select them, package them, keep track of their dependencies, integrate them, distribute updates, and decide what belonged in the system.

Debian was intended from the beginning to be developed openly. Instead of belonging to a company producing a Linux product, it grew from a small group of Free Software developers into an organized international community. Individual developers became responsible for packages, while the project developed policies and technical processes for making thousands of independently developed pieces of software behave as one distribution.

That organization matters because a distribution is itself a substantial piece of engineering. Debian does not write every program it distributes. Much of its work happens between the original software project—the upstream project—and the person installing Debian. Debian developers package upstream software, describe dependencies, integrate it with the rest of the system, apply or forward fixes, test combinations of packages, and maintain repositories from which complete systems can be installed and updated.

As Debian grew, its package-management system became increasingly important to that work. Early Debian releases had relatively primitive package handling, but the project developed dpkg and increasingly detailed information about relationships between packages. A user no longer needed to treat every program as an isolated piece of software obtained directly from its developer. The distribution could manage a collection of software as a system.

Defining What Belongs in Debian

Building a Free Software distribution also created a question that compiling and packaging alone could not answer: what counts as Free Software?

In 1997, Debian adopted its Social Contract and the Debian Free Software Guidelines, or DFSG. The Social Contract states commitments the Debian Project makes to the Free Software community, while the DFSG provides criteria Debian can use when deciding whether a software license is sufficiently free for software to be included as part of Debian.

Those guidelines include requirements such as allowing free redistribution, permitting modification and derived works, and not restricting use of the software to particular people, groups, or fields of endeavor. They do not require one particular licensing strategy. Debian explicitly recognizes licenses including the GPL and BSD licenses as examples of Free Software licenses.

Debian can contain software under both copyleft and permissive licenses. The distribution does not require every component to make the same choice about downstream licensing. Instead, each component’s license must provide the freedoms necessary to satisfy Debian’s guidelines.

Software that does not meet those requirements has historically been handled in separate archive areas rather than as part of the Debian system itself. Debian can therefore help users obtain some non-free software without redefining that software as part of Debian’s Free Software distribution.

The DFSG would also have an influence beyond Debian. Bruce Perens, who drafted the Social Contract and DFSG with input from other Debian developers, later removed the Debian-specific language from the guidelines to form the basis of the Open Source Definition. A set of rules created to answer the practical question of what software Debian could include therefore became part of the larger history of the term Open Source.

A Community Can Have Descendants

Because Debian itself can be copied and modified, the distribution can also become an upstream source for another distribution. Someone does not have to begin again with the Linux kernel, GNU utilities, and thousands of unrelated projects. They can begin with Debian’s already integrated system and build something different from it.

That has produced a large extended Debian family. Among its descendants are:

  • Ubuntu
  • Linux Mint Debian Edition
  • Kali Linux

Linux Mint Debian Edition builds a general-purpose desktop system directly on Debian, while Kali Linux specializes that foundation for penetration testing and security work. The same freely redistributable base can therefore support projects intended for very different audiences.

Ubuntu adds another dimension to the story. It is built from Debian but developed with commercial backing from Canonical. Debian itself is a community project, yet the freedoms attached to its software allow a company to take that work downstream, integrate and develop it further, and build a commercially supported distribution around it.

That does not mean a company simply takes Debian and owns what came before it. The individual components retain their respective copyrights and licenses. Copyleft requirements still apply where copylefted components are involved, permissive licenses retain their own conditions, and changes can move between upstream and downstream projects when their licenses and development practices permit it.

Debian therefore gives us a different view of software distribution. A community can take thousands of independently developed Free and Open Source components, integrate them into a complete operating system, and make that integrated system available for still other communities and companies to build upon.

Free and Open Source licensing did not merely make individual programs easier to share. It made it possible for communities to assemble complete systems that could themselves become foundations for whatever came next.

A distribution can become an upstream project too. Debian is not only assembled from other projects; other distributions can begin with Debian.

Red Hat: Building a Business Around Free Software

Debian showed how a community could assemble thousands of independently developed pieces of Free and Open Source Software into a complete operating system. The same freedoms also left room for a company to do much of the same work commercially. Red Hat would demonstrate that selling a Linux distribution did not require turning Linux into proprietary software.

Red Hat’s story began in the early 1990s with Marc Ewing’s Red Hat Linux distribution and Bob Young’s ACC Corporation, which sold Linux and UNIX software and accessories. Young began distributing Ewing’s work, and the two joined forces in 1995 to form Red Hat Software.

There was an apparent contradiction in the business. Much of the software Red Hat distributed could already be copied legally. A customer did not necessarily have to buy Linux from Red Hat to obtain Linux, GNU utilities, or the many other Free and Open Source components included in the system.

That meant the value of the product could not depend entirely on controlling access to the underlying software. Red Hat could instead sell the work required to turn that software into something organizations could reliably use.

One of the less pleasant ways Linux users learned the value of that integration was RPM Hell. RPM made it possible to install, remove, and track packaged software, but obtaining an RPM did not necessarily mean that everything required to run it was already installed. A package might depend on several other packages, each of which introduced dependencies of its own. Users could find themselves searching the Internet for one RPM after another, only to discover that the next package required still another library or a different version of one they already had.

One solution came from a descendant of Red Hat Linux. Yellow Dog Linux was an RPM-based distribution developed primarily for PowerPC computers, including Apple Macintosh systems. Yellow Dog developed YUP, the Yellowdog Updater, to work with software repositories rather than requiring users to locate every RPM individually.

Developers at Duke University built on YUP to create YUM, the Yellowdog Updater, Modified. YUM could use repositories to determine which packages were required to satisfy dependencies and retrieve them as part of an installation. Fedora adopted YUM, and it eventually became familiar to generations of Fedora, Red Hat Enterprise Linux, CentOS, and related-system users. Yellow Dog Linux itself eventually disappeared, but its name survived in yum.

Red Hat Linux helped provide the foundation for Yellow Dog Linux. Yellow Dog’s solution to an RPM problem was expanded by other developers, then flowed back into Fedora and the Red Hat ecosystem.

Packaging a Free and Open Source operating system therefore involves more than collecting freely available programs. Someone still has to decide which versions belong together, describe their dependencies, organize repositories, test combinations, and provide updates. Better tooling can automate much of that work for the user, but only because the distribution has already done the integration work behind it.

That work includes:

  • Packaging
  • Integration
  • Testing
  • Documentation
  • Technical support
  • Security updates
  • Long-term maintenance
  • Certification

None of those activities requires taking away the freedoms granted by the underlying software. They provide value around software that customers may already have the right to copy, inspect, modify, and redistribute.

This distinction became increasingly important as Linux moved from hobbyist computers and Internet servers into businesses and large organizations. A company might be perfectly capable of downloading source code without being interested in assembling, testing, maintaining, and supporting an operating system itself. What it could purchase from Red Hat was not simply permission to possess Linux, but a maintained product and a relationship with an organization willing to support it.

From Red Hat Linux to an Ecosystem

Red Hat eventually changed how it organized its Linux distributions. Red Hat Enterprise Linux, or RHEL, had been introduced in 2002 as the company’s commercially supported enterprise distribution. The original Red Hat Linux line was discontinued in 2003, and the Fedora Project was introduced for users and developers who wanted a faster-moving community distribution.

The ability to use and redistribute Free and Open Source Software also allowed other projects and companies to develop systems around the Red Hat ecosystem. A few examples show that movement in different directions:

  • Fedora
  • Rocky Linux
  • Oracle Linux

Fedora represents the community side of Red Hat’s own development ecosystem. Newer software and technologies can develop in Fedora before some of that work moves through CentOS Stream and eventually into Red Hat Enterprise Linux. The community project is therefore not merely a free copy of the commercial product; it participates upstream in the development path that can eventually lead toward RHEL.

Rocky Linux demonstrates movement in the other direction. It is a community-developed enterprise Linux distribution designed to be compatible with RHEL. The existence of a commercial enterprise distribution does not prevent a separate community from using the available Free and Open Source code to build its own compatible system.

Oracle Linux takes that possibility into the commercial world again. Oracle is not Red Hat, yet it can offer its own commercially supported Linux distribution designed for compatibility with RHEL. Free and Open Source licensing therefore permits an unusual commercial relationship: one company’s commercial software ecosystem can provide much of the foundation for another company’s competing commercial product.

Fedora shows a community project feeding toward a commercial distribution, Rocky Linux shows a community project appearing downstream from it, and Oracle Linux shows another commercial product appearing downstream. Commercial and community development are not opposite ends of a line. Free and Open Source licensing allows software to move among both.

What Red Hat Sells

Red Hat Enterprise Linux is commercial software, but that does not make the Free and Open Source components from which it is built proprietary. Customers pay Red Hat for an enterprise product assembled from those components and for the services surrounding that product.

The distinction is easier to see if we separate the software from the business built around it. Linux can remain licensed under the GPL. BSD-licensed components can retain their permissive licenses. Thousands of other packages can retain the licenses chosen by their respective projects. Red Hat can still select versions, integrate them, test the resulting system, provide updates, certify hardware and software, maintain releases for years, and sell support for the complete product.

A company can build a commercial product from software that its customers have substantial rights to copy and modify. The company does not necessarily make its money by preventing those freedoms. It can make money by doing work around the software that customers consider valuable.

Debian and Red Hat consequently arrive at complete operating systems through different organizations. Debian demonstrates that a community can integrate Free and Open Source Software into a distribution that later becomes the foundation for both community and commercial descendants. Red Hat demonstrates that a company can take much of the same larger pool of Free and Open Source Software and build a commercial product and support business around it.

Free and Open Source Software does not eliminate commercial software. It changes what a software company can sell and where the value of that commercial product can come from.

When customers already have substantial rights to the software, commercial value can move toward integration, maintenance, support, certification, and trust.

StarOffice, OpenOffice.org, and LibreOffice: Who Controls the Future?

The office suite we now know as LibreOffice began as proprietary commercial software. Its roots reach back to StarWriter, created by Marco Börries in Germany in the 1980s. StarDivision developed the program into a larger suite, and by 1992 it had become StarOffice.

StarOffice was eventually available on several operating systems, including Windows, OS/2, Solaris, and Linux. It was still StarDivision’s product, however. The company controlled its development and distribution in much the same way another software company might control any proprietary office suite.

Then the owner changed.

Sun Microsystems acquired StarDivision in 1999. The following year, Sun did something more significant than simply continue selling StarOffice: it announced OpenOffice.org and released the StarOffice source code for the new project on October 13, 2000. OpenOffice.org 1.0 followed on April 30, 2002. A proprietary commercial software family now had an Open Source branch that other developers could study, modify, and help develop.

Sun did not have to stop selling an office suite in order to do this. StarOffice continued as a commercial product while OpenOffice.org developed as an Open Source project. Once again, commercial and Open Source were not opposites. The same software family could participate in both models.

For several years that arrangement continued with Sun as the principal corporate sponsor of OpenOffice.org. The community could contribute to the project, while Sun remained an important center of its development and stewardship.

Then the owner changed again.

Oracle acquired Sun Microsystems in January 2010. That acquisition meant that OpenOffice.org, along with the other technology Sun had accumulated, now sat under a different corporate owner. Members of the OpenOffice.org community did not have to wait to discover what Oracle would eventually choose to do with the project.

They could fork it.

LibreOffice

On September 28, 2010, members of the OpenOffice.org community announced The Document Foundation, an independent organization intended to provide a community-governed home for the office suite. Unable to obtain the trademarked OpenOffice.org name from Oracle, the new project was called LibreOffice.

LibreOffice was not a rewrite created from nothing. It began as a fork of OpenOffice.org. The developers already had access to the source and, more importantly, the software’s license gave them the rights necessary to take that source in another direction.

That is where the right to fork becomes more than an abstract freedom written into a license. The community did not need to purchase the project from Oracle, persuade Oracle to transfer ownership, or abandon years of existing code and begin again. Developers could take the code they were already working on and continue developing it under different stewardship.

Oracle later stopped developing OpenOffice.org and, in June 2011, contributed the source code and trademarks to the Apache Software Foundation. OpenOffice therefore continued as Apache OpenOffice, while LibreOffice continued independently under The Document Foundation.

One software family had now passed through several very different arrangements:

  • StarOffice
  • OpenOffice.org
  • LibreOffice
  • Apache OpenOffice

The names alone do not explain what happened. StarOffice began as proprietary commercial software. Sun opened its source to create OpenOffice.org. The OpenOffice.org community later exercised its right to fork the code and created LibreOffice. Oracle then transferred OpenOffice.org to Apache, producing another independently governed Open Source branch.

The ability to fork did not guarantee which branch would attract developers, users, or institutional support. A software license cannot determine whether a project will succeed. What it can determine is whether people have the legal ability to continue the software when they disagree with the decisions of whoever currently controls a project.

Open Does Not Mean Interchangeable

The split also produced a subtler licensing lesson. Apache OpenOffice and LibreOffice are both Open Source, but they do not use the same licensing model.

Apache OpenOffice uses the permissive Apache License 2.0. LibreOffice is currently distributed primarily under the Mozilla Public License 2.0, with new contributions also licensed under the LGPLv3+ according to the project’s contribution policy. Those differences affect how code can move between the two projects.

Apache-licensed code can be incorporated into LibreOffice under the applicable licensing arrangements, and LibreOffice has incorporated code originating in Apache OpenOffice. The reverse direction is more difficult. Code contributed only under LibreOffice’s copyleft licenses cannot simply be incorporated into Apache OpenOffice and redistributed solely under Apache’s permissive license.

The result is an asymmetric relationship. Apache OpenOffice can develop a feature under a permissive license that LibreOffice may be able to incorporate. If LibreOffice develops a change under licensing terms that impose copyleft requirements, Apache OpenOffice cannot simply take that code and place it into its Apache-licensed codebase.

Open Source does not mean that code can move freely between every Open Source project. Two projects can both provide their source code, both permit modification, and both permit redistribution while still using licenses that place different requirements on what happens when their code is combined or redistributed.

Commercial software can become the source of an Open Source project. Commercial and Open Source versions can coexist. A change in corporate ownership does not necessarily give that corporation complete control over the future of previously released Open Source code. A community with the right to fork can continue development independently. And even after a fork, the licenses chosen by the resulting projects can affect which direction code is able to travel between them.

Open Source does not guarantee who will control a project tomorrow. It gives others rights that can prevent one owner from being the only possible future for the code.

The right to fork does not guarantee that a fork will succeed. It guarantees that continued development does not have to depend on one owner saying yes.

Summary

Software does not fit neatly into a single category. Whether software is commercial, whether someone pays to obtain it, whether its source code is available, how copies are distributed, and what users are permitted to do with those copies are separate questions. Shareware can be proprietary. Freeware can restrict modification. Free Software can be sold commercially. Open Source software can be developed by volunteers, businesses, or both. Understanding software licensing begins by separating those questions rather than assuming that one answer determines all the others.

The histories of Doom, GNU Emacs, and BSD show how much the rights attached to software can differ. Encouraging people to copy Doom did not initially give them its source code, and publishing that source did not immediately make it Open Source. GNU Emacs demonstrated how copyleft could use copyright to preserve particular freedoms as software moved downstream. BSD licenses made a different choice, granting broad freedoms while generally allowing downstream developers to decide how their larger resulting works would be licensed. Both copyleft and permissive licenses can produce Free and Open Source Software, but they do not impose the same obligations on what comes next.

Those permissions become even more significant when individual programs become parts of larger systems. Debian shows how a community can assemble thousands of independently developed components into a complete operating system that can itself become the foundation for other projects. Red Hat shows how much commercial value can be created around software that customers already have substantial rights to use, study, modify, and redistribute. The history from StarOffice through OpenOffice.org and LibreOffice shows why the right to fork matters when ownership or stewardship changes—and why even two Open Source projects may not be able to exchange code equally when their licenses differ.

Licensing is therefore more than a statement about whether software costs money or whether its source code can be downloaded. It establishes permissions and obligations that help determine where code can travel, what can be built from it, and what rights accompany it along the way. Those choices helped UNIX cross organizational boundaries, allowed BSD code to spread into an enormous range of systems, and made it possible to assemble the Free and Open Source components surrounding Linux into complete operating systems. As we continue following the modern UNIX family, those licensing decisions will remain part of the explanation for why BSD and Linux developed into the ecosystems we know today.