From: Richard Stallman <rms@gnu.org>
To: Marcin Borkowski <mbork@mbork.pl>
Cc: van@scratch.space, emacs-devel@gnu.org
Subject: Re: Some ideas with Emacs
Date: Wed, 04 Dec 2019 23:41:15 -0500 [thread overview]
Message-ID: <E1icix1-0006kR-Dt@fencepost.gnu.org> (raw)
In-Reply-To: <87tv6hq62w.fsf@mbork.pl> (message from Marcin Borkowski on Wed, 04 Dec 2019 01:37:11 +0100)
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Elisp Reference is documentation. It contains everything you need to
> understand Elisp. Its purpose is to _teach Elisp_. I think I agree
> that documentation to free software should (in the moral sense) be free.
> Elisp Intro is _not_ documentation, it is a textbook.
I think that that definition of "documentation" is too narrow.
Back when companies provided manuals along with their software, and
people generally read these manuals, the manuals generally included
introductions and reference manuals. For each component, there was an
introduction manual that you read to learn how to use it, and a
reference manual you would use to check specific points once you know,
generally, how to use it.
I wanted to provide this level of documentation for the GNU system,
but the amount of work would have been prohibitive. To reduce it, I
developed the method whereby a manual starts out as an introduction
and then changes into a reference. This generally requires a certain
amount of duplication, but much less than 100% duplication, so it
results in big savings of size and of work.
Emacs Lisp is a partial exception. Because Bob Chassell wrote the intro,
the main manual doesn't have to start out in an introductory manner.
However, the Emacs Manual does start out in an introductory manner.
It is written so you can read it straight through and learn to edit
with Emacs.
Turning to the broader ethical issue, I think that _all_ textbooks,
indeed all educational resources, ought to be free -- because they
exist to be _used_ for a practical job: f teaching or learning a
subject.
A calculus textbook is not documentation, because the subject
it teaches is not how to use some tool or appliance. But I think
the two are similar in the basic moralily of the cases.
The memoir you proposed writing is not an educational resource. It
would exist mainly to show your personal point of view, not for
practical use. Reading it could be interesting, but it would not be
_using_ the memoir. That is why I reach different conclusions about
the memoir.
> Now what I've written above is not strictly and logically correct:
> formally, you don't _ever_ need documentation for free software, because
> you have the source code.
Our judgments of right and wront for _our_ conduct have to take
account of its likely effects, and that depends on the world we are in.
If our users were superhuman, they might not need any sort of manuals
-- they would read the source code and that would be enough. They
might not even need to get software from anyone: a smart enough being
could write for itself all software it wants. But our users are
human, not in general smarter than we ourselves.
> Notice that the "References" section to GNU Coding Standards
> (https://www.gnu.org/prep/standards/standards.html#References), which
> was mentioned earlier in this thread, seems to suffer from a very
> similar problem when it uses the criterion of a non-free program or
> system to be "well known".
That is another example of paying attention to the nature of the world
we are in. If we knew that our users would defend their freedom
firmly once introduced to free software, we could mention nonfree
programs without worrying that readers would start to use them.
But that is not the case. We need to try to reconcile the goals of
(1) telling people how to get the best use of Emacs when they also use
some nonfree programs, (2) showing we condemn those nonfree programs
for taking away users' freedom, and (3) not encouraging use of them.
I think these goals are _mostly_ compatible: we can do all of them
pretty well together, even if not perfectly.
--
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
next prev parent reply other threads:[~2019-12-05 4:41 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-29 9:05 Some ideas with Emacs Anonymous
2019-11-29 11:16 ` Marcin Borkowski
2019-11-29 11:44 ` =?gb18030?B?QW5vbnltb3Vz?=
2019-11-30 5:54 ` Emanuel Berg via Emacs development discussions.
2019-11-30 5:51 ` Emanuel Berg via Emacs development discussions.
2019-12-01 5:57 ` Richard Stallman
2019-12-01 10:56 ` Marcin Borkowski
2019-12-01 11:08 ` Marcin Borkowski
2019-12-01 13:40 ` VanL
2019-12-01 14:07 ` Marcin Borkowski
2019-12-02 4:52 ` VanL
2019-12-02 6:12 ` Marcin Borkowski
2019-12-03 5:01 ` Richard Stallman
2019-12-03 15:45 ` Eli Zaretskii
2019-12-03 16:21 ` Emanuel Berg via Emacs development discussions.
2019-12-03 17:35 ` Eli Zaretskii
2019-12-03 17:59 ` Stefan Monnier
2019-12-03 19:51 ` Emanuel Berg via Emacs development discussions.
2019-12-03 19:32 ` Marcin Borkowski
2019-12-03 19:37 ` Eli Zaretskii
2019-12-03 23:08 ` Marcin Borkowski
2019-12-04 3:42 ` Eli Zaretskii
2019-12-06 18:29 ` Marcin Borkowski
2019-12-04 8:39 ` VanL
2019-12-03 23:12 ` Marcin Borkowski
2019-12-05 4:41 ` Richard Stallman
2019-12-06 6:51 ` VanL
2019-12-06 20:13 ` Marcin Borkowski
2019-12-06 23:58 ` VanL
2019-12-02 5:41 ` Richard Stallman
2019-12-02 12:53 ` Marcin Borkowski
2019-12-02 18:07 ` Stefan Monnier
2019-12-02 20:57 ` Marcin Borkowski
2019-12-02 21:19 ` Stefan Monnier
2019-12-02 22:13 ` Marcin Borkowski
2019-12-02 22:41 ` Stefan Monnier
2019-12-02 23:04 ` Marcin Borkowski
2019-12-03 0:20 ` Stefan Monnier
2019-12-03 23:26 ` Marcin Borkowski
2019-12-03 8:37 ` VanL
2019-12-03 10:14 ` Marcin Borkowski
2019-12-03 11:14 ` VanL
2019-12-05 4:44 ` Richard Stallman
2019-12-05 7:30 ` Elias Mårtenson
2019-12-06 4:11 ` Richard Stallman
2019-12-07 2:21 ` Elias Mårtenson
2019-12-08 5:06 ` Librepay Richard Stallman
2019-12-08 12:10 ` Librepay VanL
2019-12-03 5:03 ` Some ideas with Emacs Richard Stallman
2019-12-03 4:58 ` Richard Stallman
2019-12-04 0:37 ` Marcin Borkowski
2019-12-05 4:41 ` Richard Stallman [this message]
2020-05-11 19:37 ` Marcin Borkowski
2020-06-03 4:25 ` Richard Stallman
2019-11-29 11:37 ` Stefan Kangas
2019-11-29 11:59 ` Anonymous
2019-11-29 12:31 ` Emacs: the Editor for the Next Forty Years (was Re: Some ideas with Emacs) Juanma Barranquero
2019-11-29 13:22 ` Some ideas with Emacs Eli Zaretskii
2019-11-29 13:34 ` Stefan Kangas
2019-11-29 13:56 ` Eduardo Ochs
2019-11-29 14:13 ` Eli Zaretskii
2019-11-29 14:26 ` Anonymous
2019-11-30 3:51 ` Stefan Kangas
2019-12-01 3:14 ` Emanuel Berg via Emacs development discussions.
2019-11-29 15:36 ` Stefan Monnier
2019-11-29 18:58 ` Michael Albinus
2019-11-29 19:13 ` Adding examples in the doc (was: Some ideas with Emacs) Stefan Monnier
2019-11-29 19:30 ` Yuan Fu
2019-11-29 20:03 ` Adding examples in the doc Michael Albinus
2019-11-29 19:32 ` Some ideas with Emacs Eli Zaretskii
2019-11-29 20:09 ` Michael Albinus
2019-11-29 20:14 ` Eli Zaretskii
2019-11-29 20:25 ` Michael Albinus
2019-11-29 20:30 ` Eli Zaretskii
2019-12-01 6:25 ` Emanuel Berg via Emacs development discussions.
2019-12-01 7:35 ` Eduardo Ochs
2019-12-01 10:21 ` Michael Albinus
2019-12-01 6:19 ` Emanuel Berg via Emacs development discussions.
2019-11-29 21:42 ` Clément Pit-Claudel
2019-11-30 0:12 ` João Távora
2019-12-01 6:48 ` Emanuel Berg via Emacs development discussions.
2019-12-01 17:30 ` Eli Zaretskii
2019-11-30 0:44 ` Yuan Fu
2019-11-30 4:00 ` Stefan Kangas
2019-11-30 7:19 ` Eli Zaretskii
2019-11-30 7:05 ` Eli Zaretskii
2019-12-01 6:51 ` Emanuel Berg via Emacs development discussions.
2019-12-01 17:32 ` Eli Zaretskii
2019-12-01 18:25 ` Emanuel Berg via Emacs development discussions.
2019-12-01 19:44 ` Michael Welsh Duggan
2019-12-01 20:48 ` Eli Zaretskii
2019-12-01 21:35 ` Emanuel Berg via Emacs development discussions.
2019-12-02 3:32 ` Eli Zaretskii
2019-12-02 4:17 ` Emanuel Berg via Emacs development discussions.
2019-12-02 4:48 ` Yuan Fu
2019-12-02 4:53 ` Emanuel Berg via Emacs development discussions.
2019-12-02 15:57 ` Michael Albinus
2019-12-01 22:20 ` Michael Welsh Duggan
2019-12-01 22:46 ` Emanuel Berg via Emacs development discussions.
2019-12-01 6:46 ` Emanuel Berg via Emacs development discussions.
2019-12-01 3:21 ` Emanuel Berg via Emacs development discussions.
2019-12-01 6:04 ` Richard Stallman
2019-12-01 6:15 ` Emanuel Berg via Emacs development discussions.
2019-12-01 6:05 ` Richard Stallman
2019-11-29 15:43 ` Stefan Monnier
2019-11-29 16:04 ` Robert Pluim
2019-11-30 11:21 ` Emanuel Berg via Emacs development discussions.
2019-12-01 2:41 ` VanL
2019-12-01 18:05 ` Stefan Monnier
2019-12-01 18:36 ` Emanuel Berg via Emacs development discussions.
2019-12-03 6:07 ` Ag Ibragimov
2019-12-06 18:30 ` Marcin Borkowski
2019-12-06 19:18 ` Juanma Barranquero
2019-12-06 20:14 ` Marcin Borkowski
2019-12-06 21:22 ` Stefan Monnier
2019-12-06 21:26 ` Juanma Barranquero
2019-12-07 2:13 ` Ag Ibragimov
2019-12-07 3:14 ` Drew Adams
2019-12-10 20:55 ` Marcin Borkowski
2019-12-11 4:21 ` VanL
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1icix1-0006kR-Dt@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=mbork@mbork.pl \
--cc=van@scratch.space \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).