Free Software, Free Society: selected essays of Richard M. Stallman. 2nd edition.

The X Consortium did not carry out this plan. Instead it closed down and transferred X development to the Open Group, whose staff are now carrying out a similar plan. To give them credit, when I asked them to release X11R6.4 under the GNU GPL in parallel with their planned restrictive license, they were willing to consider the idea. (They were firmly against staying with the old X11 distribution terms.) Before they said yes or no to this proposal, it had already failed for another reason: the XFree86 group followed the X Consortium’s old policy, and will not accept copylefted software.

In September 1998, several months after X11R6.4 was released with nonfree distribution terms, the Open Group reversed its decision and rereleased it under the same noncopyleft free software license that was used for X11R6.3. Thus, the Open Group therefore eventually did what was right, but that does not alter the general issue.

Even if the X Consortium and the Open Group had never planned to restrict X, someone else could have done it. Noncopylefted software is vulnerable from all directions; it lets anyone make a nonfree version dominant, if he will invest sufficient resources to add significantly important features using proprietary code. Users who choose software based on technical characteristics, rather than on freedom, could easily be lured to the nonfree version for short-term convenience.

The X Consortium and Open Group can no longer exert moral suasion by saying that it is wrong to say no. This will make it easier to decide to copyleft your X-related software.

When you work on the core of X, on programs such as the X server, Xlib, and Xt, there is a practical reason not to use copyleft. The X.org group does an important job for the community in maintaining these programs, and the benefit of copylefting our changes would be less than the harm done by a fork in development. So it is better to work with them, and not copyleft our changes on these programs. Likewise for utilities such as xset and xrdb, which are close to the core of X and do not need major improvements. At least we know that the X.org group has a firm commitment to developing these programs as free software.

The issue is different for programs outside the core of X: applications, window managers, and additional libraries and widgets. There is no reason not to copyleft them, and we should copyleft them.

In case anyone feels the pressure exerted by the criteria for inclusion in the X distributions, the GNU Project will undertake to publicize copylefted packages that work with X. If you would like to copyleft something, and you worry that its omission from the X distribution will impede its popularity, please ask us to help.

At the same time, it is better if we do not feel too much need for popularity. When a businessman tempts you with “more popularity,” he may try to convince you that his use of your program is crucial to its success. Don’t believe it! If your program is good, it will find many users anyway; you don’t need to feel desperate for any particular users, and you will be stronger if you do not. You can get an indescribable sense of joy and freedom by responding, “Take it or leave it—that’s no skin off my back.” Often the businessman will turn around and accept the program with copyleft, once you call the bluff.

Friends, free software developers, don’t repeat old mistakes! If we do not copyleft our software, we put its future at the mercy of anyone equipped with more resources than scruples. With copyleft, we can defend freedom, not just for ourselves, but for our whole community.

Copyright c 1998, 1999, 2009 Richard Stallman

This essay was originally published on http://gnu.org, in 1998. This version is part of Free Software, Free Society: Selected Essays of Richard M. Stallman, 2nd ed. (Boston: GNU Press, 2010).

Verbatim copying and distribution of this entire chapter are permitted worldwide, without royalty, in any medium, provided this notice is preserved.

Chapter 37. The Problem Is Software Controlled by Its Developer

I fully agree with Jonathan Zittrain’s conclusion that we should not abandon general-purpose computers. Alas, I disagree completely with the path that led him to it. He presents serious security problems as an intolerable crisis, but I’m not convinced. Then he forecasts that users will panic in response and stampede toward restricted computers (which he calls “appliances”), but there is no sign of this happening.