The GNULinux vs. Linux Debate

 < Free Open Study > 



The GNU/Linux vs. Linux Debate

In strict terms of total lines of code, the Linux kernel is only a fraction of the code that makes up a full-fledged system; code from the GNU project is a crucially important part of the Linux-based operating systems that people use every day. So, it might be more accurate to describe such systems as GNU systems, or GNU/Linux systems as a compromise. Such terms reflect the major contribution that the GNU project has made to the success of Linux.

Unfortunately, the damage is done. A decade of momentum is hard to reverse, and the common name for such systems has become, simply, Linux. Once the media begins using a term, however inaccurately, it enters the public discourse, and the act of insisting on a more accurate name itself becomes an oddity. This phenomenon presents books such as this one with a thorny dilemma. The goal of a book is to be accurate and detailed, yet it must be accurate in both meaning and usage. Is it more accurate to refer to a Linux-based system as Linux as in common usage, or to use the more correct but less widely recognized term GNU/Linux?

The GNU/Linux vs. Linux debate has been a heated one in the community, and is the source of a lot of hard feelings. And rightfully so: no one likes to have the magnitude of their contributions diluted by a single, small part of the whole, just as no one likes to have their integral contributions smothered by the whole.

All that we can do is attempt to be as accurate as possible, given the constraints. So, this book refers to GNU/Linux systems as Linux-based systems, or Linux systems for brevity. Hopefully this strikes a balance between accuracy and approachability.



 < Free Open Study > 

 < Free Open Study > 



References

If you're interested in the history of Unix, start with the Unix FAQ for the newsgroups comp.unix.questions and comp.unix.shell. Chapter 6 of that document provides a fairly comprehensive summary of the lineages of various Unix flavors, as well as additional references.

The best source for information on the Free Software Foundation and the GNU project (including the HURD) is their web site at http://www.fsf.org.

More information about Darwin on Linux can be found at http://www.darwinlinux.org; similarly, information on Transvirtual's PocketLinux is at http://www.pocketlinux.com.

An amusing insight into the motivations and goals of Linux can be found in an online Usenet exchange between Andy Tanenbaum (the creator of Minix) and Linus Torvalds. This discussion can be found on various web sites; simply search for "Linus vs. Tanenbaum" or "Linux is Obsolete" at your favorite web search engine. This discussion thread, when read today, is an amazing look back at the beginning of the whole "Linux revolution."



 < Free Open Study > 

 < Free Open Study > 



Chapter 2: An Open Source Primer

Linux systems are generally open source software, meaning that their source code is readily available and freely redistributable. However, many people don't understand what it actually means to be open source; even more, many people don't understand just how fundamental the open source ethos is to the evolution of Linux. This chapter will discuss open source and free software, and explore what these concepts mean to GNU and Linux. Readers who are already well versed in open source and free software may wish to skim or skip this chapter, and move on to Chapter 3.

The Nature of Software

There is a great deal of passion and rhetoric surrounding open source and free software. There are several basic arguments that appear in various forms, which establish the foundations for open source and free software. The philosophical issue of free software remains largely subjective, and an argument that one person considers valid may not work for someone else. In other words, it's a touchy issue. This section will attempt to outline the basic tenets of the various following arguments, as objectively as possible. However, readers should take this section with a grain of salt, and remember that it's just one humble author's perspective.

Software development isn't easy. It takes knowledge and skill, and most of all, time. For these reasons, software development has a cost. For commercial organizations, it's expensive financially; even for free software developers, it's expensive in terms of effort. For these reasons, it makes a lot of sense to share as much as possible. In that respect, software development is just like any other scientific or technical discipline. Scientists share information about their work with one another, and work together as a community to advance the state of the art, building on each others' work.

In contrast, companies have a profit motive, and strive to make as much profit as they can. Companies that sell products must, of course, perform the research and development that creates these products. However, companies have no motive to share this information with anyone else; after all, if they did, another organization might be able to profit from it as well, which is profit that the company could have had for themselves.

Normally, this two-faceted model works fine: scientists in academia (and sometimes in industry) produce theories and discoveries, perform experiments, and share their findings. Engineers, meanwhile, take this information and use it to build actual products that companies sell. The companies exist in order to marshal and manage the resources required to bring those products to market—a task which is usually beyond the capability of a single person.

However, like so many others, this model breaks down when applied to software. The primary difficulty is that software itself has no intrinsic value. A tangible piece of equipment such as a car has value, essentially because it cost something to build. That is, even if you have the full schematics for a car, you still must have the raw materials to build it, and those raw materials are not free. Thus, the car has an intrinsic value, separate from the cost it took to design it.

A software program, however, costs nothing to build. Once you have it written, you can replicate it endlessly, effortlessly, and exactly (with never any errors). A car, on the other hand, has costs in raw materials and fabrication. Cars and software programs both cost money to develop, of course; however, once the R&D is done, the actual cars must still be manufactured, while the software is simply copied. Since software has no cost of replication, its only cost is the effort spent to develop it. Thus, unlike a car, software has no intrinsic value. Because of this, the concept of a "software company" that actually sells software is incredibly bizarre, if you stop to think about it. It's like selling air.

Now, it's still true that software developers have to recoup their R&D costs. However, this kind of R&D is really just an overhead cost of the main product. For vendors of hardware that includes software (such as web servers, cellular phones, or personal digital assistants) the software is viewed as simply a necessary cost of developing the product. For service-oriented companies such as web site developers and network support companies, the software is simply an overhead cost of providing the service. In neither case is software being sold for its own value. When you think of things this way, the notion of selling software seems more and more odd the longer you think about it.

Note 

Of course, this whole argument is a generalization and isn't always true. Specifically, it's only true of horizontal software. The concept of a horizontal software product is described in its own section a little later in this chapter.

The upshot of all this is that since the only cost of many types of software is the cost to develop it, there is no rational reason for a company to exist for the purpose of marshalling and managing the resources required to manufacture it. This argument—or at least similar notions—form the foundation for activists who believe in a very different philosophy for software development.

Richard Stallman is an activist and computer scientist who founded the Free Software Foundation and the GNU project in order to foster a sharing culture for software development. The FSF fosters sharing and collaboration—the scientific ethic—for software development. All of the FSF's software is released along with its source code and a license that ensures its continued openness.

Stallman describes software developed in this way as free software. In what has become an old saw in the open source community, the "free" in "free software" is "free" as in "free speech", not "free" as in "free beer." That is an important distinction. Software that is given away without source code (such as some web browsers), is not free software, but is merely "no-cost" software.

The arguments presented in this chapter are largely based on vaguely economic, philosophical, and political notions. While this book strives for objectivity, readers should realize that there are many different perspectives on these issues, and are highly encouraged to read Stallman's (and this FSF's) own arguments and documentation on the subject. One of the best sources of such information is obviously the Free Software Foundation's web site, at http://www.fsf.org. At that site, you can find the official positions of the FSF, and all their arguments on these issues.



 < Free Open Study >