rms> There are more than two alternatives for how much to support rms> this idea, and I haven't yet decided what I will do. I only rms> know one thing I will not do--I won't prominently advertise rms> in the Emacs distribution the possibility of using ssh. Forgive me if my memory is inaccurate, but it seems to me that Emacs (and gcc, for that matter) advertises prominently the possibility of its use on MS-DOS, SunOS, Solaris, IRIX, HP-UX, yadda, yadda. These OSes are not only not free, they are not even open source. It seems to me that use of a non-free helper application, especially if it conforms to a public protocol and API, is far preferable to use of a proprietary OS from the point of view of GNU's goals. I suspect that, as you imply, most XEmacs developers will prefer to be laid-back about the non-freeness of the ssh implementation. But if I were you, I would put in the hooks to use ssh (perhaps in the form of ftpsshd), along with a not-at-all-laid-back caveat: Currently, the only implementation of the ssh protocol which is widely available is the ssh implementation. This is not free software (*Note: A Taxonomy of Not-Quite-Free Software). If only a few of you who find this feature useful will donate some of your time or other resources to the GNU lsh project, we will quickly have a free implementation, with all the benefits that entails. Just because "embrace and extend" is most commonly associated with Watson, Gates, and other Vile Beasts doesn't mean we can't make it work for us. In fact, the GNU Manifesto is pretty explicit that that's what the strategy is. Isn't it? rms> This is one of the ways that the rivalry between Emacs and rms> XEmacs is detrimental to the Free Software Movement. It is a rms> popularity contest, which makes it hard to say no to anyone. rms> Doing whatever the typical users want tends to reinforce the rms> majority view, not to change it. IMO, telling people that because they consort with heathen, you won't give them the features they want (in security issues, they will surely promote that to "need") is more counterproductive. Give them options, and where they require helpers that aren't free, encourage them to help reimplement those helpers as free software. Giving options is what Emacs is best at. In the last couple of years, I've seen a _lot_ of people come to Linux for the price, and turn around and say "If this is what free software is about, I want to give something back. But I'm not a programmer. Help me help Linux!" This is reaching the level of a FAQ. If it reaches nonprogrammers, it's really contagious. Let's spread the contagion as widely as possible, by giving people as few excuses not to use free software as possible. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 "Kiss a Solaris programmer today."

On Sat, 23 Jan 1999, Richard Stallman wrote: I think this argument turned around has gotten our friend Bill into trouble with the government. It doesn't seem like emacs (or any product) should try to use its political-arm to convince people that a GNU ssl is a good thing. If such a thing should exist, let it be created of its own will. Of course, I'm not trying to convince you to write an ssl package for emacs. I just don't see a conflict with accepting a third-party ssl package. For example, there's a ClearCase VC backend. Do you consider that a bad thing? Is there a GNU ClearCase in the works? Is it ok because of the difficulty in providing a pure-GNU-based implementation? -Justin vallon(a)mindspring.com

rms> Forgive me if my memory is inaccurate, but it seems to me rms> that Emacs (and gcc, for that matter) advertises rms> prominently the possibility of its use on MS-DOS, SunOS, rms> Solaris, IRIX, HP-UX, yadda, yadda. rms> Right. Non-free operating systems and non-free add-ons are rms> different issues. I want to encourage people who are using rms> these non-free systems to add Emacs to them, but I don't want rms> to encourage people using free systems such as GNU/Linux to rms> backslide by installing ssh. What is wrong with this picture? Let folks use Emacs atop Windoze -- Good (exposes the unwashed to the wonders of Free Software). Let folks use Appgen atop Linux -- Bad (exposes the initiate to the wonders of applications not bundled with the OS). Four legs, good. Two legs, {bad,better}. -- Apologies to George Owell, _Animal Farm_, Secker and Warburg, London, 1945. rms> The readiness of people to add non-free programs to their rms> free operating systems is the greatest problem we face, and rms> explaining to people why this is bad is the greatest rms> challenge. Better that general users in need of ready-made applications like accounts payable, general ledger, ..., job cost tracking, professional billing should run something like Appgen, or Star Office, or any non-Free Software on SCO, AIX, Solaris, or even Windows/NT rather than contaminate Linux, right? That way they will learn even more about the advantages of Free Software. That way Linux will be even more readily and more broadly accepted, right? And the cause of Free Software will be boldly advanced where no free software has gone before. You bet. At <http://www.gnu.org/> one sees, under Freedoms and Rights, The FSF supports ... the right to use encryption software for private communication but there seems to be nothing there to indicate that the FSF supports the right to use encryption software for private communication _if and only if the software used is Free Software as defined by the FSF at <http://www.gnu.org/philosophy/free-sw.html>_. It would seem to this observer that either (1) the FSF does not consider the use of ssh with Emacs ange-ftp/efs to be using encryption software for private communication, or (2) the meaning of the word _support_ as used in this context by the FSF is rather weak, or (3) the FSF needs to amend and make more accurate the statement of the Freedoms and Rights it supports. If the freedom to be secure in one's communication is at least as important as the freedom to use Free Software then the following points seem to be pertinent. 1. The widest possible use and deployment of strong encryption for personal use is good. In fact rapid deployment and widespread use seems very important to make it less feasible for regulations and restrictions to be imposed upon the personal use of strong encryption. 2. The widest possible use and deployment of encryption software that uses Open Protocols and that has freely accessible source is good. Rapid deployment and widespread use of strong encryption software with accessible source seems more likely to thwart regulation and restrictions than deployment of software with inaccessible source or that uses proprietary protocols. 3. ssh1 is freely available for use (but not for sale), the source is freely available to all, the protocol is an open de-facto standard. ssh2, by contrast, is not freely usable in general. ssh2 includes a proprietary secure ftp-like capability. There exist ways to use conventional ftp using ssh1 port forwarding as illustrated by ftpsshd. Thus it seems feasible to let ange-ftp/efs use ssh1 or any other implementation that provides secure port forwarding. 4. ange-ftp/efs using ssh1 advances the goals of items 1 and 2 above while possibly replacing some of the deployment and use of ssh2 and other solutions that might employ software with inaccessible source or that uses proprietary protocols. 5. By failing to advance the goals of items 1 and 2 above the continued failure of ange-ftp/efs to use ssh1 at best encourages the rapid deployment and use of ssh2 and potentially software with inaccessible source or that uses proprietary protocols. At worst, failure of ange-ftp/efs to use ssh1 advances the prospects of having regulations and restrictions imposed upon the personal use of strong encryption. The choice is I believe just that stark. Moreover, which do you think will be more likely to use the GPLed lsh when it becomes a viable option: those that have used ange-ftp/efs with ssh1, or those who have adapted proprietary solutions like ssh2 or the like apart from Emacs. jam

rms> Let folks use Appgen atop Linux -- Bad (exposes the rms> initiate to the wonders of applications not bundled with rms> the OS). rms> Four legs, good. Two legs, {bad,better}. -- Apologies to rms> George Owell, _Animal Farm_, Secker and Warburg, London, rms> 1945. rms> You seem to be arguing that anyone who sees a significant rms> distinction between two situations is on a par with a rms> dictator. I must say that is not an impressive argument. No. I intended merely to point to what seems to me the ridiculousness of the distinction and to note a parallel with the absurdities associated with doctrinaire dogma. The reference to Orwell (please excuse my original misspelling) was to the absurdities of dogma, which in this context I found amusing partly because of the juxtaposition with crypto and the obvious Orwellian _1984_ overtones. I intended no _ad hominem_ implications and I am very sorry if my scribbling lead you to such an interpretation. I am curious to know when the evil of running non-Free software atop free operating systems became part of the dogma. Was it perhaps after Linux with its hospitality to commercial applications started to attract attention? My prefatory remark, "What is wrong with this picture?", I had hopped might have provoked an explanation, or a pointer to an explanation, as to why this "back-sliding" is so evil as you indicated in the sequel. I find the doctrine of back-sliding difficult to understand. You said rms0> Right. Non-free operating systems and non-free add-ons are rms0> different issues. I want to encourage people who are using rms0> these non-free systems to add Emacs to them, but I don't want rms0> to encourage people using free systems such as GNU/Linux to rms0> backslide by installing ssh. Do you consider ssh an "add-on" to Linux? I can think of only a few people who consider any arbitrary application to be anything like an "add-on" to an operating system. Please explain what you mean. Later you said rms0> The readiness of people to add non-free programs to their rms0> free operating systems is the greatest problem we face, and rms0> explaining to people why this is bad is the greatest rms0> challenge. Perhaps, without getting into the taxonomy of operating systems and applications, you can provide an indication of why it is evil to run non-free programs atop free operating systems. Am I deluded to think that such a restriction would diminish the usefulness of free operating systems? If I am not so deluded, then what is the rationale for the restriction? rms> The rest of your arguments seem unfair also. I don't think rms> you have much chance of changing my mind this way--perhaps we rms> should simply go back to our respective work. So parody is unfair? An explanation might dispell the suggestion that a distinction that lets Free Software run atop proprietary OSes while not letting proprietary software run atop Free OSes is arbitrary and counter to the purpose of advancing the use and acceptance of Free Software. Was it unfair of me to question the dogma with which you cited to dismiss the suggestions at hand? Until responding to your mail of the 23rd my contributions to this thread were concerned with ange-ftp/efs, ssh, and ftpssh. I did not introduce the theological issues. Which of the five points on ange-ftp/efs with ssh do you find to be unfair? I can only interpret your dismissal of the questions about the FSF's support of "the right to use encryption software for private communication" to be an indication that the support is rather unsubstantial. Together with your dismissal of arguments pertaining specifically to using ange-ftp/efs with ssh, the FSF support for crypto rights seems to me indeed to be qualified by conditions. Is it fair to ask why you stand in the way of using ange-ftp/efs with ssh while we have mailcrypt supporting pgp2 and pgp5? (XEmacs, rightly IMO, does not include mailcrypt support for pgp5.) jam

Please, if you're going to argue with Stallman about the purity and fundamentalism of Free software, can you leave me out of it? This discussion has gone *way* out of range and is wasting everyone's time. rms says: Fine. Again, the way I suggest dealing with this issue is to *support URLs* as a way of specifying alternate load methods. Deal with // as you have to, and I think the rest will be OK. In particular, I don't believe the relative pathname thing is an issue; I think a combination of using ~ and relative URLs will handle most user's needs. Then Emacs can remain pure with respect to ssh, and other folks can cleanly extend the types of file loading that Emacs allows, and the whole system is sane. nelson(a)media.mit.edu . . . . . . . . http://www.media.mit.edu/~nelson/