Part VI. Traps and Challenges
Chapter 32.
Can You Trust Your Computer?
Who should your computer take its orders from? Most people think their computers should obey them, not obey someone else. With a plan they call “trusted computing,” large media corporations (including the movie companies and record companies), together with computer companies such as Microsoft and Intel, are planning to make your computer obey them instead of you. (Microsoft’s version of this scheme is called Palladium.) Proprietary programs have included malicious features before, but this plan would make it universal.
Proprietary software means, fundamentally, that you don’t control what it does; you can’t study the source code, or change it. It’s not surprising that clever businessmen find ways to use their control to put you at a disadvantage. Microsoft has done this several times: one version of Windows was designed to report to Microsoft all the software on your hard disk; a recent “security” upgrade in Windows Media Player required users to agree to new restrictions. But Microsoft is not alone: the KaZaA music-sharing software is designed so that KaZaA’s business partner can rent out the use of your computer to its clients. These malicious features are often secret, but even once you know about them it is hard to remove them, since you don’t have the source code.
In the past, these were isolated incidents. “Trusted computing” would make the practice pervasive. “Treacherous computing” is a more appropriate name, because the plan is designed to make sure your computer will systematically disobey you. In fact, it is designed to stop your computer from functioning as a general-purpose computer. Every operation may require explicit permission.
The technical idea underlying treacherous computing is that the computer includes a digital encryption and signature device, and the keys are kept secret from you. Proprietary programs will use this device to control which other programs you can run, which documents or data you can access, and what programs you can pass them to. These programs will continually download new authorization rules through the Internet, and impose those rules automatically on your work. If you don’t allow your computer to obtain the new rules periodically from the Internet, some capabilities will automatically cease to function.
Of course, Hollywood and the record companies plan to use treacherous computing for Digital Restrictions Management (DRM), so that downloaded videos and music can be played only on one specified computer. Sharing will be entirely impossible, at least using the authorized files that you would get from those companies. You, the public, ought to have both the freedom and the ability to share these things. (I expect that someone will find a way to produce unencrypted versions, and to upload and share them, so DRM will not entirely succeed, but that is no excuse for the system.)
Making sharing impossible is bad enough, but it gets worse. There are plans to use the same facility for email and documents—resulting in email that disappears in two weeks, or documents that can only be read on the computers in one company.
Imagine if you get an email from your boss telling you to do something that you think is risky; a month later, when it backfires, you can’t use the email to show that the decision was not yours. “Getting it in writing” doesn’t protect you when the order is written in disappearing ink.
Imagine if you get an email from your boss stating a policy that is illegal or morally outrageous, such as to shred your company’s audit documents, or to allow a dangerous threat to your country to move forward unchecked. Today you can send this to a reporter and expose the activity. With treacherous computing, the reporter won’t be able to read the document; her computer will refuse to obey her. Treacherous computing becomes a paradise for corruption.
Word processors such as Microsoft Word could use treacherous computing when they save your documents, to make sure no competing word processors can read them. Today we must figure out the secrets of Word format by laborious experiments in order to make free word processors read Word documents. If Word encrypts documents using treacherous computing when saving them, the free software community won’t have a chance of developing software to read them—and if we could, such programs might even be forbidden by the Digital Millennium Copyright Act.
Programs that use treacherous computing will continually download new authorization rules through the Internet, and impose those rules automatically on your work. If Microsoft, or the US government, does not like what you said in a document you wrote, they could post new instructions telling all computers to refuse to let anyone read that document. Each computer would obey when it downloads the new instructions. Your writing would be subject to 1984-style retroactive erasure. You might be unable to read it yourself.
You might think you can find out what nasty things a treacherous-computing application does, study how painful they are, and decide whether to accept them. Even if you can find this out, it would be foolish to accept the deal, but you can’t even expect the deal to stand still. Once you come to depend on using the program, you are hooked and they know it; then they can change the deal. Some applications will automatically download upgrades that will do something different—and they won’t give you a choice about whether to upgrade.
Today you can avoid being restricted by proprietary software by not using it. If you run GNU/Linux or another free operating system, and if you avoid installing proprietary applications on it, then you are in charge of what your computer does. If a free program has a malicious feature, other developers in the community will take it out, and you can use the corrected version. You can also run free application programs and tools on nonfree operating systems; this falls short of fully giving you freedom, but many users do it.
Treacherous computing puts the existence of free operating systems and free applications at risk, because you may not be able to run them at all. Some versions of treacherous computing would require the operating system to be specifically authorized by a particular company. Free operating systems could not be installed. Some versions of treacherous computing would require every program to be specifically authorized by the operating system developer. You could not run free applications on such a system. If you did figure out how, and told someone, that could be a crime.
There are proposals already for US laws that would require all computers to support treacherous computing, and to prohibit connecting old computers to the Internet. The CBDTPA (we call it the Consume But Don’t Try Programming Act) is one of them. But even if they don’t legally force you to switch to treacherous computing, the pressure to accept it may be enormous. Today people often use Word format for communication, although this causes several sorts of problems (see “We Can Put an End to Word Attachments,” on p. 231). If only a treacherous-computing machine can read the latest Word documents, many people will switch to it, if they view the situation only in terms of individual action (take it or leave it). To oppose treacherous computing, we must join together and confront the situation as a collective choice.
For further information about treacherous computing, see http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html.
To block treacherous computing will require large numbers of citizens to organize. We need your help! Please support Defective by Design, the FSF’s campaign against Digital Restrictions Management.
Postscripts
1. The computer security field uses the term “trusted computing” in a different way—beware of confusion between the two meanings.
2. The GNU Project distributes the GNU Privacy Guard, a program that implements public-key encryption and digital signatures, which you can use to send secure and private email. It is useful to explore how GPG differs from treacherous computing, and see what makes one helpful and the other so dangerous.
When someone uses GPG to send you an encrypted document, and you use GPG to decode it, the result is an unencrypted document that you can read, forward, copy, and even reencrypt to send it securely to someone else. A treacherous-computing application would let you read the words on the screen, but would not let you produce an unencrypted document that you could use in other ways. GPG, a free software package, makes security features available to the users; they use it. Treacherous computing is designed to impose restrictions on the users; it uses them.
3. The supporters of treacherous computing focus their discourse on its beneficial uses. What they say is often correct, just not important.
Like most hardware, treacherous-computing hardware can be used for purposes which are not harmful. But these features can be implemented in other ways, without treacherous-computing hardware. The principal difference that treacherous computing makes for users is the nasty consequence: rigging your computer to work against you.
What they say is true, and what I say is true. Put them together and what do you get? Treacherous computing is a plan to take away our freedom, while offering minor benefits to distract us from what we would lose.
4. Microsoft presents Palladium as a security measure, and claims that it will protect against viruses, but this claim is evidently false. A presentation by Microsoft Research in October 2002 stated that one of the specifications of Palladium is that existing operating systems and applications will continue to run; therefore, viruses will continue to be able to do all the things that they can do today.
When Microsoft employees speak of “security” in connection with Palladium, they do not mean what we normally mean by that word: protecting your machine from things you do not want. They mean protecting your copies of data on your machine from access by you in ways others do not want. A slide in the presentation listed several types of secrets Palladium could be used to keep, including “third party secrets” and “user secrets”—but it put “user secrets” in quotation marks, recognizing that this is somewhat of an absurdity in the context of Palladium.
The presentation made frequent use of other terms that we frequently associate with the context of security, such as “attack,” “malicious code,” “spoofing,” as well as “trusted.” None of them means what it normally means. “Attack” doesn’t mean someone trying to hurt you, it means you trying to copy music. “Malicious code” means code installed by you to do what someone else doesn’t want your machine to do. “Spoofing” doesn’t mean someone’s fooling you, it means your fooling Palladium. And so on.
5. A previous statement by the Palladium developers stated the basic premise that whoever developed or collected information should have total control of how you use it. This would represent a revolutionary overturn of past ideas of ethics and of the legal system, and create an unprecedented system of control. The specific problems of these systems are no accident; they result from the basic goal. It is the goal we must reject.
Copyright c 2002, 2007 Richard Stallman
This essay was first published on http://gnu.org, in 2002. 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.
Who should your computer take its orders from? Most people think their computers should obey them, not obey someone else. With a plan they call “trusted computing,” large media corporations (including the movie companies and record companies), together with computer companies such as Microsoft and Intel, are planning to make your computer obey them instead of you. (Microsoft’s version of this scheme is called Palladium.) Proprietary programs have included malicious features before, but this plan would make it universal.
Proprietary software means, fundamentally, that you don’t control what it does; you can’t study the source code, or change it. It’s not surprising that clever businessmen find ways to use their control to put you at a disadvantage. Microsoft has done this several times: one version of Windows was designed to report to Microsoft all the software on your hard disk; a recent “security” upgrade in Windows Media Player required users to agree to new restrictions. But Microsoft is not alone: the KaZaA music-sharing software is designed so that KaZaA’s business partner can rent out the use of your computer to its clients. These malicious features are often secret, but even once you know about them it is hard to remove them, since you don’t have the source code.
In the past, these were isolated incidents. “Trusted computing” would make the practice pervasive. “Treacherous computing” is a more appropriate name, because the plan is designed to make sure your computer will systematically disobey you. In fact, it is designed to stop your computer from functioning as a general-purpose computer. Every operation may require explicit permission.
The technical idea underlying treacherous computing is that the computer includes a digital encryption and signature device, and the keys are kept secret from you. Proprietary programs will use this device to control which other programs you can run, which documents or data you can access, and what programs you can pass them to. These programs will continually download new authorization rules through the Internet, and impose those rules automatically on your work. If you don’t allow your computer to obtain the new rules periodically from the Internet, some capabilities will automatically cease to function.
Of course, Hollywood and the record companies plan to use treacherous computing for Digital Restrictions Management (DRM), so that downloaded videos and music can be played only on one specified computer. Sharing will be entirely impossible, at least using the authorized files that you would get from those companies. You, the public, ought to have both the freedom and the ability to share these things. (I expect that someone will find a way to produce unencrypted versions, and to upload and share them, so DRM will not entirely succeed, but that is no excuse for the system.)
Making sharing impossible is bad enough, but it gets worse. There are plans to use the same facility for email and documents—resulting in email that disappears in two weeks, or documents that can only be read on the computers in one company.
Imagine if you get an email from your boss telling you to do something that you think is risky; a month later, when it backfires, you can’t use the email to show that the decision was not yours. “Getting it in writing” doesn’t protect you when the order is written in disappearing ink.
Imagine if you get an email from your boss stating a policy that is illegal or morally outrageous, such as to shred your company’s audit documents, or to allow a dangerous threat to your country to move forward unchecked. Today you can send this to a reporter and expose the activity. With treacherous computing, the reporter won’t be able to read the document; her computer will refuse to obey her. Treacherous computing becomes a paradise for corruption.
Word processors such as Microsoft Word could use treacherous computing when they save your documents, to make sure no competing word processors can read them. Today we must figure out the secrets of Word format by laborious experiments in order to make free word processors read Word documents. If Word encrypts documents using treacherous computing when saving them, the free software community won’t have a chance of developing software to read them—and if we could, such programs might even be forbidden by the Digital Millennium Copyright Act.
Programs that use treacherous computing will continually download new authorization rules through the Internet, and impose those rules automatically on your work. If Microsoft, or the US government, does not like what you said in a document you wrote, they could post new instructions telling all computers to refuse to let anyone read that document. Each computer would obey when it downloads the new instructions. Your writing would be subject to 1984-style retroactive erasure. You might be unable to read it yourself.
You might think you can find out what nasty things a treacherous-computing application does, study how painful they are, and decide whether to accept them. Even if you can find this out, it would be foolish to accept the deal, but you can’t even expect the deal to stand still. Once you come to depend on using the program, you are hooked and they know it; then they can change the deal. Some applications will automatically download upgrades that will do something different—and they won’t give you a choice about whether to upgrade.
Today you can avoid being restricted by proprietary software by not using it. If you run GNU/Linux or another free operating system, and if you avoid installing proprietary applications on it, then you are in charge of what your computer does. If a free program has a malicious feature, other developers in the community will take it out, and you can use the corrected version. You can also run free application programs and tools on nonfree operating systems; this falls short of fully giving you freedom, but many users do it.
Treacherous computing puts the existence of free operating systems and free applications at risk, because you may not be able to run them at all. Some versions of treacherous computing would require the operating system to be specifically authorized by a particular company. Free operating systems could not be installed. Some versions of treacherous computing would require every program to be specifically authorized by the operating system developer. You could not run free applications on such a system. If you did figure out how, and told someone, that could be a crime.
There are proposals already for US laws that would require all computers to support treacherous computing, and to prohibit connecting old computers to the Internet. The CBDTPA (we call it the Consume But Don’t Try Programming Act) is one of them. But even if they don’t legally force you to switch to treacherous computing, the pressure to accept it may be enormous. Today people often use Word format for communication, although this causes several sorts of problems (see “We Can Put an End to Word Attachments,” on p. 231). If only a treacherous-computing machine can read the latest Word documents, many people will switch to it, if they view the situation only in terms of individual action (take it or leave it). To oppose treacherous computing, we must join together and confront the situation as a collective choice.
For further information about treacherous computing, see http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html.
To block treacherous computing will require large numbers of citizens to organize. We need your help! Please support Defective by Design, the FSF’s campaign against Digital Restrictions Management.
Postscripts
1. The computer security field uses the term “trusted computing” in a different way—beware of confusion between the two meanings.
2. The GNU Project distributes the GNU Privacy Guard, a program that implements public-key encryption and digital signatures, which you can use to send secure and private email. It is useful to explore how GPG differs from treacherous computing, and see what makes one helpful and the other so dangerous.
When someone uses GPG to send you an encrypted document, and you use GPG to decode it, the result is an unencrypted document that you can read, forward, copy, and even reencrypt to send it securely to someone else. A treacherous-computing application would let you read the words on the screen, but would not let you produce an unencrypted document that you could use in other ways. GPG, a free software package, makes security features available to the users; they use it. Treacherous computing is designed to impose restrictions on the users; it uses them.
3. The supporters of treacherous computing focus their discourse on its beneficial uses. What they say is often correct, just not important.
Like most hardware, treacherous-computing hardware can be used for purposes which are not harmful. But these features can be implemented in other ways, without treacherous-computing hardware. The principal difference that treacherous computing makes for users is the nasty consequence: rigging your computer to work against you.
What they say is true, and what I say is true. Put them together and what do you get? Treacherous computing is a plan to take away our freedom, while offering minor benefits to distract us from what we would lose.
4. Microsoft presents Palladium as a security measure, and claims that it will protect against viruses, but this claim is evidently false. A presentation by Microsoft Research in October 2002 stated that one of the specifications of Palladium is that existing operating systems and applications will continue to run; therefore, viruses will continue to be able to do all the things that they can do today.
When Microsoft employees speak of “security” in connection with Palladium, they do not mean what we normally mean by that word: protecting your machine from things you do not want. They mean protecting your copies of data on your machine from access by you in ways others do not want. A slide in the presentation listed several types of secrets Palladium could be used to keep, including “third party secrets” and “user secrets”—but it put “user secrets” in quotation marks, recognizing that this is somewhat of an absurdity in the context of Palladium.
The presentation made frequent use of other terms that we frequently associate with the context of security, such as “attack,” “malicious code,” “spoofing,” as well as “trusted.” None of them means what it normally means. “Attack” doesn’t mean someone trying to hurt you, it means you trying to copy music. “Malicious code” means code installed by you to do what someone else doesn’t want your machine to do. “Spoofing” doesn’t mean someone’s fooling you, it means your fooling Palladium. And so on.
5. A previous statement by the Palladium developers stated the basic premise that whoever developed or collected information should have total control of how you use it. This would represent a revolutionary overturn of past ideas of ethics and of the legal system, and create an unprecedented system of control. The specific problems of these systems are no accident; they result from the basic goal. It is the goal we must reject.
Copyright c 2002, 2007 Richard Stallman
This essay was first published on http://gnu.org, in 2002. 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 33.
Who Does That Server Really Serve?
Background: How Proprietary Software Takes Away Your Freedom
Digital technology can give you freedom; it can also take your freedom away. The first threat to our control over our computing came from proprietary software: software that the users cannot control because the owner (a company such as Apple or Microsoft) controls it. The owner often takes advantage of this unjust power by inserting malicious features such as spyware, back doors, and Digital Restrictions Management (DRM) (referred to as “Digital Rights Management” in their propaganda).
Our solution to this problem is developing free software and rejecting proprietary software. Free software means that you, as a user, have four essential freedoms: (0) to run the program as you wish, (1) to study and change the source code so it does what you wish, (2) to redistribute exact copies, and (3) to redistribute copies of your modified versions. (See “The Free Software Definition,” on p. 3.)
With free software, we, the users, take back control of our computing. Proprietary software still exists, but we can exclude it from our lives and many of us have done so. However, we now face a new threat to our control over our computing: Software as a Service. For our freedom’s sake, we have to reject that too.
How Software as a Service Takes Away Your Freedom
Software as a Service (SaaS) means that someone sets up a network server that does certain computing tasks—running spreadsheets, word processing, translating text into another language, etc.—then invites users to do their computing on that server. Users send their data to the server, which does their computing on the data thus provided, then sends the results back or acts on them directly.
These servers wrest control from the users even more inexorably than proprietary software. With proprietary software, users typically get an executable file but not the source code. That makes it hard for programmers to study the code that is running, so it’s hard to determine what the program really does, and hard to change it.
With SaaS, the users do not have even the executable file: it is on the server, where the users can’t see or touch it. Thus it is impossible for them to ascertain what it really does, and impossible to change it.
Furthermore, SaaS automatically leads to harmful consequences equivalent to the malicious features of certain proprietary software. For instance, some proprietary programs are “spyware”: the program sends out data about users’ computing activities. Microsoft Windows sends information about users’ activities to Microsoft. Windows Media Player and RealPlayer report what each user watches or listens to.
Unlike proprietary software, SaaS does not require covert code to obtain the user’s data. Instead, users must send their data to the server in order to use it. This has the same effect as spyware: the server operator gets the data. He gets it with no special effort, by the nature of SaaS.
Some proprietary programs can mistreat users under remote command. For instance, Windows has a back door with which Microsoft can forcibly change any software on the machine. The Amazon Kindle e-book reader (whose name suggests it’s intended to burn people’s books) has an Orwellian back door that Amazon used in 2009 to remotely delete Kindle copies of Orwell’s books 1984 and Animal Farm which the users had purchased from Amazon.[1] SaaS inherently gives the server operator the power to change the software in use, or the users’ data being operated on. Once again, no special code is needed to do this.
Thus, SaaS is equivalent to total spyware and a gaping wide back door, and gives the server operator unjust power over the user. We can’t accept that.
Untangling the SaaS Issue from the Proprietary Software Issue
SaaS and proprietary software lead to similar harmful results, but the causal mechanisms are different. With proprietary software, the cause is that you have and use a copy which is difficult or illegal to change. With SaaS, the cause is that you use a copy you don’t have.
These two issues are often confused, and not only by accident. Web developers use the vague term “web application” to lump the server software together with programs run on your machine in your browser. Some web pages install nontrivial or even large JavaScript programs temporarily into your browser without informing you. When these JavaScript programs are nonfree, they are as bad as any other nonfree software. Here, however, we are concerned with the problem of the server software itself.
Many free software supporters assume that the problem of SaaS will be solved by developing free software for servers. For the server operator’s sake, the programs on the server had better be free; if they are proprietary, their owners have power over the server. That’s unfair to the operator, and doesn’t help you at all. But if the programs on the server are free, that doesn’t protect you as the server’s user from the effects of SaaS. They give freedom to the operator, but not to you.
Releasing the server software source code does benefit the community: suitably skilled users can set up similar servers, perhaps changing the software. But none of these servers would give you control over computing you do on it, unless it’s your server. The rest would all be SaaS. SaaS always subjects you to the power of the server operator, and the only remedy is, Don’t use SaaS! Don’t use someone else’s server to do your own computing on data provided by you.
Distinguishing SaaS from Other Network Services
Does condemning SaaS mean rejecting all network servers? Not at all. Most servers do not raise this issue, because the job you do with them isn’t your own computing except in a trivial sense.
The original purpose of web servers wasn’t to do computing for you, it was to publish information for you to access. Even today this is what most web sites do, and it doesn’t pose the SaaS problem, because accessing someone’s published information isn’t a matter of doing your own computing. Neither is publishing your own materials via a blog site or a microblogging service such as Twitter or identi.ca. The same goes for communication not meant to be private, such as chat groups. Social networking can extend into SaaS; however, at root it is just a method of communication and publication, not SaaS. If you use the service for minor editing of what you’re going to communicate, that is not a significant issue.
Services such as search engines collect data from around the web and let you examine it. Looking through their collection of data isn’t your own computing in the usual sense—you didn’t provide that collection—so using such a service to search the web is not SaaS. (However, using someone else’s search engine to implement a search facility for your own site is SaaS.)
E-commerce is not SaaS, because the computing isn’t solely yours; rather, it is done jointly for you and another party. So there’s no particular reason why you alone should expect to control that computing. The real issue in e-commerce is whether you trust the other party with your money and personal information.
Using a joint project’s servers isn’t SaaS because the computing you do in this way isn’t yours personally. For instance, if you edit pages on Wikipedia, you are not doing your own computing; rather, you are collaborating in Wikipedia’s computing.
Wikipedia controls its own servers, but groups can face the problem of SaaS if they do their group activities on someone else’s server. Fortunately, development hosting sites such as Savannah and SourceForge don’t pose the SaaS problem, because what groups do there is mainly publication and public communication, rather than their own private computing.
Multiplayer games are a group activity carried out on someone else’s server, which makes them SaaS. But where the data involved is just the state of play and the score, the worst wrong the operator might commit is favoritism. You might well ignore that risk, since it seems unlikely and very little is at stake. On the other hand, when the game becomes more than just a game, the issue changes.
Which online services are SaaS? Google Docs is a clear example. Its basic activity is editing, and Google encourages people to use it for their own editing; this is SaaS. It offers the added feature of collaborative editing, but adding participants doesn’t alter the fact that editing on the server is SaaS. (In addition, Google Docs is unacceptable because it installs a large nonfree JavaScript program into the users’ browsers.) If using a service for communication or collaboration requires doing substantial parts of your own computing with it too, that computing is SaaS even if the communication is not.
Some sites offer multiple services, and if one is not SaaS, another may be SaaS. For instance, the main service of Facebook is social networking, and that is not SaaS; however, it supports third-party applications, some of which may be SaaS. Flickr’s main service is distributing photos, which is not SaaS, but it also has features for editing photos, which is SaaS.
Some sites whose main service is publication and communication extend it with “contact management”: keeping track of people you have relationships with. Sending mail to those people for you is not SaaS, but keeping track of your dealings with them, if substantial, is SaaS.
If a service is not SaaS, that does not mean it is OK. There are other bad things a service can do. For instance, Facebook distributes video in Flash, which pressures users to run nonfree software, and it gives users a misleading impression of privacy. Those are important issues too, but this article’s concern is the issue of SaaS.
The IT industry discourages users from considering these distinctions. That’s what the buzzword “cloud computing” is for. This term is so nebulous that it could refer to almost any use of the Internet. It includes SaaS and it includes nearly everything else. The term only lends itself to uselessly broad statements.
The real meaning of “cloud computing” is to suggest a devil-may-care approach towards your computing. It says, “Don’t ask questions, just trust every business without hesitation. Don’t worry about who controls your computing or who holds your data. Don’t check for a hook hidden inside our service before you swallow it.” In other words, “Think like a sucker.” I prefer to avoid the term.
Dealing with the SaaS Problem
Only a small fraction of all web sites do SaaS; most don’t raise the issue. But what should we do about the ones that raise it?
For the simple case, where you are doing your own computing on data in your own hands, the solution is simple: use your own copy of a free software application. Do your text editing with your copy of a free text editor such as GNU Emacs or a free word processor. Do your photo editing with your copy of free software such as GIMP.
But what about collaborating with other individuals? It may be hard to do this at present without using a server. If you use one, don’t trust a server run by a company. A mere contract as a customer is no protection unless you could detect a breach and could really sue, and the company probably writes its contracts to permit a broad range of abuses. Police can subpoena your data from the company with less basis than required to subpoena them from you, supposing the company doesn’t volunteer them like the US phone companies that illegally wiretapped their customers for Bush. If you must use a server, use a server whose operators give you a basis for trust beyond a mere commercial relationship.
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.
Background: How Proprietary Software Takes Away Your Freedom
Digital technology can give you freedom; it can also take your freedom away. The first threat to our control over our computing came from proprietary software: software that the users cannot control because the owner (a company such as Apple or Microsoft) controls it. The owner often takes advantage of this unjust power by inserting malicious features such as spyware, back doors, and Digital Restrictions Management (DRM) (referred to as “Digital Rights Management” in their propaganda).
Our solution to this problem is developing free software and rejecting proprietary software. Free software means that you, as a user, have four essential freedoms: (0) to run the program as you wish, (1) to study and change the source code so it does what you wish, (2) to redistribute exact copies, and (3) to redistribute copies of your modified versions. (See “The Free Software Definition,” on p. 3.)
With free software, we, the users, take back control of our computing. Proprietary software still exists, but we can exclude it from our lives and many of us have done so. However, we now face a new threat to our control over our computing: Software as a Service. For our freedom’s sake, we have to reject that too.
How Software as a Service Takes Away Your Freedom
Software as a Service (SaaS) means that someone sets up a network server that does certain computing tasks—running spreadsheets, word processing, translating text into another language, etc.—then invites users to do their computing on that server. Users send their data to the server, which does their computing on the data thus provided, then sends the results back or acts on them directly.
These servers wrest control from the users even more inexorably than proprietary software. With proprietary software, users typically get an executable file but not the source code. That makes it hard for programmers to study the code that is running, so it’s hard to determine what the program really does, and hard to change it.
With SaaS, the users do not have even the executable file: it is on the server, where the users can’t see or touch it. Thus it is impossible for them to ascertain what it really does, and impossible to change it.
Furthermore, SaaS automatically leads to harmful consequences equivalent to the malicious features of certain proprietary software. For instance, some proprietary programs are “spyware”: the program sends out data about users’ computing activities. Microsoft Windows sends information about users’ activities to Microsoft. Windows Media Player and RealPlayer report what each user watches or listens to.
Unlike proprietary software, SaaS does not require covert code to obtain the user’s data. Instead, users must send their data to the server in order to use it. This has the same effect as spyware: the server operator gets the data. He gets it with no special effort, by the nature of SaaS.
Some proprietary programs can mistreat users under remote command. For instance, Windows has a back door with which Microsoft can forcibly change any software on the machine. The Amazon Kindle e-book reader (whose name suggests it’s intended to burn people’s books) has an Orwellian back door that Amazon used in 2009 to remotely delete Kindle copies of Orwell’s books 1984 and Animal Farm which the users had purchased from Amazon.[1] SaaS inherently gives the server operator the power to change the software in use, or the users’ data being operated on. Once again, no special code is needed to do this.
Thus, SaaS is equivalent to total spyware and a gaping wide back door, and gives the server operator unjust power over the user. We can’t accept that.
Untangling the SaaS Issue from the Proprietary Software Issue
SaaS and proprietary software lead to similar harmful results, but the causal mechanisms are different. With proprietary software, the cause is that you have and use a copy which is difficult or illegal to change. With SaaS, the cause is that you use a copy you don’t have.
These two issues are often confused, and not only by accident. Web developers use the vague term “web application” to lump the server software together with programs run on your machine in your browser. Some web pages install nontrivial or even large JavaScript programs temporarily into your browser without informing you. When these JavaScript programs are nonfree, they are as bad as any other nonfree software. Here, however, we are concerned with the problem of the server software itself.
Many free software supporters assume that the problem of SaaS will be solved by developing free software for servers. For the server operator’s sake, the programs on the server had better be free; if they are proprietary, their owners have power over the server. That’s unfair to the operator, and doesn’t help you at all. But if the programs on the server are free, that doesn’t protect you as the server’s user from the effects of SaaS. They give freedom to the operator, but not to you.
Releasing the server software source code does benefit the community: suitably skilled users can set up similar servers, perhaps changing the software. But none of these servers would give you control over computing you do on it, unless it’s your server. The rest would all be SaaS. SaaS always subjects you to the power of the server operator, and the only remedy is, Don’t use SaaS! Don’t use someone else’s server to do your own computing on data provided by you.
Distinguishing SaaS from Other Network Services
Does condemning SaaS mean rejecting all network servers? Not at all. Most servers do not raise this issue, because the job you do with them isn’t your own computing except in a trivial sense.
The original purpose of web servers wasn’t to do computing for you, it was to publish information for you to access. Even today this is what most web sites do, and it doesn’t pose the SaaS problem, because accessing someone’s published information isn’t a matter of doing your own computing. Neither is publishing your own materials via a blog site or a microblogging service such as Twitter or identi.ca. The same goes for communication not meant to be private, such as chat groups. Social networking can extend into SaaS; however, at root it is just a method of communication and publication, not SaaS. If you use the service for minor editing of what you’re going to communicate, that is not a significant issue.
Services such as search engines collect data from around the web and let you examine it. Looking through their collection of data isn’t your own computing in the usual sense—you didn’t provide that collection—so using such a service to search the web is not SaaS. (However, using someone else’s search engine to implement a search facility for your own site is SaaS.)
E-commerce is not SaaS, because the computing isn’t solely yours; rather, it is done jointly for you and another party. So there’s no particular reason why you alone should expect to control that computing. The real issue in e-commerce is whether you trust the other party with your money and personal information.
Using a joint project’s servers isn’t SaaS because the computing you do in this way isn’t yours personally. For instance, if you edit pages on Wikipedia, you are not doing your own computing; rather, you are collaborating in Wikipedia’s computing.
Wikipedia controls its own servers, but groups can face the problem of SaaS if they do their group activities on someone else’s server. Fortunately, development hosting sites such as Savannah and SourceForge don’t pose the SaaS problem, because what groups do there is mainly publication and public communication, rather than their own private computing.
Multiplayer games are a group activity carried out on someone else’s server, which makes them SaaS. But where the data involved is just the state of play and the score, the worst wrong the operator might commit is favoritism. You might well ignore that risk, since it seems unlikely and very little is at stake. On the other hand, when the game becomes more than just a game, the issue changes.
Which online services are SaaS? Google Docs is a clear example. Its basic activity is editing, and Google encourages people to use it for their own editing; this is SaaS. It offers the added feature of collaborative editing, but adding participants doesn’t alter the fact that editing on the server is SaaS. (In addition, Google Docs is unacceptable because it installs a large nonfree JavaScript program into the users’ browsers.) If using a service for communication or collaboration requires doing substantial parts of your own computing with it too, that computing is SaaS even if the communication is not.
Some sites offer multiple services, and if one is not SaaS, another may be SaaS. For instance, the main service of Facebook is social networking, and that is not SaaS; however, it supports third-party applications, some of which may be SaaS. Flickr’s main service is distributing photos, which is not SaaS, but it also has features for editing photos, which is SaaS.
Some sites whose main service is publication and communication extend it with “contact management”: keeping track of people you have relationships with. Sending mail to those people for you is not SaaS, but keeping track of your dealings with them, if substantial, is SaaS.
If a service is not SaaS, that does not mean it is OK. There are other bad things a service can do. For instance, Facebook distributes video in Flash, which pressures users to run nonfree software, and it gives users a misleading impression of privacy. Those are important issues too, but this article’s concern is the issue of SaaS.
The IT industry discourages users from considering these distinctions. That’s what the buzzword “cloud computing” is for. This term is so nebulous that it could refer to almost any use of the Internet. It includes SaaS and it includes nearly everything else. The term only lends itself to uselessly broad statements.
The real meaning of “cloud computing” is to suggest a devil-may-care approach towards your computing. It says, “Don’t ask questions, just trust every business without hesitation. Don’t worry about who controls your computing or who holds your data. Don’t check for a hook hidden inside our service before you swallow it.” In other words, “Think like a sucker.” I prefer to avoid the term.
Dealing with the SaaS Problem
Only a small fraction of all web sites do SaaS; most don’t raise the issue. But what should we do about the ones that raise it?
For the simple case, where you are doing your own computing on data in your own hands, the solution is simple: use your own copy of a free software application. Do your text editing with your copy of a free text editor such as GNU Emacs or a free word processor. Do your photo editing with your copy of free software such as GIMP.
But what about collaborating with other individuals? It may be hard to do this at present without using a server. If you use one, don’t trust a server run by a company. A mere contract as a customer is no protection unless you could detect a breach and could really sue, and the company probably writes its contracts to permit a broad range of abuses. Police can subpoena your data from the company with less basis than required to subpoena them from you, supposing the company doesn’t volunteer them like the US phone companies that illegally wiretapped their customers for Bush. If you must use a server, use a server whose operators give you a basis for trust beyond a mere commercial relationship.
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.
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.
In the early days of the free software movement, it was impossible to avoid depending on nonfree programs. Before we had the GNU C compiler, every C program (free or not) depended on a nonfree C compiler. Before we had the GNU C library, every program depended on a nonfree C library. Before we had Linux, the first free kernel, every program depended on a nonfree kernel. Before we had BASH, every shell script had to be interpreted by a nonfree shell. It was inevitable that our first programs would initially be hampered by these dependencies, but we accepted this because our plan included rescuing them subsequently. Our overall goal, a self-hosting GNU operating system, included free replacements for all those dependencies; if we reached the goal, all our programs would be rescued. Thus it happened: with the GNU/Linux system, we can now run these programs on free platforms.
The situation is different today. We now have powerful free operating systems and many free programming tools. Whatever job you want to do, you can do it on a free platform; there is no need to accept a nonfree dependency even temporarily. The main reason people fall into the trap today is because they are not thinking about it. The easiest solution to the problem is to teach people to recognize it and not fall into it.
To keep your Java code safe from the Java Trap, install a free Java development environment and use it. More generally, whatever language you use, keep your eyes open, and check the free status of programs your code depends on. The easiest way to verify that a program is free is by looking for it in the Free Software Directory (http://fsf.org/directory). If a program is not in the directory, you can check its license(s) against the list of free software licenses (http://gnu.org/licenses/license-list.html).
We are trying to rescue the trapped Java programs, so if you like the Java language, we invite you to help in developing GNU Classpath. Trying your programs with the GCJ Compiler and GNU Classpath, and reporting any problems you encounter in classes already implemented, is also useful. However, finishing GNU Classpath will take time; if more nonfree libraries continue to be added, we may never have all the latest ones. So please don’t put your free software in shackles. When you write an application program today, write it to run on free facilities from the start.
Copyright c 2004, 2006, 2010 Richard Stallman
This essay was first published on http://gnu.org, in 2004. 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 35.
The JavaScript Trap
In the free software community, the idea that nonfree programs mistreat their users is familiar. Some of us refuse entirely to install proprietary software, and many others consider nonfreedom a strike against the program. Many users are aware that this issue applies to the plug-ins that browsers offer to install, since they can be free or nonfree.
But browsers run other nonfree programs which they don’t ask you about or even tell you about—programs that web pages contain or link to. These programs are most often written in JavaScript, though other languages are also used.
JavaScript (officially called ECMAScript, but few use that name) was once used for minor frills in web pages, such as cute but inessential navigation and display features. It was acceptable to consider these as mere extensions of HTML markup, rather than as true software; they did not constitute a significant issue.
Many sites still use JavaScript that way, but some use it for major programs that do large jobs. For instance, Google Docs downloads into your machine a JavaScript program which measures half a megabyte, in a compacted form that we could call Obfuscript because it has no comments and hardly any whitespace, and the method names are one letter long. The source code of a program is the preferred form for modifying it; the compacted code is not source code, and the real source code of this program is not available to the user.
Browsers don’t normally tell you when they load JavaScript programs. Most browsers have a way to turn off JavaScript entirely, but none of them can check for JavaScript programs that are nontrivial and nonfree. Even if you’re aware of this issue, it would take you considerable trouble to identify and then block those programs. However, even in the free software community most users are not aware of this issue; the browsers’ silence tends to conceal it.
It is possible to release a JavaScript program as free software, by distributing the source code under a free software license. But even if the program’s source is available, there is no easy way to run your modified version instead of the original. Current free browsers do not offer a facility to run your own modified version instead of the one delivered in the page. The effect is comparable to tivoization, although not quite so hard to overcome.
JavaScript is not the only language web sites use for programs sent to the user. Flash supports programming through an extended variant of JavaScript. We will need to study the issue of Flash to make suitable recommendations. Silverlight seems likely to create a problem similar to Flash, except worse, since Microsoft uses it as a platform for nonfree codecs. A free replacement for Silverlight does not do the job for the free world unless it normally comes with free replacement codecs.
Java applets also run in the browser, and raise similar issues. In general, any sort of applet system poses this sort of problem. Having a free execution environment for an applet only brings us far enough to encounter the problem.
A strong movement has developed that calls for web sites to communicate only through formats and protocols that are free (some say “open”); that is to say, whose documentation is published and which anyone is free to implement. With the presence of programs in web pages, that criterion is necessary, but not sufficient. JavaScript itself, as a format, is free, and use of JavaScript in a web site is not necessarily bad. However, as we’ve seen above, it also isn’t necessarily OK. When the site transmits a program to the user, it is not enough for the program to be written in a documented and unencumbered language; that program must be free, too. “Only free programs transmitted to the user” must become part of the criterion for proper behavior by web sites.
Silently loading and running nonfree programs is one among several issues raised by “web applications.” The term “web application” was designed to disregard the fundamental distinction between software delivered to users and software running on the server. It can refer to a specialized client program running in a browser; it can refer to specialized server software; it can refer to a specialized client program that works hand in hand with specialized server software. The client and server sides raise different ethical issues, even if they are so closely integrated that they arguably form parts of a single program. This article addresses only the issue of the client-side software. We are addressing the server issue separately.
In practical terms, how can we deal with the problem of nonfree JavaScript programs in web sites? Here’s a plan of action.
First, we need a practical criterion for nontrivial JavaScript programs. Since “nontrivial” is a matter of degree, this is a matter of designing a simple criterion that gives good results, rather than determining the one correct answer.
Our proposal is to consider a JavaScript program nontrivial if it makes an AJAX request, and consider it nontrivial if it defines methods and either loads an external script or is loaded as one.
At the end of this article we propose a convention by which a nontrivial JavaScript program in a web page can state the URL where its source code is located, and can state its license too, using stylized comments.
Finally, we need to change free browsers to support freedom for users of pages with JavaScript. First of all, browsers should be able to tell the user about nontrivial nonfree JavaScript programs, rather than running them. Perhaps NoScript could be adapted to do this.
Browser users also need a convenient facility to specify JavaScript code to use instead of the JavaScript in a certain page. (The specified code might be total replacement, or a modified version of the free JavaScript program in that page.) Greasemonkey comes close to being able to do this, but not quite, since it doesn’t guarantee to modify the JavaScript code in a page before that program starts to execute. Using a local proxy works, but is too inconvenient now to be a real solution. We need to construct a solution that is reliable and convenient, as well as sites for sharing changes. The GNU Project would like to recommend sites which are dedicated to free changes only.
These features will make it possible for a JavaScript program included in a web page to be free in a real and practical sense. JavaScript will no longer be a particular obstacle to our freedom—no more than C and Java are now. We will be able to reject and even replace the nonfree nontrivial JavaScript programs, just as we reject and replace nonfree packages that are offered for installation in the usual way. Our campaign for web sites to free their JavaScript can then begin.
Thank you to Matt Lee and John Resig for their help in defining our proposed criterion, and to David Parunakian and Jaffar Rumith for bringing this issue to my attention.
Appendix: A Convention for Releasing Free JavaScript Programs
For references to corresponding source code, we recommend
// @source:
followed by the URL.
To indicate the license of the JavaScript code embedded in a page, we recommend putting the license notice between two notes of this form:
@licstart The following is the entire license notice for the
JavaScript code in this page.
...
@licend The above is the entire license notice
for the JavaScript code in this page.
Of course, all of this should be contained in a multiline comment.
The GNU GPL, like many other free software licenses, requires distribution of a copy of the license with both source and binary forms of the program. However, the GNU GPL is long enough that including it in a page with a JavaScript program can be inconvenient. You can remove that requirement, for code that you have the copyright on, with a license notice like this:
Copyright (C) YYYY Developer
The JavaScript code in this page is free software: you can
redistribute it and/or modify it under the terms of the GNU
General Public License (GNU GPL) as published by the Free Software
Foundation, either version 3 of the License, or (at your option)
any later version. The code is distributed WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
As additional permission under GNU GPL version 3 section 7, you
may distribute non-source (e.g., minimized or compacted) forms of
that code without the copy of the GNU GPL normally required by
section 4, provided you include this license notice and a URL
through which recipients can access the Corresponding Source.
Copyright c 2009, 2010 Richard Stallman
This essay was first published on http://gnu.org, in 2009. This version is part of Free Software, Free Society: Selected Essays of Richard M. Stallman, 2nd ed. (Boston: GNU Press, 2010).
This chapter is licensed under the Creative Commons Attribution-NoDerivs 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/3.0/us/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.
In the free software community, the idea that nonfree programs mistreat their users is familiar. Some of us refuse entirely to install proprietary software, and many others consider nonfreedom a strike against the program. Many users are aware that this issue applies to the plug-ins that browsers offer to install, since they can be free or nonfree.
But browsers run other nonfree programs which they don’t ask you about or even tell you about—programs that web pages contain or link to. These programs are most often written in JavaScript, though other languages are also used.
JavaScript (officially called ECMAScript, but few use that name) was once used for minor frills in web pages, such as cute but inessential navigation and display features. It was acceptable to consider these as mere extensions of HTML markup, rather than as true software; they did not constitute a significant issue.
Many sites still use JavaScript that way, but some use it for major programs that do large jobs. For instance, Google Docs downloads into your machine a JavaScript program which measures half a megabyte, in a compacted form that we could call Obfuscript because it has no comments and hardly any whitespace, and the method names are one letter long. The source code of a program is the preferred form for modifying it; the compacted code is not source code, and the real source code of this program is not available to the user.
Browsers don’t normally tell you when they load JavaScript programs. Most browsers have a way to turn off JavaScript entirely, but none of them can check for JavaScript programs that are nontrivial and nonfree. Even if you’re aware of this issue, it would take you considerable trouble to identify and then block those programs. However, even in the free software community most users are not aware of this issue; the browsers’ silence tends to conceal it.
It is possible to release a JavaScript program as free software, by distributing the source code under a free software license. But even if the program’s source is available, there is no easy way to run your modified version instead of the original. Current free browsers do not offer a facility to run your own modified version instead of the one delivered in the page. The effect is comparable to tivoization, although not quite so hard to overcome.
JavaScript is not the only language web sites use for programs sent to the user. Flash supports programming through an extended variant of JavaScript. We will need to study the issue of Flash to make suitable recommendations. Silverlight seems likely to create a problem similar to Flash, except worse, since Microsoft uses it as a platform for nonfree codecs. A free replacement for Silverlight does not do the job for the free world unless it normally comes with free replacement codecs.
Java applets also run in the browser, and raise similar issues. In general, any sort of applet system poses this sort of problem. Having a free execution environment for an applet only brings us far enough to encounter the problem.
A strong movement has developed that calls for web sites to communicate only through formats and protocols that are free (some say “open”); that is to say, whose documentation is published and which anyone is free to implement. With the presence of programs in web pages, that criterion is necessary, but not sufficient. JavaScript itself, as a format, is free, and use of JavaScript in a web site is not necessarily bad. However, as we’ve seen above, it also isn’t necessarily OK. When the site transmits a program to the user, it is not enough for the program to be written in a documented and unencumbered language; that program must be free, too. “Only free programs transmitted to the user” must become part of the criterion for proper behavior by web sites.
Silently loading and running nonfree programs is one among several issues raised by “web applications.” The term “web application” was designed to disregard the fundamental distinction between software delivered to users and software running on the server. It can refer to a specialized client program running in a browser; it can refer to specialized server software; it can refer to a specialized client program that works hand in hand with specialized server software. The client and server sides raise different ethical issues, even if they are so closely integrated that they arguably form parts of a single program. This article addresses only the issue of the client-side software. We are addressing the server issue separately.
In practical terms, how can we deal with the problem of nonfree JavaScript programs in web sites? Here’s a plan of action.
First, we need a practical criterion for nontrivial JavaScript programs. Since “nontrivial” is a matter of degree, this is a matter of designing a simple criterion that gives good results, rather than determining the one correct answer.
Our proposal is to consider a JavaScript program nontrivial if it makes an AJAX request, and consider it nontrivial if it defines methods and either loads an external script or is loaded as one.
At the end of this article we propose a convention by which a nontrivial JavaScript program in a web page can state the URL where its source code is located, and can state its license too, using stylized comments.
Finally, we need to change free browsers to support freedom for users of pages with JavaScript. First of all, browsers should be able to tell the user about nontrivial nonfree JavaScript programs, rather than running them. Perhaps NoScript could be adapted to do this.
Browser users also need a convenient facility to specify JavaScript code to use instead of the JavaScript in a certain page. (The specified code might be total replacement, or a modified version of the free JavaScript program in that page.) Greasemonkey comes close to being able to do this, but not quite, since it doesn’t guarantee to modify the JavaScript code in a page before that program starts to execute. Using a local proxy works, but is too inconvenient now to be a real solution. We need to construct a solution that is reliable and convenient, as well as sites for sharing changes. The GNU Project would like to recommend sites which are dedicated to free changes only.
These features will make it possible for a JavaScript program included in a web page to be free in a real and practical sense. JavaScript will no longer be a particular obstacle to our freedom—no more than C and Java are now. We will be able to reject and even replace the nonfree nontrivial JavaScript programs, just as we reject and replace nonfree packages that are offered for installation in the usual way. Our campaign for web sites to free their JavaScript can then begin.
Thank you to Matt Lee and John Resig for their help in defining our proposed criterion, and to David Parunakian and Jaffar Rumith for bringing this issue to my attention.
Appendix: A Convention for Releasing Free JavaScript Programs
For references to corresponding source code, we recommend
// @source:To indicate the license of the JavaScript code embedded in a page, we recommend putting the license notice between two notes of this form:
@licstart The following is the entire license notice for the
JavaScript code in this page.
...
@licend The above is the entire license notice
for the JavaScript code in this page.Of course, all of this should be contained in a multiline comment.
The GNU GPL, like many other free software licenses, requires distribution of a copy of the license with both source and binary forms of the program. However, the GNU GPL is long enough that including it in a page with a JavaScript program can be inconvenient. You can remove that requirement, for code that you have the copyright on, with a license notice like this:
Copyright (C) YYYY Developer
The JavaScript code in this page is free software: you can
redistribute it and/or modify it under the terms of the GNU
General Public License (GNU GPL) as published by the Free Software
Foundation, either version 3 of the License, or (at your option)
any later version. The code is distributed WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
As additional permission under GNU GPL version 3 section 7, you
may distribute non-source (e.g., minimized or compacted) forms of
that code without the copy of the GNU GPL normally required by
section 4, provided you include this license notice and a URL
through which recipients can access the Corresponding Source.Copyright c 2009, 2010 Richard Stallman
This essay was first published on http://gnu.org, in 2009. This version is part of Free Software, Free Society: Selected Essays of Richard M. Stallman, 2nd ed. (Boston: GNU Press, 2010).
This chapter is licensed under the Creative Commons Attribution-NoDerivs 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/3.0/us/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.
Chapter 36. The X Window System Trap
To copyleft or not to copyleft? That is one of the major controversies in the free software community. The idea of copyleft is that we should fight fire with fire—that we should use copyright to make sure our code stays free. The GNU General Public License (GNU GPL) is one example of a copyleft license.
Some free software developers prefer noncopyleft distribution. Noncopyleft licenses such as the XFree86 and BSD licenses are based on the idea of never saying no to anyone—not even to someone who seeks to use your work as the basis for restricting other people. Noncopyleft licensing does nothing wrong, but it misses the opportunity to actively protect our freedom to change and redistribute software. For that, we need copyleft.
For many years, the X Consortium was the chief opponent of copyleft. It exerted both moral suasion and pressure to discourage free software developers from copylefting their programs. It used moral suasion by suggesting that it is not nice to say no. It used pressure through its rule that copylefted software could not be in the X Distribution.
Why did the X Consortium adopt this policy? It had to do with their conception of success. The X Consortium defined success as popularity—specifically, getting computer companies to use the X Window System. This definition put the computer companies in the driver’s seat: whatever they wanted, the X Consortium had to help them get it.
Computer companies normally distribute proprietary software. They wanted free software developers to donate their work for such use. If they had asked for this directly, people would have laughed. But the X Consortium, fronting for them, could present this request as an unselfish one. “Join us in donating our work to proprietary software developers,” they said, suggesting that this is a noble form of self-sacrifice. “Join us in achieving popularity,” they said, suggesting that it was not even a sacrifice.
But self-sacrifice is not the issue: tossing away the defense that copyleft provides, which protects the freedom of the whole community, is sacrificing more than yourself. Those who granted the X Consortium’s request entrusted the community’s future to the goodwill of the X Consortium.
This trust was misplaced. In its last year, the X Consortium made a plan to restrict the forthcoming X11R6.4 release so that it would not be free software. They decided to start saying no, not only to proprietary software developers, but to our community as well.
There is an irony here. If you said yes when the X Consortium asked you not to use copyleft, you put the X Consortium in a position to license and restrict its version of your program, along with the code for the core of X.
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.
Zombie machines are a problem, but not a catastrophe. Moreover, far from panicking, most users ignore the issue. Today, people are indeed concerned about the danger of phishing (mail and web pages that solicit personal information for fraud), but using a browsing-only device instead of a general computer won’t protect you from that.
Meanwhile, Apple has reported that 25 percent of iPhones have been unlocked. Surely at least as many users would have preferred an unlocked iPhone but were afraid to try a forbidden recipe to obtain it. This refutes the idea that users generally prefer that their devices be locked.
It is true that a general computer lets you run programs designed to spy on you, restrict you, or even let the developer attack you. Such programs include KaZaA, RealPlayer, Adobe Flash, Windows Media Player, Microsoft Windows, and MacOS. Windows Vista does all three of those things; it also lets Microsoft change the software without asking, or command it to permanently cease normal functioning.
But restricted computers are no help, because they present the same problem for the same reason.
The iPhone is designed for remote attack by Apple. When Apple remotely destroys iPhones that users have unlocked to enable other uses, that is no better than when Microsoft remotely sabotages Vista. The TiVo is designed to enforce restrictions on access to the recordings you make, and reports what you watch. E-book readers such as the Amazon “Swindle” are designed to stop you from sharing and lending your books. Features that artificially obstruct use of your data are known as Digital Restrictions Management (DRM); our protest campaign against DRM is hosted at http://defectivebydesign.org. (Our adversaries call DRM “Digital Rights Management” based on their idea that restricting you is their right. When you choose a term, you choose your side.)
The nastiest of the common restricted devices are cell phones. They transmit signals for tracking your whereabouts even when switched “off”; the only way to stop this is to take out all the batteries. Many can also be turned on remotely, for listening, unbeknownst to you. (The FBI is already taking advantage of this feature, and the US Commerce Department lists this danger in its Security Guide.) Cellular phone network companies regularly install software in users phones, without asking, to impose new usage restrictions.
With a general computer you can escape by rejecting such programs. You don’t have to have KaZaA, RealPlayer, Adobe Flash, Windows Media Player, Microsoft Windows or MacOS on your computer (I don’t). By contrast, a restricted computer gives you no escape from the software built into it.
The root of this problem, both in general PCs and restricted computers, is software controlled by its developer. The developer (typically a corporation) controls what the program does, and prevents everyone else from changing it. If the developer decides to put in malicious features, even a master programmer cannot easily remove them.
The remedy is to give the users more control, not less. We must insist on free/libre software, software that the users are free to change and redistribute. Free/libre software develops under the control of its users: if they don’t like its features, for whatever reason, they can change them. If you’re not a programmer, you still get the benefit of control by the users. A programmer can make the improvements you would like, and publish the changed version. Then you can use it too.
With free/libre software, no one has the power to make a malicious feature stick. Since the source code is available to the users, millions of programmers are in a position to spot and remove the malicious feature and release an improved version; surely someone will do it. Others can then compare the two versions to verify independently which version treats users right. As a practical fact, free software is generally free of designed-in malware.
Many people do acquire restricted devices, but not for motives of security. Why do people choose them?
Sometimes it is because the restricted devices are physically smaller. I edit text all day (literally) and I find the keyboard and screen of a laptop well worth the size and weight. However, people who use computers differently may prefer something that fits in a pocket. In the past, these devices have typically been restricted, but they weren’t chosen for that reason.
Now they are becoming less restricted. In fact, the OpenMoko cell phone features a main computer running entirely free/libre software, including the GNU/Linux operating system normally used on PCs and servers.
A major cause for the purchase of some restricted computers is financial sleight of hand. Game consoles, and the iPhone, are sold for an unsustainably low price, and the manufacturers subsequently charge when you use them. Thus, game developers must pay the game console manufacturer to distribute a game, and they pass this cost on to the user. Likewise, AT&T pays Apple when an iPhone is used as a telephone. The low up-front price misleads customers into thinking they will save money.
If we are concerned about the spread of restricted computers, we should tackle the issue of the price deception that sells them. If we are concerned about malware, we should insist on free software that gives the users control.
Postnote
Zittrain’s suggestion to reduce the statute of limitations on software patent lawsuits is a tiny step in the right direction, but it is much easier to solve the whole problem. Software patents are an unnecessary, artificial danger imposed on all software developers and users in the US. Every program is a combination of many methods and techniques—thousands of them in a large program. If patenting these methods is allowed, then hundreds of those used in a given program are probably patented. (Avoiding them is not feasible; there may be no alternatives, or the alternatives may be patented too.) So the developers of the program face hundreds of potential lawsuits from parties unknown, and the users can be sued as well.
The complete, simple solution is to eliminate patents from the field of software. Since the patent system is created by statute, eliminating patents from software will be easy given sufficient political will. (See http://www.endsoftpatents.org.)
Copyright c 2008, 2010 Richard Stallman
This article was first published in the March/April 2008 issue of http://bostonreview.net and is a response to Jonathan Zittrain’s “Protecting the Internet without Wrecking It,” which was published in the same issue and is available at http://bostonreview.net/BR33.2/zittrain.php. 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.
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.
Zombie machines are a problem, but not a catastrophe. Moreover, far from panicking, most users ignore the issue. Today, people are indeed concerned about the danger of phishing (mail and web pages that solicit personal information for fraud), but using a browsing-only device instead of a general computer won’t protect you from that.
Meanwhile, Apple has reported that 25 percent of iPhones have been unlocked. Surely at least as many users would have preferred an unlocked iPhone but were afraid to try a forbidden recipe to obtain it. This refutes the idea that users generally prefer that their devices be locked.
It is true that a general computer lets you run programs designed to spy on you, restrict you, or even let the developer attack you. Such programs include KaZaA, RealPlayer, Adobe Flash, Windows Media Player, Microsoft Windows, and MacOS. Windows Vista does all three of those things; it also lets Microsoft change the software without asking, or command it to permanently cease normal functioning.
But restricted computers are no help, because they present the same problem for the same reason.
The iPhone is designed for remote attack by Apple. When Apple remotely destroys iPhones that users have unlocked to enable other uses, that is no better than when Microsoft remotely sabotages Vista. The TiVo is designed to enforce restrictions on access to the recordings you make, and reports what you watch. E-book readers such as the Amazon “Swindle” are designed to stop you from sharing and lending your books. Features that artificially obstruct use of your data are known as Digital Restrictions Management (DRM); our protest campaign against DRM is hosted at http://defectivebydesign.org. (Our adversaries call DRM “Digital Rights Management” based on their idea that restricting you is their right. When you choose a term, you choose your side.)
The nastiest of the common restricted devices are cell phones. They transmit signals for tracking your whereabouts even when switched “off”; the only way to stop this is to take out all the batteries. Many can also be turned on remotely, for listening, unbeknownst to you. (The FBI is already taking advantage of this feature, and the US Commerce Department lists this danger in its Security Guide.) Cellular phone network companies regularly install software in users phones, without asking, to impose new usage restrictions.
With a general computer you can escape by rejecting such programs. You don’t have to have KaZaA, RealPlayer, Adobe Flash, Windows Media Player, Microsoft Windows or MacOS on your computer (I don’t). By contrast, a restricted computer gives you no escape from the software built into it.
The root of this problem, both in general PCs and restricted computers, is software controlled by its developer. The developer (typically a corporation) controls what the program does, and prevents everyone else from changing it. If the developer decides to put in malicious features, even a master programmer cannot easily remove them.
The remedy is to give the users more control, not less. We must insist on free/libre software, software that the users are free to change and redistribute. Free/libre software develops under the control of its users: if they don’t like its features, for whatever reason, they can change them. If you’re not a programmer, you still get the benefit of control by the users. A programmer can make the improvements you would like, and publish the changed version. Then you can use it too.
With free/libre software, no one has the power to make a malicious feature stick. Since the source code is available to the users, millions of programmers are in a position to spot and remove the malicious feature and release an improved version; surely someone will do it. Others can then compare the two versions to verify independently which version treats users right. As a practical fact, free software is generally free of designed-in malware.
Many people do acquire restricted devices, but not for motives of security. Why do people choose them?
Sometimes it is because the restricted devices are physically smaller. I edit text all day (literally) and I find the keyboard and screen of a laptop well worth the size and weight. However, people who use computers differently may prefer something that fits in a pocket. In the past, these devices have typically been restricted, but they weren’t chosen for that reason.
Now they are becoming less restricted. In fact, the OpenMoko cell phone features a main computer running entirely free/libre software, including the GNU/Linux operating system normally used on PCs and servers.
A major cause for the purchase of some restricted computers is financial sleight of hand. Game consoles, and the iPhone, are sold for an unsustainably low price, and the manufacturers subsequently charge when you use them. Thus, game developers must pay the game console manufacturer to distribute a game, and they pass this cost on to the user. Likewise, AT&T pays Apple when an iPhone is used as a telephone. The low up-front price misleads customers into thinking they will save money.
If we are concerned about the spread of restricted computers, we should tackle the issue of the price deception that sells them. If we are concerned about malware, we should insist on free software that gives the users control.
Postnote
Zittrain’s suggestion to reduce the statute of limitations on software patent lawsuits is a tiny step in the right direction, but it is much easier to solve the whole problem. Software patents are an unnecessary, artificial danger imposed on all software developers and users in the US. Every program is a combination of many methods and techniques—thousands of them in a large program. If patenting these methods is allowed, then hundreds of those used in a given program are probably patented. (Avoiding them is not feasible; there may be no alternatives, or the alternatives may be patented too.) So the developers of the program face hundreds of potential lawsuits from parties unknown, and the users can be sued as well.
The complete, simple solution is to eliminate patents from the field of software. Since the patent system is created by statute, eliminating patents from software will be easy given sufficient political will. (See http://www.endsoftpatents.org.)
Copyright c 2008, 2010 Richard Stallman
This article was first published in the March/April 2008 issue of http://bostonreview.net and is a response to Jonathan Zittrain’s “Protecting the Internet without Wrecking It,” which was published in the same issue and is available at http://bostonreview.net/BR33.2/zittrain.php. 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 38. We Can Put an End to Word Attachments
Don’t you just hate receiving Word documents in email messages? Word attachments are annoying, but, worse than that, they impede people from switching to free software. Maybe we can stop this practice with a simple collective effort. All we have to do is ask each person who sends us a Word file to reconsider that way of doing things.
Most computer users use Microsoft Word. That is unfortunate for them, since Word is proprietary software, denying its users the freedom to study, change, copy, and redistribute it. And because Microsoft changes the Word file format with each release, its users are locked into a system that compels them to buy each upgrade whether they want a change or not. They may even find, several years from now, that the Word documents they are writing this year can no longer be read with the version of Word they use then.
But it hurts us, too, when they assume we use Word and send us (or demand that we send them) documents in Word format. Some people publish or post documents in Word format. Some organizations will only accept files in Word format: I heard from someone that he was unable to apply for a job because resumes had to be Word files. Even governments sometimes impose Word format on the public, which is truly outrageous.
For us users of free operating systems, receiving Word documents is an inconvenience or an obstacle. But the worst impact of sending Word format is on people who might switch to free systems: they hesitate because they feel they must have Word available to read the Word files they receive. The practice of using the secret Word format for interchange impedes the growth of our community and the spread of freedom. While we notice the occasional annoyance of receiving a Word document, this steady and persistent harm to our community usually doesn’t come to our attention. But it is happening all the time.
Many GNU users who receive Word documents try to find ways to handle them. You can manage to find the somewhat obfuscated ASCII text in the file by skimming through it. Free software today can read most Word documents, but not all—the format is secret and has not been entirely decoded. Even worse, Microsoft can change it at any time.
Worst of all, it has already done so. Microsoft Office 2007 uses by default a format based on the patented OOXML format. (This is the one that Microsoft got declared an “open standard” by political manipulation and packing standards committees.) The actual format is not entirely OOXML, and it is not entirely documented. Microsoft offers a gratis patent license for OOXML on terms which do not allow free implementations. We are thus beginning to receive Word files in a format that free programs are not even allowed to read.
When you receive a Word file, if you think of that as an isolated event, it is natural to try to cope by finding a way to read it. Considered as an instance of a pernicious systematic practice, it calls for a different approach. Managing to read the file is treating a symptom of an epidemic disease; what we really want to do is stop the disease from spreading. That means we must convince people not to send or post Word documents.
I therefore make a practice of responding to Word attachments with a polite message explaining why the practice of sending Word files is a bad thing, and asking the person to resend the material in a nonsecret format. This is a lot less work than trying to read the somewhat obfuscated ASCII text in the Word file. And I find that people usually understand the issue, and many say they will not send Word files to others any more.
If we all do this, we will have a much larger effect. People who disregard one polite request may change their practice when they receive multiple polite requests from various people. We may be able to give Don’t send Word format! the status of netiquette, if we start systematically raising the issue with everyone who sends us Word files.
To make this effort efficient, you will probably want to develop a canned reply that you can quickly send each time it is necessary. I’ve included two examples: the version I have been using recently, followed by a new version that teaches a Word user how to convert to other useful formats.
• You sent the attachment in Microsoft Word format, a secret proprietary format, so I cannot read it. If you send me the plain text, HTML, or PDF, then I could read it.
Sending people documents in Word format has bad effects, because that practice puts pressure on them to use Microsoft software. In effect, you become a buttress of the Microsoft monopoly. This specific problem is a major obstacle to the broader adoption of GNU/Linux. Would you please reconsider the use of Word format for communication with other people?
• You sent the attachment in Microsoft Word format, a secret proprietary format, so it is hard for me to read. If you send me plain text, HTML, or PDF, then I will read it.
Distributing documents in Word format is bad for you and for others. You can’t be sure what they will look like if someone views them with a different version of Word; they may not work at all.
Receiving Word documents is bad for you because they can carry viruses (see http://en.wikipedia.org/wiki/Macro_virus_(computing)). Sending Word documents is bad for you because a Word document normally includes hidden information about the author, enabling those in the know to pry into the author’s activities (maybe yours). Text that you think you deleted may still be embarrassingly present. See http://news.bbc.co.uk/2/hi/technology/3154479.stm for more info.
But above all, sending people Word documents puts pressure on them to use Microsoft software and helps to deny them any other choice. In effect, you become a buttress of the Microsoft monopoly. This pressure is a major obstacle to the broader adoption of free software. Would you please switch to a different way of sending files to other people, instead of Word format?
To convert the file to HTML using Word is simple. Open the document, click on File, then Save As, and in the Save As Type strip box at the bottom of the box, choose HTML Document or Web Page. Then choose Save. You can then attach the new HTML document instead of your Word document. Note that Word changes in inconsistent ways—if you see slightly different menu item names, please try them.
To convert to plain text is almost the same—instead of HTML Document, choose Text Only or Text Document as the Save As Type.
Your computer may also have a program to convert to PDF format. Select File, then Print. Scroll through available printers and select the PDF converter. Click on the Print button and enter a name for the PDF file when requested.
See http://gnu.org/philosophy/no-word-attachments.html for more about this issue.
You can use these replies verbatim if you like, or you can personalize them or write your own. By all means construct a reply that fits your ideas and your personality—if the replies are personal and not all alike, that will make the campaign more effective.
These replies are meant for individuals who send Word files. When you encounter an organization that imposes use of Word format, that calls for a different sort of reply; there you can raise issues of fairness that would not apply to an individual’s actions.
Some recruiters ask for resumes in Word format. Ludicrously, some recruiters do this even when looking for someone for a free software job. (Anyone using those recruiters for free software jobs is not likely to get a competent employee.) To help change this practice, you can put a link to http://gnu.org/philosophy/no-word-attachments.html into your resume, next to links to other formats of the resume. Anyone hunting for a Word version of the resume will probably read the page.
This essay talks about Word attachments, since they are by far the most common case. However, the same issues apply with other proprietary formats, such as PowerPoint and Excel. Please feel free to adapt the replies to cover those as well.
With our numbers, simply by asking, we can make a difference.
Copyright c 2002, 2007, 2010 Richard Stallman
This essay was originally published on http://gnu.org, in 2002. 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 39. Thank You, Larry McVoy
For the first time in my life, I want to thank Larry McVoy. He recently eliminated a major weakness of the free software community, by announcing the end of his campaign to entice free software projects to use and promote his nonfree software. Soon, Linux development will no longer use this program, and no longer spread the message that nonfree software is a good thing if it’s convenient.
My gratitude is limited, since it was McVoy that created the problem in the first place. But I still appreciate his decision to clear it up.
There are thousands of nonfree programs, and most merit no special attention, other than developing a free replacement. What made this program, BitKeeper, infamous and dangerous was its marketing approach: inviting high-profile free software projects to use it, so as to attract other paying users.
McVoy made the program available gratis to free software developers. This did not mean it was free software for them: they were privileged not to part with their money, but they still had to part with their freedom. They gave up the fundamental freedoms that define free software: freedom to run the program as you wish for any purpose, freedom to study and change the source code as you wish, freedom to make and redistribute copies, and freedom to publish modified versions.
The free software movement has said, “Think of ‘free speech,’ not ‘free beer’ ” since 1990. McVoy said the opposite; he invited developers to focus on the lack of monetary price, instead of on freedom. A free software activist would dismiss this suggestion, but those in our community who value technical advantage above freedom and community were susceptible to it.
McVoy’s great triumph was the adoption of this program for Linux development. No free software project is more visible than Linux. It is the kernel of the GNU/Linux operating system, an essential component, and users often mistake it for the entire system. As McVoy surely planned, the use of his program in Linux development was powerful publicity for it.
It was also, whether intentionally or not, a powerful political PR campaign, telling the free software community that freedom-denying software is acceptable as long as it’s convenient. If we had taken that attitude towards Unix in 1984, where would we be today? Nowhere. If we had accepted using Unix, instead of setting out to replace it, nothing like the GNU/Linux system would exist.
Of course, the Linux developers had practical reasons for what they did. I won’t argue with those reasons; they surely know what’s convenient for them. But they did not count, or did not value, how this would affect their freedom—or the rest of the community’s efforts.
A free kernel, even a whole free operating system, is not sufficient to use your computer in freedom; we need free software for everything else, too. Free applications, free drivers, free BIOS: some of those projects face large obstacles—the need to reverse engineer formats or protocols or pressure companies to document them, or to work around or face down patent threats, or to compete with a network effect. Success will require firmness and determination. A better kernel is desirable, to be sure, but not at the expense of weakening the impetus to liberate the rest of the software world.
When the use of his program became controversial, McVoy responded with distraction. For instance, he promised to release it as free software if the company went out of business. Alas, that does no good as long as the company remains in business. Linux developers responded by saying, “We’ll switch to a free program when you develop a better one.” This was an indirect way of saying, “We made the mess, but we won’t clean it up.”
Fortunately, not everyone in Linux development considered a nonfree program acceptable, and there was continuing pressure for a free alternative. Finally Andrew Tridgell developed an interoperating free program, so Linux developers would no longer need to use a nonfree program.
McVoy first blustered and threatened, but ultimately chose to go home and take his ball with him: he withdrew permission for gratis use by free software projects, and Linux developers will move to other software. The program they no longer use will remain unethical as long as it is nonfree, but they will no longer promote it, nor by using it teach others to give freedom low priority. We can begin to forget about that program.
We should not forget the lesson we have learned from it: Nonfree programs are dangerous to you and to your community. Don’t let them get a place in your life.
Copyright c 2005 Richard Stallman
This essay was originally published on http://gnu.org, in 2005. 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.
ТЕЛЕГРАМКанал с обзорами, анонсами новинок и книжными подборками
Книжный Вестник
Бот для удобного поиска книг (если не нашлось на сайте)
Поиск книг
Свежие любовные романы в удобных форматах
Любовные романы
О психологии, саморазвитии и личностном росте
Саморазвитие
Детективы и триллеры, все новинки
Детективы
Фантастика и фэнтези, все новинки
Фантастика
Отборные классические книги
Классика
ВКОНТАКТЕБиблиотека с любовными романами, которая наверняка придётся по вкусу женской части аудитории
Любовные романы
Библиотека с фантастикой и фэнтези, а также смежных жанров
Фантастика
Самые популярные книги в формате фб2
Топ фб2
книги