However, on a longer time scale, we can create alternatives to using servers. For instance, we can create a peer-to-peer program through which collaborators can share data encrypted. The free software community should develop distributed peer-to-peer replacements for important “web applications.” It may be wise to release them under GNU Affero GPL, since they are likely candidates for being converted into server-based programs by someone else. The GNU Project is looking for volunteers to work on such replacements. We also invite other free software projects to consider this issue in their design.
In the meantime, if a company invites you to use its server to do your own computing tasks, don’t yield; don’t use SaaS. Don’t buy or install “thin clients,” which are simply computers so weak they make you do the real work on a server, unless you’re going to use them with your server. Use a real computer and keep your data there. Do your work with your own copy of a free program, for your freedom’s sake.
Copyright c 2010 Richard Stallman
This essay was originally published in the online edition of the Boston Review, on 8 March 2010, under the title “What Does That Server Really Serve?” 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 34.
Free but Shackled: The Java Trap
Since this article was first published, on 12 April 2004, Sun has relicensed most of its Java platform reference implementation under the GNU General Public License, and there is now a free development environment for Java. Thus, the Java language as such is no longer a trap.
You must be careful, however, because not every Java platform is free. Sun continues distributing an executable Java platform which is nonfree, and other companies do so too.
The free environment for Java is called IcedTea; the source code Sun freed is included in that. So that is the one you should use. Many GNU/Linux distributions come with IcedTea, but some include nonfree Java platforms.
To reliably ensure your Java programs run fine in a free environment, you need to develop them using IcedTea. Theoretically the Java platforms should be compatible, but they are not compatible 100 percent.
In addition, there are nonfree programs with “Java” in their name, such as JavaFX, and there are nonfree Java packages you might find tempting but need to reject. So check the licenses of whatever packages you plan to use. If you use Swing, make sure to use the free version, which comes with IcedTea.
Aside from those Java specifics, the general issue described here remains important, because any nonfree library or programming platform can cause a similar problem. We must learn a lesson from the history of Java, so we can avoid other traps in the future.
If your program is free software, it is basically ethical—but there is a trap you must be on guard for. Your program, though in itself free, may be restricted by nonfree software that it depends on. Since the problem is most prominent today for Java programs, we call it the Java Trap.
A program is free software if its users have certain crucial freedoms. Roughly speaking, they are: the freedom to run the program, the freedom to study and change the source, the freedom to redistribute the source and binaries, and the freedom to publish improved versions. (See “The Free Software Definition,” on p. 3.) Whether any given program in source form is free software depends solely on the meaning of its license.
Whether the program can be used in the Free World, used by people who mean to live in freedom, is a more complex question. This is not determined by the program’s own license alone, because no program works in isolation. Every program depends on other programs. For instance, a program needs to be compiled or interpreted, so it depends on a compiler or interpreter. If compiled into byte code, it depends on a byte-code interpreter. Moreover, it needs libraries in order to run, and it may also invoke other separate programs that run in other processes. All of these programs are dependencies. Dependencies may be necessary for the program to run at all, or they may be necessary only for certain features. Either way, all or part of the program cannot operate without the dependencies.
If some of a program’s dependencies are nonfree, this means that all or part of the program is unable to run in an entirely free system—it is unusable in the Free World. Sure, we could redistribute the program and have copies on our machines, but that’s not much good if it won’t run. That program is free software, but it is effectively shackled by its nonfree dependencies.
This problem can occur in any kind of software, in any language. For instance, a free program that only runs on Microsoft Windows is clearly useless in the Free World. But software that runs on GNU/Linux can also be useless if it depends on other nonfree software. In the past, Motif (before we had LessTif) and Qt (before its developers made it free software) were major causes of this problem. Most 3D video cards work fully only with nonfree drivers, which also cause this problem. But the major source of this problem today is Java, because people who write free software often feel Java is sexy. Blinded by their attraction to the language, they overlook the issue of dependencies and fall into the Java Trap.
Sun’s implementation of Java is nonfree. The standard Java libraries are nonfree also. We do have free implementations of Java, such as the GNU Compiler for Java (GCJ) and GNU Classpath, but they don’t support all the features yet. We are still catching up.
If you develop a Java program on Sun’s Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months. You might say, “It’s too much work to start over.” Then your program will have fallen into the Java Trap; it will be unusable in the Free World.
The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system. Then if you use a Java feature or library that free software does not yet support, you will find out straightaway, and you can rewrite that code immediately.
Sun continues to develop additional “standard” Java libraries, and nearly all of them are nonfree; in many cases, even a library’s specification is a trade secret, and Sun’s latest license for these specifications prohibits release of anything less than a full implementation of the specification. (See http://jcp.org/aboutJava/communityprocess/JSPA2.pdf and http://jcp.org/aboutJava/communityprocess/final/jsr129/j2me_pb-1_0-fr-spec-license.html for examples.)
Fortunately, that specification license does permit releasing an implementation as free software; others who receive the library can be allowed to change it and are not required to adhere to the specification. But the requirement has the effect of prohibiting the use of a collaborative development model to produce the free implementation. Use of that model would entail publishing incomplete versions, something those who have read the spec are not allowed to do.