From: "Robert J. Chassell" <bob@rattlesnake.com>
Cc: emacs-devel@gnu.org, andy@xemacs.org, xemacs-beta@xemacs.org
Subject: Re: Permission to use portions of the recent GNU Emacs Manual
Date: Mon, 13 Dec 2004 16:53:51 +0000 (UTC) [thread overview]
Message-ID: <m1CdtSJ-0004R2C@rattlesnake.com> (raw)
In-Reply-To: <E1CdpPR-0001mX-Ap@mail.agora-net.com> (message from Thien-Thi Nguyen on Mon, 13 Dec 2004 07:34:37 -0500)
To focus on Emacs when we are talking about licenses suggests to me
that you are more concerned with the development of that product than
with changing the political and business patterns of societies.
you are falling victim to a false dichotomy. the xemacs programmers are
certainly a society, ...
My apologies. I thought I was being clear: the society to which I am
referring is the larger society, at the very least that of Europe and
North America.
Yes, the xemacs programmers are certainly a society, but that is not
the one about which I am talking.
As I said earlier, Sun, 12 Dec 2004 16:07:52 +0000 (UTC)
... the entire purpose of a legal license is to provide an
interface between those who know something about the subject and
the vastly larger outside world.
The xemacs society is certainly not the `vastly larger outside world'.
I went on to say, Sun, 12 Dec 2004 19:43:59 +0000 (UTC)
... the issue here is the interface between certain professionals
in one industry and everyone else. ... people who are not
programmers and who do not know anything about computers or code.
....
Certainly, licenses are irrelevant to people who live in small
communities. In a small community, social pressure and personal
knowledge works well. 25 years ago, Unix and Lisp programmers lived
in such a community or many of them did. I think many programmers
wish they still lived in such a community.
But the wider world has intervened. Programming and its machines have
become successful. Even my grand-neice uses a computer. We do not
live in a small and isolated community any more.
That larger society is the one to which I am referring, not to the
society of xemacs programmers, all of whom know about computers and
code.
... a concept too vague to be useful ...
But we are talking about business models and their supporting laws.
These are NOT vague.
An organization has at least three options, none vague:
1. Should the organization generate revenue by lowering its output
and raising its price, and ensuring it can do that through law?
That is what a `Creative Commons license with a commercial
restriction' or one similar encourages.
2. Or should the organization generate revenue by increasing its
output and selling more ... and also permit others to free ride on
its unrecoverable costs, like attention getting, so it never
undertakes the action in the first place? That is what the GNU
GPL encourages for documentation.
3. Or, considering the GFDL, should the organization generate revenue
by increasing its output and selling more ... and also permit
competition, but with what I hope is the `right amount' of
restriction -- enough so the initiating organization can recover
costs so it will undertake actions but not so much that the
initiating organization can legally prevent any income-related
competition as it can with a `Creative Commons license with a
commercial restriction'.
It is worth saying again: a license on information is an interface
between certain professionals in one industry and everyone else.
The professionals may be software documentation writers or musicians
or others. An intermediate organization may gather attention for
their work and publish it using resources that are not recoverable.
(This is different from publishing on a hard disk, which you can
readily erase.)
Depending on the license, other people and other organizations may
deal with the same information. The wider society sets up default
ground rules and default assumptions.
In decades past, when the cost of publishing was higher than it is
now, and when major technological advances were funded and controlled
in the US by oligopolies, the default ground rule was that the
oligopolies controlled the people and prevented other organizations
from doing anything exactly similar to what they did.
That meant a competing oligopolist had to `invent around' the issue,
which was not too expensive for the oligopolist, but costly enough to
keep out most competitors. (This is according to a study I read years
ago; I can hunt up the reference if you want. The study was published
on paper in the 1970s or '80s and never put on the Web.)
The goal of the GNU project is to change the wider society's default
ground rules and default assumptions. The new rules and assumptions
are those in which professionals, like the xemacs developers, are
legally permitted to cooperate and in which intermediate organizations
may legally be created and may legally act.
--
Robert J. Chassell
bob@rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.rattlesnake.com http://www.teak.cc
next prev parent reply other threads:[~2004-12-13 16:53 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-09 22:28 Permission to use portions of the recent GNU Emacs Manual Ben Wing
2004-12-10 23:14 ` Richard Stallman
2004-12-11 0:59 ` Ben Wing
2004-12-11 1:06 ` Miles Bader
2004-12-11 10:27 ` Alan Mackenzie
2004-12-11 18:19 ` Eli Zaretskii
2004-12-11 20:43 ` David Kastrup
2004-12-11 19:02 ` Stefan Monnier
2004-12-12 0:26 ` Karl Fogel
2004-12-12 8:57 ` David Kastrup
2004-12-12 16:56 ` Brian Palmer
2004-12-12 13:31 ` Matthew Mundell
2004-12-12 13:40 ` David Kastrup
2004-12-12 2:03 ` Robert J. Chassell
2004-12-12 4:59 ` Karl Fogel
[not found] ` <m1CdWGG-0004R2C@rattlesnake.com>
2004-12-12 17:43 ` David Kastrup
2004-12-12 18:39 ` Florian Weimer
2004-12-12 19:24 ` David Kastrup
2004-12-12 19:49 ` Florian Weimer
2004-12-12 19:43 ` Robert J. Chassell
2004-12-12 19:59 ` David Kastrup
2004-12-12 20:46 ` Robert J. Chassell
2004-12-12 21:00 ` Andy Piper
2004-12-13 1:59 ` Robert J. Chassell
2004-12-13 2:23 ` David Kastrup
2004-12-13 12:34 ` Thien-Thi Nguyen
2004-12-13 16:53 ` Robert J. Chassell [this message]
2004-12-15 14:23 ` Stephen J. Turnbull
2004-12-15 19:14 ` Robert J. Chassell
2004-12-15 20:19 ` David Kastrup
2004-12-15 23:32 ` Robert J. Chassell
2004-12-17 5:36 ` Stephen J. Turnbull
2004-12-15 23:20 ` Richard Stallman
2004-12-16 10:58 ` David Kastrup
2004-12-16 12:18 ` Eli Zaretskii
2004-12-16 12:29 ` Kim F. Storm
2004-12-17 0:53 ` Richard Stallman
2004-12-18 10:20 ` Ben Wing
2004-12-18 23:32 ` Miles Bader
2004-12-19 6:31 ` Ben Wing
2004-12-19 6:32 ` Ben Wing
2004-12-19 13:54 ` Robert J. Chassell
2004-12-19 15:40 ` David Kastrup
2004-12-19 16:10 ` Paul Pogonyshev
2004-12-19 21:32 ` David Kastrup
2004-12-19 23:48 ` Paul Pogonyshev
2004-12-20 8:07 ` David Kastrup
2004-12-20 14:05 ` Robert J. Chassell
2004-12-20 0:19 ` Ben Wing
2004-12-20 7:20 ` David Kastrup
2004-12-20 10:58 ` Stephen J. Turnbull
2004-12-20 10:56 ` Richard Stallman
2004-12-20 12:47 ` David Kastrup
2004-12-17 1:32 ` Stephen J. Turnbull
2004-12-12 4:39 ` Richard Stallman
2004-12-12 6:16 ` Stefan Monnier
2004-12-12 21:28 ` Eli Zaretskii
2004-12-12 21:43 ` David Kastrup
2004-12-13 2:22 ` Robert J. Chassell
2004-12-13 6:48 ` Brian Palmer
2004-12-13 10:05 ` David Kastrup
2004-12-13 17:44 ` Bruce Stephens
2004-12-14 13:09 ` Stephen J. Turnbull
2004-12-14 2:56 ` Karl Fogel
2004-12-14 14:16 ` Robert J. Chassell
2004-12-13 4:23 ` Dhruva
2004-12-13 19:51 ` Richard Stallman
2004-12-13 20:03 ` David Kastrup
2004-12-14 10:03 ` Per Abrahamsen
2004-12-14 10:14 ` David Kastrup
2004-12-14 14:09 ` Robert J. Chassell
2004-12-14 14:25 ` David Kastrup
2004-12-14 20:19 ` Robert J. Chassell
2004-12-14 22:09 ` David Kastrup
2004-12-15 0:12 ` Robert J. Chassell
2004-12-15 8:03 ` Per Abrahamsen
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=m1CdtSJ-0004R2C@rattlesnake.com \
--to=bob@rattlesnake.com \
--cc=andy@xemacs.org \
--cc=emacs-devel@gnu.org \
--cc=xemacs-beta@xemacs.org \
/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).