Re: Permission to use portions of the recent GNU Emacs Manual

[Robert J. Chassell]

   This is COMPLETELY relevant to this list, because the bottom issue is

   [a] XEmacs ...

However, on 12 Dec 2004, Andy Piper <address@hidden> said

    XEmacs explicitly does not collect papers ....

This means that XEmacs depends on charity.  In this case, it did not
receive charity.

Of course, people in the XEmacs project can complain, but they have
decided to do nothing about their license.  So that part of the issue
is not relevant to this list.

   [c] ... will you cross-license the manual for us?

That is only relevant if you may not legally change the modifiable
parts, and if the illegality of your modifying those parts, such as an
introduction, is less important than the principle the licensors are
trying to establish in the world.

Is it really true that legally you may not modify variant parts as you
wish?

As I said on 15 Dec 2004, I have been focusing on invariant issues,
the `freedoms from', rather than on the `freedoms to'.  But the
freedom to modify is strong.  Fair use is strong.  As I said, I am not
a lawyer; I am not skilled in these sorts of issues and I cannot tell
you legally one way or the other.

If my current understanding is correct, then you have no worries about
modifications and about creating short `how-to' manuals or whatever
from the Emacs manual.

I do think it is a bug that the GFDL is not undertandable by lay
people with only a little legal knowledge.  The XEmacs issue is
straightforward, but the modification and fair use issues are not.  In
particular, if I understand correctly, `fair use' is another feature,
like `derivative work', that is established by judges, not licenses.

As for the second issue:  do you think the purpose of the GFDL is
wrong, that is bad to permit invariant sections?

Of the various types of invariant section, are you against an
invariant section

     ... that deals exclusively with the relationship of the
     publishers or authors of the Document to the Document's overall
     subject (or to related matters) and contains nothing that could
     fall directly within that overall subject.

Are you against limitations on front and back cover texts?
Or think the limitations should be different?

As "Stephen J. Turnbull" <address@hidden> said correctly

    In general, authors of derivatives of works licensed under strong
    copyleft have _no_ choice.

When it started, the XEmacs project chose to depend on a license
chosen by someone else.

    You are trying to switch discussion from the difficulties of
    dealing with someone else's license to the simplicity of choosing
    your own.

But you (meaning the members of the XEmacs project) did not write
Emacs initially.  I know for sure.  You joined.  And then you decided
to stop being helpful in a major purpose of the GNU Emacs project -- I
am not talking about writing of code or documentation, of course; that
is a means, not an end.  And you decided, presuming Andy Piper is
right, to depend on charity.

Unless your (now I am speaking individually again) framing takes this
into account, it is erroneous.

You say, for example

    I am satisfied with the XEmacs strategy as I understand it because
    I believe that there is no security, period.

and speaking of SCO, say,

    If the meanest patent shark in the ocean, IBM, doesn't know what
    "good papers" look like, who does?

as if IBM is more important to SCO either than courts or than
investors on Wall Street who might be confused by a non-GPL'd license
conflict in which one side makes statements irrelevant to the case.
Note that the pay of SCO leaders depends on the value of SCO stock.

    Therefore I do not worry about "unanticipated" technical trouble
    when the bad guys simply resort to brute force---lies, FUD and
    expensive lawyers---rather than anything resembling legal
    reasoning.

But `technical trouble' is one way for the bad guys to fight.  It is
as if you believe that courts which are honest are the only way to
fight, not just a tool, like other tools.

    ... our (implicit) strategy is to interpret copyright claims as
    damage, and to code around it.

With patents, this is not always possible.

As you say, correctly,

    The FSF's strategy is less risky, but not a sure thing.

I agree.  It is not a sure thing.  That is why the FSF seeks help.
That is why it introduced the GFDL; it is better than a `Creative
Commons license with a commercial restriction' or similar license.

    Several hackers have pointed out the convergence between code and
    documentation ....

Yes.  The problem is, those who use rivalrous or non-recoverable
resources are more likely in practice to be publishers on CDs or paper
than those who provide code.

This may well not last too much longer -- it all depends on the
progress of technology, law, and business models.  But in the
meantime, it is simply the case that software tends to end up on
computers without using rivalrous or non-recoverable resources and
documentation ends up both on computers and on CDs and paper.  (This
is not always the case, but is frequent.)  Hence, the reason for a
license that deals with rivalrous or non-recoverable resources.

(Printed books and CDs are rivalrous resources.  Like a shirt, if you
have a book, I do not have it.  You can loan me the book and the
shirt, but then you have neither.  Your and my use rival each other's.
On the other hand, you can manufacture a copy of a program and give it
to me so cheaply that it is, in effect, non-rivalrous.)

A company that prints a book is in the hard-copy publishing business.
That is to say, in business terms, it tries to recover resources from
a decreasing marginal cost product that requires use of rivalrous
resources.  A software project is not like that.

Of course, software projects may also deal with rivalrous and
non-recoverable resources.  Marketing can be an example; but it looks
much less significant to software than to selling books.  After all,
intrinsically, software does not use rivalrous resources, but books
do.

--
    Robert J. Chassell
    address@hidden                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc