The GNU Project

byRichardStallman

The first software-sharing community

When I started working at theMITArtificial Intelligence Lab in 1971, I became part of asoftware-sharing community that had existed for many years. Sharingof software was not limited to our particular community; it is as oldas computers, just as sharing of recipes is as old as cooking. But wedid it more than most.

The AI Lab used a timesharing operating system calledITS(theIncompatible Timesharing System) that the lab's staff hackers [1]haddesigned and written in assembler language for the DigitalPDP-10, one ofthe large computers of the era. As a member of this community, an AILab staff system hacker, my job was to improve this system.

We did not call our software “free software,” because thatterm did not yet exist; but that is what it was. Whenever people fromanother university or a company wanted to port and use a program, wegladly let them. If you saw someone using an unfamiliar andinteresting program, you could always ask to see the source code, sothat you could read it, change it, or cannibalize parts of it to makea new program.

The collapse of the community

The situation changed drastically in the early 1980s when Digitaldiscontinued the PDP-10 series. Its architecture, elegant andpowerful in the 60s, could not extend naturally to the larger addressspaces that were becoming feasible in the 80s. This meant that nearlyall of the programs composing ITS were obsolete.

The AI Lab hacker community had already collapsed, not long before.In 1981, the spin-off company Symbolics had hired away nearly all ofthe hackers from the AI Lab, and the depopulated community was unableto maintain itself. (The bookHackers, by Steve Levy, describes theseevents, as well as giving a clear picture of this community in itsprime.) When the AI Lab bought a new PDP-10 in 1982, itsadministrators decided to use Digital's nonfree timesharing systeminstead of ITS.

The modern computers of the era, such as the VAX or the 68020, hadtheir own operating systems, but none of them were free software: youhad to sign a nondisclosure agreement even to get an executable copy.

This meant that the first step in using a computer was to promise notto help your neighbor. A cooperating community was forbidden. Therule made by the owners of proprietary software was, “If youshare with your neighbor, you are a pirate. If you want any changes,beg us to make them.”

The idea that the proprietary software social system—the systemthat says you are not allowed to share or change software—isantisocial, that it is unethical, that it is simply wrong, may come asa surprise to some readers. But what else could we say about a systembased on dividing the public and keeping users helpless? Readers whofind the idea surprising may have taken the proprietary softwaresocial system as a given, or judged it on the terms suggested byproprietary software businesses. Software publishers have worked longand hard to convince people that there is only one way to look at theissue.

When software publishers talk about “enforcing” their“rights” or “stoppingpiracy,” what theyactuallysayis secondary. The real message of these statements isin the unstated assumptions they take for granted, which the public isasked to accept without examination. Let's therefore examine them.

One assumption is that software companies have an unquestionable naturalright to own software and thus have power over all its users. (Ifthis were a natural right, then no matter how much harm it does to thepublic, we could not object.) Interestingly, the US Constitution andlegal tradition reject this view; copyright is not a natural right,but an artificial government-imposed monopoly that limits the users'natural right to copy.

Another unstated assumption is that the only important thing aboutsoftware is what jobs it allows you to do—that we computer usersshould not care what kind of society we are allowed to have.

A third assumption is that we would have no usable software (or wouldnever have a program to do this or that particular job) if we did notoffer a company power over the users of the program. This assumptionmay have seemed plausible, before the free software movementdemonstrated that we can make plenty of useful software withoutputting chains on it.

If we decline to accept these assumptions, and judge these issuesbased on ordinary commonsense morality while placing the users first,we arrive at very different conclusions. Computer users should befree to modify programs to fit their needs, and free to sharesoftware, because helping other people is the basis of society.

There is no room here for an extensive statement of the reasoningbehind this conclusion, so I refer the reader to “Why Software Should Not HaveOwners,” and “FreeSoftware Is Even More Important Now.”

A stark moral choice

With my community gone, to continue as before was impossible.Instead, I faced a stark moral choice.

The easy choice was to join the proprietary software world, signingnondisclosure agreements and promising not to help my fellow hacker.Most likely I would also be developing software that was releasedunder nondisclosure agreements, thus adding to the pressure on otherpeople to betray their fellows too.

I could have made money this way, and perhaps amused myself writingcode. But I knew that at the end of my career, I would look back onyears of building walls to divide people, and feel I had spent my lifemaking the world a worse place.

I had already experienced being on the receiving end of anondisclosure agreement, when someone refused to give me and the MITAI Lab the source code for the control program for our printer. (Thelack of certain features in this program made use of the printerextremely frustrating.) So I could not tell myself that nondisclosureagreements were innocent. I was very angry when he refused to sharewith us; I could not turn around and do the same thing to everyoneelse.

Another choice, straightforward but unpleasant, was to leave thecomputer field. That way my skills would not be misused, but theywould still be wasted. I would not be culpable for dividing andrestricting computer users, but it would happen nonetheless.

So I looked for a way that a programmer could do something for thegood. I asked myself, was there a program or programs that I couldwrite, so as to make a community possible once again?

The answer was clear: what was needed first was an operating system.That is the crucial software for starting to use a computer. With anoperating system, you can do many things; without one, you cannot runthe computer at all. With a free operating system, we could againhave a community of cooperating hackers—and invite anyone to join.And anyone would be able to use a computer without starting out byconspiring to deprive his or her friends.

As an operating system developer, I had the right skills for this job.So even though I could not take success for granted, I realized that Iwas elected to do the job. I chose to make the system compatible withUnix so that it would be portable, and so that Unix users could easilyswitch to it. The name GNU was chosen, following a hacker tradition, asa recursive acronym for “GNU's Not Unix.” It is pronouncedasone syllable with a hard g.

An operating system does not mean just a kernel, barely enough to runother programs. In the 1970s, every operating system worthy of thename included command processors, assemblers, compilers, interpreters,debuggers, text editors, mailers, and much more. ITS had them,Multics had them, VMS had them, and Unix had them. The GNU operatingsystem would include them too.

Later I heard these words, attributed to Hillel [2]:

If I am not for myself, who will be for me?
If I am only for myself, what am I?
If not now, when?

The decision to start the GNU Project was based on a similar spirit.

Free as in freedom

The term “free software” is sometimes misunderstood—ithas nothing to do with price. It is about freedom. Here, therefore,is the definition of free software.

A program is free software, for you, a particular user, if:

• You have the freedom to run the program as you wish, for any purpose.
• You have the freedom to modify the program to suit your needs.(To make this freedom effective in practice, you must have accessto the source code, since making changes in a program withouthaving the source code is exceedingly difficult.)
• You have the freedom to redistribute copies, either gratisor for a fee.
• You have the freedom to distribute modified versions of the program,so that the community can benefit from your improvements.

Since “free” refers to freedom, not to price, there is nocontradiction between selling copies and free software. In fact, thefreedom to sell copies is crucial: collections of free software soldon CD-ROMs are important for the community, and selling them is animportant way to raise funds for free software development.Therefore, a program which people are not free to include on thesecollections is not free software.

Because of the ambiguity of “free,” people have longlooked for alternatives, but no one has found a better term.The English language has more words and nuances than any other, but itlacks a simple, unambiguous, word that means “free,” as infreedom—“unfettered” being the word that comes closest inmeaning. Such alternatives as “liberated,”“freedom,” and “open” have either the wrongmeaning or some other disadvantage.

GNU software and the GNU system

Developing a whole system is a very large project. To bring it intoreach, I decided to adapt and use existing pieces of free softwarewherever that was possible. For example, I decided at the verybeginning to use TeX as the principal text formatter; a few yearslater, I decided to use the X Window System rather than writinganother window system for GNU.

Because of these decisions, and others like them,the GNU system is not the same as the collection of allGNU software. The GNU system includes programs that are not GNUsoftware, programs that were developed by other people and projectsfor their own purposes, but which we can use because they are freesoftware.

Commencing the project

In January 1984 I quit my job at MIT and began writing GNU software.Leaving MIT was necessary so that MIT would not be able to interferewith distributing GNU as free software. If I had remained on thestaff, MIT could have claimed to own the work, and could have imposedtheir own distribution terms, or even turned the work into aproprietary software package. I had no intention of doing a largeamount of work only to see it become useless for its intended purpose:creating a new software-sharing community.

However, Professor Winston, then the head of the MIT AI Lab, kindlyinvited me to keep using the lab's facilities.

The first steps

Shortly before beginning the GNU Project, I heard about the FreeUniversity Compiler Kit, also known as VUCK. (The Dutch word for“free” is written with av.) This was a compilerdesigned to handle multiple languages, including C and Pascal, and tosupport multiple target machines. I wrote to its author asking if GNUcould use it.

He responded derisively, stating that the university was free but thecompiler was not. I therefore decided that my first program for theGNU Project would be a multilanguage, multiplatform compiler.

Hoping to avoid the need to write the whole compiler myself, Iobtained the source code for the Pastel compiler, which was amultiplatform compiler developed at Lawrence Livermore Lab. Itsupported, and was written in, an extended version of Pascal, designedto be a system-programming language. I added a C front end, and beganporting it to the Motorola 68000 computer. But I had to give thatup when I discovered that the compiler needed many megabytes of stackspace, and the available 68000 Unix system would only allow 64k.

I then realized that the Pastel compiler functioned by parsing theentire input file into a syntax tree, converting the whole syntax treeinto a chain of “instructions,” and then generating thewhole output file, without ever freeing any storage. At this point, Iconcluded I would have to write a new compiler from scratch. That newcompiler is now known asGCC;none of the Pastel compiler is used in it, but I managed to adapt anduse the C front end that I had written. But that was some yearslater; first, I worked on GNU Emacs.

GNU Emacs

I began work on GNU Emacs in September 1984, and in early 1985 it wasbeginning to be usable. This enabled me to begin using Unix systemsto do editing; having no interest in learning to use vi or ed, I haddone my editing on other kinds of machines until then.

At this point, people began wanting to use GNU Emacs, which raised thequestion of how to distribute it. Of course, I put it on theanonymous ftp server on the MIT computer that I used. (This computer,prep.ai.mit.edu, thus became the principal GNU ftp distribution site;when it was decommissioned a few years later, we transferred the nameto our new ftp server.) But at that time, many of the interestedpeople were not on the Internet and could not get a copy by ftp. Sothe question was, what would I say to them?

I could have said, “Find a friend who is on the net and who will makea copy for you.” Or I could have done what I did with the originalPDP-10 Emacs: tell them, “Mail me a tape and aSASE, and Iwill mail it back with Emacs on it.” But I had no job, and I waslooking for ways to make money from free software. So I announcedthat I would mail a tape to whoever wanted one, for a fee of $150. Inthis way, I started a free software distribution business, theprecursor of the companies that today distribute entire GNU/Linuxsystem distributions.

Is a program free for every user?

If a program is free software when it leaves the hands of its author,this does not necessarily mean it will be free software for everyonewho has a copy of it. For example,public domainsoftware(software that is not copyrighted) is free software; butanyone can make a proprietary modified version of it. Likewise, manyfree programs are copyrighted but distributed under simple permissivelicenses which allow proprietary modified versions.

The paradigmatic example of this problem is the X Window System.Developed at MIT, and released as free software with a permissivelicense, it was soon adopted by various computer companies. Theyadded X to their proprietary Unix systems, in binary form only, andcovered by the same nondisclosure agreement. These copies of X wereno more free software than Unix was.

The developers of the X Window System did not consider this aproblem—they expected and intended this to happen. Their goal wasnot freedom, just “success,” defined as “having manyusers.” They did not care whether these users had freedom, onlythat they should be numerous.

This led to a paradoxical situation where two different ways ofcounting the amount of freedom gave different answers to the question,“Is this program free?” If you judged based on the freedomprovided by the distribution terms of the MIT release, you would saythat X was free software. But if you measured the freedom of theaverage user of X, you would have to say it was proprietary software.Most X users were running the proprietary versions that came with Unixsystems, not the free version.

Copyleft and the GNU GPL

The goal of GNU was to give users freedom, not just to be popular. Sowe needed to use distribution terms that would prevent GNU softwarefrom being turned into proprietary software. The method we use iscalled “copyleft” [3].

Copyleft uses copyright law, but flips it over to serve the oppositeof its usual purpose: instead of a means for restricting a program, itbecomes a means for keeping the program free.

The central idea of copyleft is that we give everyone permission torun the program, copy the program, modify the program, and distributemodified versions—but not permission to add restrictions of theirown. Thus, the crucial freedoms that define “freesoftware” are guaranteed to everyone who has a copy; they becomeinalienable rights.

For an effective copyleft, modified versions must also be free. Thisensures that work based on ours becomes available to our community ifit is published. When programmers who have jobs as programmersvolunteer to improve GNU software, it is copyleft that prevents theiremployers from saying, “You can't share those changes, becausewe are going to use them to make our proprietary version of theprogram.”

The requirement that changes must be free is essential if we want toensure freedom for every user of the program. The companies thatprivatized the X Window System usually made some changes to port it totheir systems and hardware. These changes were small compared withthe great extent of X, but they were not trivial. If making changeswere an excuse to deny the users freedom, it would be easy for anyoneto take advantage of the excuse.

A related issue concerns combining a free program with nonfree code.Such a combination would inevitably be nonfree; whichever freedomsare lacking for the nonfree part would be lacking for the whole aswell. To permit such combinations would open a hole big enough tosink a ship. Therefore, a crucial requirement for copyleft is to plugthis hole: anything added to or combined with a copylefted programmust be such that the larger combined version is also free andcopylefted.

The specific implementation of copyleft that we use for most GNUsoftware is the GNU General Public License, or GNU GPL for short. Wehave other kinds of copyleft that are used in specific circumstances.GNU manuals are copylefted also, but use a much simpler kind ofcopyleft, because the complexity of the GNU GPL is not necessaryfor manuals [4].

The Free Software Foundation

As interest in using Emacs was growing, other people becameinvolved in the GNU project, and we decided that it was time to seekfunding once again to support the development of the GNU operatingsystem. So in 1985 I brought in friends who cared about the goal, andcreated theFree SoftwareFoundation(FSF), a tax-exempt charity for free softwaredevelopment. The FSF also took over the Emacs tape distributionbusiness; later it extended this by adding other free software (bothGNU and non-GNU) to the tape, and by selling free(freedom-respecting) manuals as well.

Most of the FSF's income used to come from sales of copies of freesoftware and of other related services (CD-ROMs of source code,CD-ROMs with binaries, nicely printed manuals, all with the freedom toredistribute and modify), and Deluxe Distributions (distributions forwhich we built the whole collection of software for the customer'schoice of platform). Today the FSFstillsells manuals and othergear, but it gets the bulk of its funding from members' dues. Youcan join the FSF atfsf.org.

Free Software Foundation employees have written and maintained anumber of GNU software packages. Two notable ones are the C libraryand the shell. The GNU C library is what every program running on aGNU/Linux system uses to communicate with Linux. It was developed bya member of the Free Software Foundation staff, Roland McGrath. Theshell used on most GNU/Linux systems isBASH, the Bourne AgainSHell [5], which was developed by FSF employee Brian Fox.

We funded development of these programs because the GNU Project wasnot just about tools or a development environment. Our goal was acomplete operating system, and these programs were needed for thatgoal.

Free software support

The free software philosophy rejects a specific widespread businesspractice, but it is not against business. When businesses respect theusers' freedom, we wish them success.

Selling copies of Emacs demonstrates one kind of free softwarebusiness. When the FSF took over that business, I needed another wayto make a living. I found it in selling services relating to the freesoftware I had developed. This included teaching, for subjects suchas how to program GNU Emacs and how to customize GCC, and softwaredevelopment, mostly porting GCC to new platforms.

Today each of these kinds of free software business is practiced by anumber of corporations. Some distribute free software collections onCD-ROM; others sell support at levels ranging from answering userquestions, to fixing bugs, to adding major new features. We are evenbeginning to see free software companies based on launching new freesoftware products.

Watch out, though—a number of companies that associate themselveswith the term “open source” actually base their businesson nonfree software that works with free software. These are notfree software companies, they are proprietary software companies whoseproducts tempt users away from freedom. They call these programs“value-added packages,” which shows the values theywould like us to adopt: convenience above freedom. If we value freedommore, we should call them “freedom-subtracted” packages.

Technical goals

The principal goal of GNU is to be free software. Even if GNU had notechnical advantage over Unix, it would have a social advantage,allowing users to cooperate, and an ethical advantage, respecting theuser's freedom.

But it was natural to apply the known standards of good practice tothe work—for example, dynamically allocating data structures to avoidarbitrary fixed size limits, and handling all the possible 8-bit codeswherever that made sense.

In addition, we rejected the Unix focus on small memory size, bydeciding not to support 16-bit machines (it was clear that 32-bitmachines would be the norm by the time the GNU system was finished),and to make no effort to reduce memory usage unless it exceeded amegabyte. In programs for which handling very large files was notcrucial, we encouraged programmers to read an entire input file intocore, then scan its contents without having to worry about I/O.

These decisions enabled many GNU programs to surpass their Unixcounterparts in reliability and speed.

Donated computers

As the GNU Project's reputation grew, people began offering to donatemachines running Unix to the project. These were very useful, becausethe easiest way to develop components of GNU was to do it on a Unixsystem, and replace the components of that system one by one. Butthey raised an ethical issue: whether it was right for us to have acopy of Unix at all.

Unix was (and is) proprietary software, and the GNU Project'sphilosophy said that we should not use proprietary software. But,applying the same reasoning that leads to the conclusion that violencein self defense is justified, I concluded that it was legitimate touse a proprietary package when that was crucial for developing a freereplacement that would help others stop using the proprietary package.

But, even if this was a justifiable evil, it was still an evil. Todaywe no longer have any copies of Unix, because we have replaced themwith free operating systems. If we could not replace a machine'soperating system with a free one, we replaced the machine instead.

The GNU Task List

As the GNU Project proceeded, and increasing numbers of systemcomponents were found or developed, eventually it became useful tomake a list of the remaining gaps. We used it to recruit developersto write the missing pieces. This list became known as the GNU TaskList. In addition to missing Unix components, we listed variousother useful software and documentation projects that, we thought, atruly complete system ought to have.

Today [6], hardly any Unix components are left in the GNU TaskList—those jobs had been done, aside from a few inessentialones. But the list is full of projects that some might call“applications.” Any program that appeals to more than anarrow class of users would be a useful thing to add to an operatingsystem.

Even games are included in the task list—and have been since thebeginning. Unix included games, so naturally GNU should too. Butcompatibility was not an issue for games, so we did not follow thelist of games that Unix had. Instead, we listed a spectrum ofdifferent kinds of games that users might like.

The GNU Lesser GPL

The GNU C library uses a special kind of copyleft called the GNULesser General Public License [7], which gives permission to linkproprietary software with the library. Why make this exception?

It is not a matter of principle; there is no principle that saysproprietary software products are entitled to include our code. (Whycontribute to a project predicated on refusing to share with us?)Using the LGPL for the C library, or for any library, is a matter ofstrategy.

The C library does a generic job; every proprietary system or compilercomes with a C library. Therefore, to make our C library availableonly to free software would not have given free software anyadvantage—it would only have discouraged use of our library.

One system is an exception to this: on the GNU system (and thisincludes GNU/Linux), the GNU C library is the only C library. So thedistribution terms of the GNU C library determine whether it ispossible to compile a proprietary program for the GNU system. Thereis no ethical reason to allow proprietary applications on the GNUsystem, but strategically it seems that disallowing them would do moreto discourage use of the GNU system than to encourage development offree applications. That is why using the Lesser GPL is a goodstrategy for the C library.

For other libraries, the strategic decision needs to beconsidered on a case-by-case basis. When a library does a special jobthat can help write certain kinds of programs, then releasing it underthe GPL, limiting it to free programs only, is a way of helping otherfree software developers, giving them an advantage against proprietarysoftware.

Consider GNU Readline, a library that was developed to providecommand-line editing for BASH. Readline is released under theordinary GNU GPL, not the Lesser GPL. This probably does reduce theamount Readline is used, but that is no loss for us. Meanwhile, atleast one useful application has been made free software specificallyso it could use Readline, and that is a real gain for thecommunity.

Proprietary software developers have the advantages money provides;free software developers need to make advantages for each other. Ihope some day we will have a large collection of GPL-covered librariesthat have no parallel available to proprietary software, providinguseful modules to serve as building blocks in new free software, andadding up to a major advantage for further free software development.

Scratching an itch?

Eric Raymond says that “Every good work of software starts byscratching a developer's personal itch.” Maybe that happenssometimes, but many essential pieces of GNU software were developed inorder to have a complete free operating system. They come from avision and a plan, not from impulse.

For example, we developed the GNU C library because a Unix-like systemneeds a C library, BASH because a Unix-likesystem needs a shell, and GNU tar because a Unix-like system needs atar program. The same is true for my own programs—the GNU Ccompiler, GNU Emacs, GDB and GNU Make.

Some GNU programs were developed to cope with specific threats to ourfreedom. Thus, we developed gzip to replace the Compress program,which had been lost to the community because oftheLZWpatents. We foundpeople to develop LessTif, and more recently startedGNOMEand Harmony, to address the problems caused by certain proprietarylibraries (see below). We are developing the GNU Privacy Guard toreplace popular nonfree encryption software, because users should nothave to choose between privacy and freedom.

Of course, the people writing these programs became interested in thework, and many features were added to them by various people for thesake of their own needs and interests. But that is not why theprograms exist.

Unexpected developments

At the beginning of the GNU Project, I imagined that we would developthe whole GNU system, then release it as a whole. That is not how ithappened.

Since each component of the GNU system was implemented on a Unixsystem, each component could run on Unix systems long before acomplete GNU system existed. Some of these programs became popular,and users began extending them and porting them—to the variousincompatible versions of Unix, and sometimes to other systems as well.

The process made these programs much more powerful, and attracted bothfunds and contributors to the GNU Project. But it probably alsodelayed completion of a minimal working system by several years, asGNU developers' time was put into maintaining these ports and addingfeatures to the existing components, rather than moving on to writeone missing component after another.

The GNU Hurd

By 1990, the GNU system was almost complete; the only major missingcomponent was the kernel. We had decided to implement our kernel as acollection of server processes running on top of Mach. Mach is amicrokernel developed at Carnegie Mellon University and then at theUniversity of Utah; the GNU Hurd is a collection of servers (i.e., aherd of GNUs) that run on top of Mach, and do thevarious jobs of the Unix kernel. The start of development was delayedas we waited for Mach to be released as free software, as had beenpromised.

One reason for choosing this design was to avoid what seemed to be thehardest part of the job: debugging a kernel program without asource-level debugger to do it with. This part of the job had beendone already, in Mach, and we expected to debug the Hurd servers asuser programs, with GDB. But it took a long time to make that possible,and the multithreaded servers that send messages to each other haveturned out to be very hard to debug. Making the Hurd work solidly hasstretched on for many years.

Alix

The GNU kernel was not originally supposed to be called the Hurd. Itsoriginal name was Alix—named after the woman who was my sweetheart atthe time. She, a Unix system administrator, had pointed out how hername would fit a common naming pattern for Unix system versions; as ajoke, she told her friends, “Someone should name a kernel afterme.” I said nothing, but decided to surprise her with a kernelnamed Alix.

It did not stay that way. Michael (now Thomas) Bushnell, the maindeveloper of the kernel, preferred the name Hurd, and redefined Alixto refer to a certain part of the kernel—the part that would trapsystem calls and handle them by sending messages to Hurd servers.

Later, Alix and I broke up, and she changed her name;independently, the Hurd design was changed so that the C library wouldsend messages directly to servers, and this made the Alix componentdisappear from the design.

But before these things happened, a friend of hers came across thename Alix in the Hurd source code, and mentioned it to her. Soshe did have the chance to find a kernel named after her.

Linux and GNU/Linux

The GNU Hurd is not suitable for production use, and we don't knowif it ever will be. The capability-based design has problems thatresult directly from the flexibility of the design, and it is notclear whether solutions exist.

Fortunately, another kernel is available. In 1991, Linus Torvaldsdeveloped a Unix-compatible kernel and called it Linux. It wasproprietary at first, but in 1992, he made it free software; combiningLinux with the not-quite-complete GNU system resulted in a completefree operating system. (Combining them was a substantial job initself, of course.) It is due to Linux that we can actually run aversion of the GNU system today.

We call this system versionGNU/Linux, to express its composition as a combination of the GNUsystem with Linux as the kernel. Please don't fall into the practiceof calling the whole system “Linux,” since that meansattributing our work to someone else.Pleasegive us equalmention.

Challenges in our future

We have proved our ability to develop a broad spectrum of freesoftware. This does not mean we are invincible and unstoppable.Several challenges make the future of free software uncertain; meetingthem will require steadfast effort and endurance, sometimes lastingfor years. It will require the kind of determination that peopledisplay when they value their freedom and will not let anyone take itaway.

The following four sections discuss these challenges.

Secret hardware

Hardware manufacturers increasingly tend to keep hardwarespecifications secret. This makes it difficult to write free driversso that Linux and XFree86 can support new hardware. We have completefree systems today, but we will not have them tomorrow if we cannotsupport tomorrow's computers.

There are two ways to cope with this problem. Programmers can doreverse engineering to figure out how to support the hardware. Therest of us can choose the hardware that is supported by free software;as our numbers increase, secrecy of specifications will become aself-defeating policy.

Reverse engineering is a big job; will we have programmers withsufficient determination to undertake it? Yes—if we have built up astrong feeling that free software is a matter of principle, andnonfree drivers are intolerable. And will large numbers of us spendextra money, or even a little extra time, so we can use free drivers?Yes, if the determination to have freedom is widespread [8].

Nonfree libraries

A nonfree library that runs on free operating systems acts as a trapfor free software developers. The library's attractive features arethe bait; if you use the library, you fall into the trap, because yourprogram cannot usefully be part of a free operating system. (Strictlyspeaking, we could include your program, but itwon'trunwith the library missing.) Even worse, ifa program that uses the proprietary library becomes popular, it canlure other unsuspecting programmers into the trap.

The first instance of this problem was the Motif toolkit, back in the80s. Although there were as yet no free operating systems, it wasclear what problem Motif would cause for them later on. The GNUProject responded in two ways: by asking individual free softwareprojects to support the free X Toolkit widgets as well as Motif, andby asking for someone to write a free replacement for Motif. The jobtook many years; LessTif, developed by the Hungry Programmers, becamepowerful enough to support most Motif applications only in 1997.

Between 1996 and 1998, another nonfreeGUItoolkitlibrary, called Qt, was used in a substantial collection of freesoftware, the desktopKDE.

Free GNU/Linux systems were unable to use KDE, because we could notuse the library. However, some commercial distributors of GNU/Linuxsystems who were not strict about sticking with free software addedKDE to their systems—producing a system with more capabilities,but less freedom. The KDE group was actively encouraging moreprogrammers to use Qt, and millions of new “Linux users”had never been exposed to the idea that there was a problem in this.The situation appeared grim.

The free software community responded to the problem in two ways:GNOME and Harmony.

GNOME, the GNU Network Object Model Environment, is GNU's desktopproject. Started in 1997 by Miguel de Icaza, and developed with thesupport of Red Hat Software, GNOME set out to provide similar desktopfacilities, but using free software exclusively. It has technicaladvantages as well, such as supporting a variety of languages, notjust C++. But its main purpose was freedom: not to require the use ofany nonfree software.

Harmony is a compatible replacement library, designed to make itpossible to run KDE software without using Qt.

In November 1998, the developers of Qt announced a change of licensewhich, when carried out, should make Qt free software. There is noway to be sure, but I think that this was partly due to thecommunity's firm response to the problem that Qt posed when it wasnonfree. (The new license is inconvenient and inequitable, so itremains desirable to avoid using Qt [9].)

How will we respond to the next tempting nonfree library? Will thewhole community understand the need to stay out of the trap? Or willmany of us give up freedom for convenience, and produce a majorproblem? Our future depends on our philosophy.

Software patents

The worst threat we face comes from software patents, which can putalgorithms and features off limits to free software for up to twentyyears. The LZW compression algorithm patents were applied for in1983, and we still cannot release free software to produce propercompressedGIF [10].In 1998, a free program to produceMP3compressed audiowas removed from distribution under threat of a patent suit [11].

There are ways to cope with patents: we can search for evidence that apatent is invalid, and we can look for alternative ways to do a job.But each of these methods works only sometimes; when both fail, apatent may force all free software to lack some feature that userswant. After a long wait, the patents expire, but what will we dountil then?

Those of us who value free software for freedom's sake will stay withfree software anyway. We will manage to get work done without thepatented features. But those who value free software because theyexpect it to be technically superior are likely to call it a failurewhen a patent holds it back. Thus, while it is useful to talk aboutthe practical effectiveness of the “bazaar” model ofdevelopment, and the reliability and power of some free software,we must not stop there. We must talk about freedom and principle.

Free documentation

The biggest deficiency in our free operating systems is not in thesoftware—it is the lack of good free manuals that we can include inour systems. Documentation is an essential part of any softwarepackage; when an important free software package does not come with agood free manual, that is a major gap. We have many such gaps today.

Free documentation, like free software, is a matter of freedom, notprice. The criterion for a free manual is pretty much the same as forfree software: it is a matter of giving all users certain freedoms.Redistribution (including commercial sale) must be permitted, onlineand on paper, so that the manual can accompany every copy of theprogram.

Permission for modification is crucial too. As a general rule, Idon't believe that it is essential for people to have permission tomodify all sorts of articles and books. For example, I don't thinkyou or I are obliged to give permission to modify articles like thisone, which describe our actions and our views.

But there is a particular reason why the freedom to modify is crucialfor documentation for free software. When people exercise their rightto modify the software, and add or change its features, if they areconscientious they will change the manual, too—so they canprovide accurate and usable documentation with the modified program.A nonfree manual, which does not allow programmers to be conscientiousand finish the job, does not fill our community's needs.

Some kinds of limits on how modifications are done pose no problem.For example, requirements to preserve the original author's copyrightnotice, the distribution terms, or the list of authors, are OK. It isalso no problem to require modified versions to include notice thatthey were modified, even to have entire sections that may not bedeleted or changed, as long as these sections deal with nontechnicaltopics. These kinds of restrictions are not a problem because theydon't stop the conscientious programmer from adapting the manual tofit the modified program. In other words, they don't block the freesoftware community from making full use of the manual.

However, it must be possible to modify all thetechnicalcontent ofthe manual, and then distribute the result in all the usual media,through all the usual channels; otherwise, the restrictions doobstruct the community, the manual is not free, and we need anothermanual.

Will free software developers have the awareness and determination toproduce a full spectrum of free manuals? Once again, our futuredepends on philosophy.

We must talk about freedom

Estimates today are that there are ten million users of GNU/Linuxsystems such as Debian GNU/Linux and Red Hat “Linux.”Free software has developed such practical advantages that users areflocking to it for purely practical reasons.

The good consequences of this are evident: more interest in developingfree software, more customers for free software businesses, and moreability to encourage companies to develop commercial free softwareinstead of proprietary software products.

But interest in the software is growing faster than awareness of thephilosophy it is based on, and this leads to trouble. Our ability tomeet the challenges and threats described above depends on the will tostand firm for freedom. To make sure our community has this will, weneed to spread the idea to the new users as they come into thecommunity.

But we are failing to do so: the efforts to attract new users into ourcommunity are far outstripping the efforts to teach them the civics ofour community. We need to do both, and we need to keep the twoefforts in balance.

“Open Source”

Teaching new users about freedom became more difficult in 1998, when apart of the community decided to stop using the term “freesoftware” and say “open source software”instead.

Some who favored this term aimed to avoid the confusion of“free” with “gratis”—a valid goal. Others,however, aimed to set aside the spirit of principle that had motivatedthe free software movement and the GNU Project, and to appeal insteadto executives and business users, many of whom hold an ideology thatplaces profit above freedom, above community, above principle. Thus,the rhetoric of “open source” focuses on the potential tomake high-quality, powerful software, but shuns the ideas of freedom,community, and principle.

The “Linux” magazines are a clear example of this—theyare filled with advertisements for proprietary software that workswith GNU/Linux. When the next Motif or Qt appears, will thesemagazines warn programmers to stay away from it, or will they run adsfor it?

The support of business can contribute to the community in many ways;all else being equal, it is useful. But winning their support byspeaking even less about freedom and principle can be disastrous; itmakes the previous imbalance between outreach and civics educationeven worse.

“Free software” and “open source” describe thesame category of software, more or less, but say different thingsabout the software, and about values. The GNU Project continues touse the term “free software,” to express the idea thatfreedom, not just technology, is important.

Try!

Yoda's aphorism (“There is no ‘try’”) soundsneat, but it doesn't work for me. I have done most of my work whileanxious about whether I could do the job, and unsure that it would beenough to achieve the goal if I did. But I tried anyway, becausethere was no one but me between the enemy and my city. Surprisingmyself, I have sometimes succeeded.

Sometimes I failed; some of my cities have fallen. Then I foundanother threatened city, and got ready for another battle. Over time,I've learned to look for threats and put myself between them and mycity, calling on other hackers to come and join me.

Nowadays, often I'm not the only one. It is a relief and a joy when Isee a regiment of hackers digging in to hold the line, and I realize,this city may survive—for now. But the dangers are greater eachyear, and now Microsoft has explicitly targeted our community. Wecan't take the future of freedom for granted. Don't take it forgranted! If you want to keep your freedom, you must be prepared todefend it.

Footnotes

1. The use of “hacker” to mean “securitybreaker” is a confusion on the part of the mass media. Wehackers refuse to recognize that meaning, and continue using the wordto mean someone who loves to program, someone who enjoys playfulcleverness, or the combination of the two. See myarticle, “OnHacking.”
2. As an Atheist, I don't follow any religious leaders, but Isometimes find I admire something one of them has said.
3. In 1984 or 1985, Don Hopkins (a very imaginative fellow) mailed mea letter.On the envelopehehad written several amusing sayings,including this one: “Copyleft—all rights reversed.” Iused the word “copyleft” to name the distribution conceptI was developing at the time.
4. We now use theGNU FreeDocumentation Licensefor documentation.
5. “Bourne Again Shell” is a play on the name“Bourne Shell,” which was the usual shell on Unix.
6. That was written in 1998. In 2009 we no longer maintain a longtask list. The community develops free software so fast that we can'teven keep track of it all. Instead, we have a list of High PriorityProjects, a much shorter list of projects we really want to encouragepeople to write.
7. This license was initially called the GNU Library GeneralPublic License, we renamed it to avoid giving the idea that alllibraries ought to use it. SeeWhy you shouldn't use theLesser GPL for your next libraryfor more information.
8. 2008 note: this issue extends to the BIOS as well. There is a freeBIOS,LibreBoot(a distribution ofcoreboot); the problem is getting specs for machines so thatLibreBoot can support them without nonfree “blobs.”
9. In September 2000, Qt was rereleased under the GNU GPL,which essentially solved this problem.
10. As of 2009, the GIF patents have expired.
11. As of 2017, the MP3 patents have expired. Look howlong we had to wait.