From: Marcin Borkowski <mbork@mbork.pl>
To: rms@gnu.org
Cc: van@scratch.space, emacs-devel@gnu.org
Subject: Re: Some ideas with Emacs
Date: Wed, 04 Dec 2019 01:37:11 +0100 [thread overview]
Message-ID: <87tv6hq62w.fsf@mbork.pl> (raw)
In-Reply-To: <E1ic0Gn-0003Ni-SQ@fencepost.gnu.org>
On 2019-12-03, at 05:58, Richard Stallman <rms@gnu.org> wrote:
> [[[ 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. ]]]
>
> > A _manual_ should be e.g. comprehensive (i.e., cover the whole of its
> > subject). A _book_ on a subject does not have to be so.
>
> I see the distinction you are making, but it doesn't affect our stance.
I see.
What about "non-free", paper-only books I asked about?
> Our principles of free documentation apply to any works that we would
> distribute or recommend to help people learn to use the software.
> Whether it is a manual meant to be complete, or a book that treats any
> choice of topics, if it doesn't carry a free license we ought not to
> refer users to it in any way. What we ought to do is use or write
> some free documentation to explain the same methods and techniques.
Let me say that I admire your stance (even if I do not agree with it).
I have to say that being convinced about existence of objective moral
principles and defending them firmly is a rare thing nowadays.
> > Could you define "political points which are outside the practical topic
> > of the manual"?
>
> There is a precise criterion in the GFDL itself.
I see.
> > The FSF does refer to e.g. MS
> > Windows (in the Emacs manual, of all places). How is a CC-NC/CC-ND book
> > (not "manual"!!!) worse than that?
>
> The Emacs manual does not recommend using Windows. It refers to
> running Emacs on Windows to encourage Windows users to run Emacs. We
> consider it ok to mention the existence of Windows because we expect
> users already know about it. It is unlikely anyone will learn about
> the existence of Windows from the Emacs Manual and start using Windows
> as a result.
OK, that makes sense.
> See the section References in the GNU Coding Standards for the way
> we judge such questions.
I read the relevant part. I think the crucial thing is (again) the
question whether such a book is "documentation" or not. (In my opinion
it is not.)
> We have the motto that a nonfree program is worse than no program at
> all. What does this mean?
>
> It is clear that a nonfree program might be of some practical use,
> whereas a nonexistent program is of zero practical use. The point of
> this motto is precisely that we don't judge solely by practical use.
> Our goal is to win freedom, so we prize freedom over practical use.
> The nonfree program is not a contribution to the free world -- rather,
> it is a trap that we should help people climb out of.
While I do not agree with you here, I admit that this stance is
consistent. And again, putting morality above practicality is something
I consider in general a rare and good thing. (BTW, off the top of my
head, I can't think of any organization believing really firmly in its
principles and valuing them above pragmatism even against a majority
besides the Roman Catholic Church and the FSF.)
> The same applied to documentation (manuals or not). Documentation simply
> means a work that teaches you how to use something. I think the book
> you have in mind would be documentation.
As I mentioned above, my definition is different. Let me try to
explain. (This may be a bit oversimplified, but I want to convey the
general idea. Also, I will use the word "free" in the sense you use it
to talk about software and documentation.)
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. It contains
nothing new you could not learn or easily think up yourself after you
read and understood the Elisp Reference. Its purpose is to teach Elisp
_in an easier and faster way_. I think it is nice but not required
(again, in the moral sense) that a textbook about free software is free.
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. So I would guess that there is some
subjectivity here - what is and what is not "documentation" depends on
the audience (a sufficiently advanced programmer does not need even the
Elisp Reference at all). This problem might mean that either I am
wrong, or it makes sense to consider an "average user" or a similar
construct.
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".
> Would you please make your book free, so that it contributes?
I am considering this as one of the options.
> > As an even more theoretical exercise, assume I wanted to write a book...
> > called "Memoirs of an Emacs user", which would be an artistic
> > representation of my process of Emacs and Org-mode gradually embracing
> > my life;-) - possibly including practical tips on Emacs usage? Would
> > you mind talking about it here?
>
> A book like this would not be documentation -- at least, mostly not.
> It would be a sort of memoir. I think CC-NC-ND is an acceptable
> license for a memoir, precisely because it is NOT documentation -- it
> does not have the purpose of teaching people practical skills or
> guiding them in doing a task.
>
> See https://gnu.org/philosophy/copyright-vs-community.html for more
> explanation.
Thanks for your explanation. I will definitely read that document.
Best regards,
--
Marcin Borkowski
http://mbork.pl
next prev parent reply other threads:[~2019-12-04 0:37 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 [this message]
2019-12-05 4:41 ` Richard Stallman
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=87tv6hq62w.fsf@mbork.pl \
--to=mbork@mbork.pl \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
--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).