Permission to use portions of the recent GNU Emacs Manual

Permission to use portions of the recent GNU Emacs Manual

[Ben Wing]

Richard --

The GNU Emacs user's manual has changed its license to the GFDL.  The XEmacs
manual has a different license -- the GPL.  Because of contributions from
various parties, we cannot easily change our license, and apparently there
are incompatibilities between the GFDL and the GPL.

Therefore I am wondering if you will give us permission to incorporate parts
of the GNU Emacs manual under the existing XEmacs license, which reads

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

@ignore
Permission is granted to process this file through Tex and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).

@end ignore
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
sections entitled ``The GNU Manifesto'', ``Distribution'' and ``GNU
General Public License'' are included exactly as in the original, and
provided that the entire resulting derived work is distributed under the
terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that the sections entitled ``The GNU Manifesto'',
``Distribution'' and ``GNU General Public License'' may be included in a
translation approved by the author instead of in the original English.

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

[Richard Stallman]

    The GNU Emacs user's manual has changed its license to the GFDL.  The XEmacs
    manual has a different license -- the GPL.  Because of contributions from
    various parties, we cannot easily change our license,

Too bad.  I won't relicense such a large amount of material all
together.

If you show me specific parts you would like to use, I will consider
relicensing them.

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

[Ben Wing]

>     The GNU Emacs user's manual has changed its license to 
> the GFDL.  The XEmacs
>     manual has a different license -- the GPL.  Because of 
> contributions from
>     various parties, we cannot easily change our license,
> 
> Too bad.  I won't relicense such a large amount of material 
> all together.

Given that this manual used to be under the exact same license, and that
there are minimal differences between the two, and that XEmacs is a free
software project completely in the spirit of the "GNU Manifesto", what is
the problem?

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

[Miles Bader]

On Fri, Dec 10, 2004 at 06:59:50PM -0600, Ben Wing wrote:
> Given that this manual used to be under the exact same license, and that
> there are minimal differences between the two, and that XEmacs is a free
> software project completely in the spirit of the "GNU Manifesto", what is
> the problem?

If the entire manual was made available under the GPL as well, it would sort
of make using the GDFL a bit pointless, no?

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

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

[Alan Mackenzie]

Hi, Richard and Ben,

On Fri, 10 Dec 2004, Richard Stallman wrote:

>    The GNU Emacs user's manual has changed its license to the GFDL.
>    The XEmacs manual has a different license -- the GPL.  Because of
>    contributions from various parties, we cannot easily change our
>    license,

>Too bad.  I won't relicense such a large amount of material all
>together.

There is irony in that sentence.

>If you show me specific parts you would like to use, I will consider
>relicensing them.

I'm speaking as somebody who's put a significant amount of time into
amending the Emacs manual (e.g. programs.texi).  I did so under the
impression that what I was amending was free, in the same sense that
the Emacs Lisp that I contribute is free.

Some time later, my attention was drawn to the details of the GFDL.
Anybody wishing to use the contents of a GFD is obliged to copy the cover
sheets of the original.  This restriction seems analogous to one that,
say, allows functions to be used for decoding a compressed graphic but
not for encoding one.

What is the purpose of the GFDL?  I quote from the licence:  "The purpose
of this License is to make a manual ....  "free" in the sense of
freedom: to assure everyone the effective freedom to copy and
redistribute it, with or without modifying it, either commercially or
noncommercially."  Since the XEmacs team's freedom here is ineffective,
the GFDL is, on its own terms, broken.

I do not understand why the GFDL exists at all.  It seems to me that the
GPL is as adequate for manuals as it is for code.  I also don't
understand why the Emacs Manual's licence had to be changed - a prime
effect of this change was to annul people's freedom to combine old bits
of the manual with new bits.

My feeling is that this is just not the way things should be in the free
software community.  Put bluntly, having made contributions to the Emacs
manual, I feel duped.  Yes, the GFDL conforms to the terms of the
assignment papers I signed, but I don't think I should have to wave the
small print past a lawyer before signing this sort of thing.

Do I really want to make any more contributions to the Emacs manual?
That's not just a rhetorical question.

Richard, the GFDL is broken.  Please get it fixed, in a way which will
restore the XEmacs team's freedom to copy and modify the Emacs manual.

-- 
Alan Mackenzie (Munich, Germany)

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

[Eli Zaretskii]

> Date: Sat, 11 Dec 2004 10:27:39 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org, xemacs-beta@xemacs.org
> 
> What is the purpose of the GFDL?  I quote from the licence:  "The purpose
> of this License is to make a manual ....  "free" in the sense of
> freedom: to assure everyone the effective freedom to copy and
> redistribute it, with or without modifying it, either commercially or
> noncommercially."  Since the XEmacs team's freedom here is ineffective,
> the GFDL is, on its own terms, broken.

I think you are taking the ``free'' part too literally.  Free Software
or Free Documentation does not necessarily mean that you are ``free''
to do whatever you want with it.  For example, the GPL says that your
freedom is limited by the requirement to supply the sources together
with the binary.

So an argument that ``free'' means there are no limitations is an
invalid argument, IMHO.  A better argument would be whether the
limitations of freedom imposed by the GFDL are justified by the goals
of the Free Software movement.

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

[Stefan Monnier]

> What is the purpose of the GFDL?  I quote from the licence:  "The purpose
> of this License is to make a manual ....  "free" in the sense of
> freedom: to assure everyone the effective freedom to copy and
> redistribute it, with or without modifying it, either commercially or
> noncommercially."  Since the XEmacs team's freedom here is ineffective,
> the GFDL is, on its own terms, broken.

I have no real opinion on the GFDL, tho just because of the turmoil it has
caused and is still causing, I guess I'm rather annoyed by it.

But I think that this "freedom" argument is flawed.  "Freedom" means
something different to everyone, so it's not a very good way to convince
other people.  Especially in the context of the Free Software movement,
I understand "free" to apply to the program itself, not its user:
the program (or the doc) itself is "free", can't be harnessed/hijacked by
anyone.  It quite directly implies that people aren't "free" to use it as
they please.

I don't see any benefit from using the GFDL over the GPL that would justify
the downside of preventing the XEmacs people from using our documentation.
[ Unless we consider that as an upside, but I really don't see any good
reason why we should be so antagonizing. ] Similarly, the licensing problems
it can cause when extracting docs and doc-skeletons out of code
is worrisome.


        Stefan

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

[David Kastrup]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Sat, 11 Dec 2004 10:27:39 +0000 (GMT)
>> From: Alan Mackenzie <acm@muc.de>
>> Cc: emacs-devel@gnu.org, xemacs-beta@xemacs.org
>> 
>> What is the purpose of the GFDL?  I quote from the licence: "The
>> purpose of this License is to make a manual ....  "free" in the
>> sense of freedom: to assure everyone the effective freedom to copy
>> and redistribute it, with or without modifying it, either
>> commercially or noncommercially."  Since the XEmacs team's freedom
>> here is ineffective, the GFDL is, on its own terms, broken.
>
> I think you are taking the ``free'' part too literally.  Free
> Software or Free Documentation does not necessarily mean that you
> are ``free'' to do whatever you want with it.  For example, the GPL
> says that your freedom is limited by the requirement to supply the
> sources together with the binary.
>
> So an argument that ``free'' means there are no limitations is an
> invalid argument, IMHO.  A better argument would be whether the
> limitations of freedom imposed by the GFDL are justified by the
> goals of the Free Software movement.

And that, in my opinion, is not just a question about the GFDL itself,
but also what it is being applied to.

Personally, I consider it a good thing that the GFDL as an option for
authors exists: if I were to write a book with non-trivial
non-technical value, a book with a topic of its own, I'd consider the
GFDL a good choice to have that would be good for preserving parts of
my author's interest in the integrity of the work.

But while I like its availability where I consider it appropriate, I
think that it should not be applied to reference material intended to
accompany software distributions: it makes no sense to not be able to
copy examples and passages freely between doc strings and manual.  Of
course, the sole copyright owner of the material (like the FSF is for
its key project) _can_ do that, but it means that the project as a
whole is no longer governed by the spirit of a public licence: we now
have only a _single_ party that is allowed to manage the operations
needed to sensibly maintain the project as a whole.

Since combined GFDL/GPL projects break the spirit of a public licence
in, I consider the GFDL licence the wrong choice for material that is
basically maintained by the same set of authors and in the same manner
(CVS or whatever) together with GPLed software.  This would probably
hold for the majority of documentation in Texinfo format, with
possibly some arguable exceptions where a whole project is done
_completely_ under the GFDL, like some LaTeX references are, even
though the lack of ability for freely copying example code from and
back to GPLed projects might also apply here.

Of course it would be pointless to distribute the Emacs Lisp manual
under the GFDL while giving the XEmacs team full licence to use it
under the GPL.  I agree with that.  But I also think that the Emacs
Lisp manual is a prime example of a manual that should be available
under the GPL outright to begin with, because it evolves together with
and inseparable from Emacs, and having it under a different licence
means that we use copyright for throwing a permanent monkey wrench for
maintenance into any forks of the project not done by the copyright
owner itself, defeating the "public" in the "GNU General Public
Licence".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I don't see any benefit from using the GFDL over the GPL that would justify
> the downside of preventing the XEmacs people from using our documentation.
> [ Unless we consider that as an upside, but I really don't see any good
> reason why we should be so antagonizing. ] Similarly, the licensing problems
> it can cause when extracting docs and doc-skeletons out of code
> is worrisome.

I agree.

It is bad that our docs are license-incompatible with XEmacs's GPL'd
docs.  It is also confusing how the GFDL interacts with extracted docs
from non-GFDL code, as you point out.

In general, the GFDL's requirements take a great deal of time and
concentration to understand (this is heard so often, from so many,
that I trust it is uncontroversial now).  This makes the GFDL
problematic for reference documentation like the Emacs manual, because
such documentation gets small, lightweight contributions from many
different people.  The burden of simply *understanding* the GFDL
significantly raises the overhead of making an individual
contribution.

I am reluctant to contribute to the Emacs manual under the GFDL.  I
feel like my contributions are going into a restrictive pool, where
many will not be able to make use of them.  Apparently, Alan Mackenzie
feels this way too.  I wonder how many others?

No one who works on Emacs would be reluctant to contribute to a GPL'd
manual, I'll bet.

-Karl

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

[Robert J. Chassell]

   What is the purpose of the GFDL?  

The prime purpose of the GFDL is to encourage more publishers to
provide commercial, free documentation.  

Publishers have told me that they are afraid that without some kind of
legal obligation to publish a few words on the front and back covers
they will be ripped off by free riders.  Were they to invest in
gathering people's attention, others would benefit.  So they did not
invest in providing commercial, free documentation.  

The strategy may be wrong.  Businesses may not compete with one
another.  They may not care whether they lose revenue to free riders
and others.  But I do not think so.  (Indeed, most of the free works I
see nowadays in commercial publications are under more restrictive
`Creative Commons' licenses, so there is an argument that the GFDL is
not restrictive enough.)

>From my knowledge, many businessmen fear that other businessmen will
compete, one way or the other.  For example, a long time ago Tim
O'Reilly told me that he believed that powerful people in Macmillan
hoped to destroy his publishing house before it became well
established.  Perhaps he was delusional.  Or perhaps he was correct.
I think he was more likely correct than wrong.  In any event, others
have said the same.

The GFDL is designed to reduce the benefits to free riders.  That is
its prime purpose.  (It has secondary purposes, too, like enabling
people to write personal introductions that legally will remain
invariant.)  As I said, there is short term evidence that the GFDL is
insufficiently restrictive; but I do not see how it could be made more
restrictive and still be free in any meaningful sense.

It is not pleasant to live in a world where good guys are hurt by bad
guys, but that the way the world is.

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

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

[Richard Stallman]

    I do not understand why the GFDL exists at all.  It seems to me that the
    GPL is as adequate for manuals as it is for code.

The GPL was designed for software, not for books.  The GPL's
requirements would be quite inconvenient for anyone who wanted to
publish a printed book from the material.

I think the GFDL says more or less what it ought to say.

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

[Karl Fogel]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> The prime purpose of the GFDL is to encourage more publishers to
> provide commercial, free documentation.  
> 
> Publishers have told me that they are afraid that without some kind of
> legal obligation to publish a few words on the front and back covers
> they will be ripped off by free riders.  Were they to invest in
> gathering people's attention, others would benefit.  So they did not
> invest in providing commercial, free documentation.  
> 
> The strategy may be wrong.  Businesses may not compete with one
> another.  They may not care whether they lose revenue to free riders
> and others.  But I do not think so.  (Indeed, most of the free works I
> see nowadays in commercial publications are under more restrictive
> `Creative Commons' licenses, so there is an argument that the GFDL is
> not restrictive enough.)
> 
> From my knowledge, many businessmen fear that other businessmen will
> compete, one way or the other.  For example, a long time ago Tim
> O'Reilly told me that he believed that powerful people in Macmillan
> hoped to destroy his publishing house before it became well
> established.  Perhaps he was delusional.  Or perhaps he was correct.
> I think he was more likely correct than wrong.  In any event, others
> have said the same.

If O'Reilly was worried about this at one point, they've loosened up
considerably.  They're now happily publishing books under considerably
*less* restrictive [than the GFDL] Creative Commons licenses --
licenses that do not have, for example, front- and back-cover
requirements, or invariant portion requirements.

> The GFDL is designed to reduce the benefits to free riders.  That is
> its prime purpose.  (It has secondary purposes, too, like enabling
> people to write personal introductions that legally will remain
> invariant.)  As I said, there is short term evidence that the GFDL is
> insufficiently restrictive; but I do not see how it could be made more
> restrictive and still be free in any meaningful sense.

(Thanks for the summary of the GFDL's purposes -- very helpful!)

An important question remains:

Why is attractiveness to commercial publishers, or reducing benefits
to free riders, important for the Emacs manual?

If the Emacs manual were picked up by free riders, that would be fine
with us, wouldn't it?  

(Is it that the FSF sells manuals?  If so, how many copies do they
sell anyway, and how much would that number be likely to be affected?
Most people who contribute to the manual are not doing it to raise
money for the FSF.  They're doing it to contribute to Emacs.  When I
want to contribute to the FSF, I write a check.  When I want to
contribute to Emacs, I write code or docs.)

So what exactly is the GFDL protecting, in the specific case of the
Emacs manual?  Are we really worried about some portion of the manual
being used in a screed in support of software patents or something?

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

[Stefan Monnier]

>     I do not understand why the GFDL exists at all.  It seems to me that the
>     GPL is as adequate for manuals as it is for code.

> The GPL was designed for software, not for books.  The GPL's
> requirements would be quite inconvenient for anyone who wanted to
> publish a printed book from the material.

> I think the GFDL says more or less what it ought to say.

OK, for books it makes sense.  But it doesn't for material such as the elisp
manual (which is not published).


        Stefan

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

[David Kastrup]

Karl Fogel <kfogel@floss.red-bean.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I don't see any benefit from using the GFDL over the GPL that would justify
>> the downside of preventing the XEmacs people from using our documentation.
>> [ Unless we consider that as an upside, but I really don't see any good
>> reason why we should be so antagonizing. ] Similarly, the licensing problems
>> it can cause when extracting docs and doc-skeletons out of code
>> is worrisome.
>
> I agree.
>
> It is bad that our docs are license-incompatible with XEmacs's GPL'd
> docs.

It's bad for the XEmacs developers and other Emacs forks, irrelevant
for us, since only FSF copyright assigned contributions are accepted
into Emacs and its manual, anyway, and the copyright holder is free to
move stuff between licences within the scope of the assignment
contracts.

> It is also confusing how the GFDL interacts with extracted docs from
> non-GFDL code, as you point out.

Again, this is not a problem for Emacs development itself (the
copyright all being by the FSF), but for every fork of it.

Which makes it appear to me as jibing with the idea of a Public
Licence.  As explained elsewhere, I do think the GFDL a good idea, but
I don't like the implications of using it tightly coupled with GPLed
software development.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Matthew Mundell]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But I think that this "freedom" argument is flawed.  "Freedom" means
> something different to everyone, so it's not a very good way to convince
> other people.  Especially in the context of the Free Software movement,
> I understand "free" to apply to the program itself, not its user:
> the program (or the doc) itself is "free", can't be harnessed/hijacked by
> anyone.  It quite directly implies that people aren't "free" to use it as
> they please.

That sounds more like the program is being protected than freed.

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

[David Kastrup]

Matthew Mundell <matt@mundell.ukfsn.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> But I think that this "freedom" argument is flawed.  "Freedom"
>> means something different to everyone, so it's not a very good way
>> to convince other people.  Especially in the context of the Free
>> Software movement, I understand "free" to apply to the program
>> itself, not its user: the program (or the doc) itself is "free",
>> can't be harnessed/hijacked by anyone.  It quite directly implies
>> that people aren't "free" to use it as they please.
>
> That sounds more like the program is being protected than freed.

Certainly.  This protection is the whole point of copyleft licences as
compared to licences like the MIT X11 licence or placing something in
the public domain.

This is not an issue: the various GNU licences never were aiming for
the "most free in every sense of the word" award in the first place.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Brian Palmer]

On Sun, 12 Dec 2004 09:57:56 +0100, David Kastrup <dak@gnu.org> wrote:
> Karl Fogel <kfogel@floss.red-bean.com> writes:
> 
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >> I don't see any benefit from using the GFDL over the GPL that would justify
> >> the downside of preventing the XEmacs people from using our documentation.
> >> [ Unless we consider that as an upside, but I really don't see any good
> >> reason why we should be so antagonizing. ] Similarly, the licensing problems
> >> it can cause when extracting docs and doc-skeletons out of code
> >> is worrisome.
> >
> > I agree.
> >
> > It is bad that our docs are license-incompatible with XEmacs's GPL'd
> > docs.
> 
> It's bad for the XEmacs developers and other Emacs forks, irrelevant
> for us, since only FSF copyright assigned contributions are accepted
> into Emacs and its manual, anyway, and the copyright holder is free to

Not true, e.g., lao.el is Copyright (C) 1997 Electrotechnical 
Laboratory, JAPAN. I'm also going to say it's a bad thing for 
everybody, in second order effects if not primary. The more 
cooperation that exists between the many emacs forks out 
there, the more cooperation that can be built on. Emacs profits
from that cooperation, too. 

The question that comes , then, is this obstacle to cooperation 
so very valuable to emacs? What is the net benefit of having the
emacs manual only available under the GFDL? 

> move stuff between licences within the scope of the assignment
> contracts.
> 
> > It is also confusing how the GFDL interacts with extracted docs from
> > non-GFDL code, as you point out.
> 
> Again, this is not a problem for Emacs development itself (the
> copyright all being by the FSF), but for every fork of it.

And for every elisp application built on emacs. There are any number of 
elisp applications out there which will involve the authors looking 
through the emacs manual for reference. The GFDL status of the 
manual has clear implications on their ability to copy info out for 
docstrings or basing any functions on examples given in the 
manual.

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

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    Why is attractiveness to commercial publishers, or reducing
>    benefits to free riders, important for the Emacs manual?
>
> To enable the FSF to be a `do what we do organization' rather than a
> `don't do what we do, do what we say' organization.

[Lots of other explanation deleted]

This is all very fine and explains the reason for both the GFDL and
the GPL pretty much equally.  It does not explain, however:

a) what precise purpose does the GFDL achieve for the GNU Emacs manual
that is not achieved by it being under the GPL (your explanation is
mostly about the contrast to Public Domain and/or BSD)?

b) is the difference this makes worth the trouble it causes?

c) in particular: is it a good idea to split a free project into two
parts with incompatible licences in a manner that makes it only
possible for the copyright holder to sensibly maintain the exchange of
material across the rift?  Do we really want to demonstrate how to do
such a thing in large scale?

d) is it a good idea to change a large body of free software (like the
GNU Emacs manual) to a different licence when it is well-known that
substantial forks exist for which no licence change is possible, not
least of all because the fork does not have the permission of the FSF
to change the licence for old derived material to the GFDL, even in
the case (which is not the current case) that they'd wanted to do it?

In short, in this manner we are creating an insurmountable border for
anybody but the FSF to past versions of the manual, as well as to
current versions of the Emacs code.

I don't like it.  This has nothing to do with liking or not liking the
GFDL itself: as I already stated it would probably be my preferred
manner of publishing a book that was intended mainly for publishing in
the first place, and that was not as tightly coupled with software as
most Texinfo manuals are.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Florian Weimer]

* David Kastrup:

> d) is it a good idea to change a large body of free software (like the
> GNU Emacs manual) to a different licence when it is well-known that
> substantial forks exist for which no licence change is possible, not
> least of all because the fork does not have the permission of the FSF
> to change the licence for old derived material to the GFDL, even in
> the case (which is not the current case) that they'd wanted to do it?

d) doesn't apply to the situation which sparked this discussion
because the Emacs manual hasn't been released under the GPL.  If the
XEmacs manual is GPLed, it's not a fork of the Emacs manual, because
the Emacs manual licensing terms have been GPL-incompatible since at
least 1992, probably even longer.

The widely held belief that the GFDL relicensing of the Emacs manual
introduced the GPL incompatibility (and invariant sections) is wrong.

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

[David Kastrup]

Florian Weimer <fw@deneb.enyo.de> writes:

> * David Kastrup:
>
>> d) is it a good idea to change a large body of free software (like
>> the GNU Emacs manual) to a different licence when it is well-known
>> that substantial forks exist for which no licence change is
>> possible, not least of all because the fork does not have the
>> permission of the FSF to change the licence for old derived
>> material to the GFDL, even in the case (which is not the current
>> case) that they'd wanted to do it?
>
> d) doesn't apply to the situation which sparked this discussion
> because the Emacs manual hasn't been released under the GPL.  If the
> XEmacs manual is GPLed, it's not a fork of the Emacs manual, because
> the Emacs manual licensing terms have been GPL-incompatible since at
> least 1992, probably even longer.

So what is the actual situation with the licence of the XEmacs manual?
What kind of licensing are they _free_ to place on the XEmacs manual
without the possibility of XEmacs contributors vetoing that decision?
This would give us some sort of idea whether the requirements of the
XEmacs team can be accommodated in a manner that is not equivalent to
returning to the old licensing conditions completely.

> The widely held belief that the GFDL relicensing of the Emacs manual
> introduced the GPL incompatibility (and invariant sections) is
> wrong.

Well, ok, so we just substituted one idea I don't like with another
one.  So what terms in the old licence were GPL-incompatible?

And, putting back the XEmacs manual problem for a moment, do we have a
reasonable chance to place the GPL on the manual source code in a
sensible way, without causing insurmountable problems for printed
manuals?

I'd think that the problems with printed manuals from GPLed source
might be somewhat similar to the problems with embedded controllers
based upon GPLed source: in both cases the usual end product is used
without accessing the source.  There is a difference, though: in the
case of the manual, the usual customer will _benefit_ from a
machine-readable source code copy since he can then use text search
and indexing and similar.

Since this problem does not seem restricted to GNU Emacs and its
printed manual, is there a more appropriate list where we could try
discussing how to cope with the general problem that gets exhibited
here?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Robert J. Chassell]

   > To enable the FSF to be a `do what we do organization' rather than a
   > `don't do what we do, do what we say' organization.

   a) what precise purpose does the GFDL achieve for the GNU Emacs manual
   that is not achieved by it being under the GPL (your explanation is
   mostly about the contrast to Public Domain and/or BSD)?

To be a `do what we do, not a do what we say' organization.

   b) is the difference this makes worth the trouble it causes?

I think so.  Certainly, over the past few years lawyers have become
very important in the question of software and other freedoms.  As the
cost of manufacturing information, which is called `copying', comes
down, the information's legal status becomes more and more important.

A long time ago, I heard someone say that the issue was whether anyone
could create a program using an interpreted language like Emacs Lisp,
or whether the program would be too slow.  That is not the issue now.

Many programmers think of the trouble licenses cause to other
programmers.  That is to be expected, since programmers write code and
document it.

But the issue here is the interface between certain professionals in
one industry and everyone else.  Moreover, industry also develops
hardware that combined with software have enabled copying to become
less and less expensive.  This means that when you show how the
interface is supposed to work, you need to think about all the people
who are not programmers and who do not know anything about computers
or code.

Nanotechnological assemblers -- rapidly reproducing Von Neumann
machines that also copy other things -- would reduce the cost of
manufacturing copies to zero.  But we are never going to see a
reduction to zero in the cost of attention getting, that is to say, of
marketing and advertising.  That is because getting attention is a
zero-sum operation, like getting status.  It is not like science-based
manufacturing, which is positive sum.

This means that an appropriate license will continue to be relevant.

   c) in particular: is it a good idea to split a free project into two
   parts with incompatible licences in a manner that makes it only
   possible for the copyright holder to sensibly maintain the exchange of
   material across the rift?  Do we really want to demonstrate how to do
   such a thing in large scale?

If people on one of the two projects insist on using a license that
hurts people, especially the vast majority, who are non-programmers,
then their project should suffer.

So far, I have not seen any remarks that speak to the points.  Among
others, I would like to see an argument favoring a `Creative Commons'
license that forbids any but gratis distribution, except for its
controlling monopolist.  Why would that be better for you and me and
others?  I think it is worse.

I would like to see an argument that says that says that FSF need not
be consistent; that it should become a `do not do what I do, do what I
say' organization.  I think the FSF should be consistent.  Perhaps I
am wrong.

I would like to see, but do not expect to see, an argument that says
that many programmers who work on GNU projects are really good at
selling non-programing business patterns to people are not programmers
and who know nothing about computers and software.

   d) is it a good idea to change a large body of free software (like
   the GNU Emacs manual) to a different licence when it is well-known
   that substantial forks exist for which no licence change is
   possible, ...

Why is it not possible?  Are you suggesting that the XEmacs people
lack proper papers for contributions?  If so, this means they cannot
ever ensure that the lawyers of a hostile organization with plenty of
money will tell the organization's leaders that the software is legal.
That is what I think you are suggesting.

This means that the XEmacs project is rhetorically ineffective.  Since
I doubt that many people on it are concerned about business patterns,
politics and the like, I do not think this issue is salient to them.
I think they are mainly concerned with programming and wish the wider
world would go away.

In any event, the Lucid people were warned about this years ago and
continued on their way.  As for FSF:  why should a project favoring
software freedom, the GNU project, change its licenses to hurt its
goal?

I think that a good reason to go back on the license would be that FSF
need not be consistent.  But I do not believe that reason and have
never heard an argument that claims that.

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.

As for living in a bigger world: one could argue that laws and
licenses are irrelevant since most of the world is `extra-legal'.
Only regions like Western Europe and a few others are more or less
`law abiding'.  In much of the world, any organization with more than
a billion US dollars or so per year to spend can corrupt enough
officials for it to continue to do what it has done before.

But again, I do not think that the rule of rich, greedy individuals is
better than the rule of law.  I have heard claims that rich, greedy
individuals do make better rulers, and that their right to hinder me
is good for others than me; but I have never welcomed that.

Moreover, there are good arguments -- indeed I have made them -- that
failure is an intrinsic problem of hierarchies that exclude change.
(Failure may not occur in the short term, that is to say, in less than
a couple of human generations.)  Only when competitors are equally
weak can such hierarchies last for thousands of years.

So, to answer your questions again:

a) the precise purpose of the GNU Free Documentation License is to
   offer a better alternative to greedy publishers, a better way to
   protect their investment in attention getting.  The FSF puts its
   own documentation under the GFDL because its leaders believe that
   programmers, at least those involved in the GNU project, are poor
   at being `don't do what we do, do what we say' salesmen to people
   who are not programmers.

b) the difference between a license that insists that commercial
   organizations fail in their purpose and a license that enables
   their purpose is vast.  No one claims that companies that are
   unable recover costs will survive against companies that are able
   to revover costs.

c) a project that hinders another in fulfilling its goal cannot expect
   to be supported by the second, except as charity.

d) as an organization comes to realize that its primary business is
   politics in a deep sense -- that of changing business patterns --
   and that the people in the organization are poor at politics with
   strangers who know nothing of computers and that competitors are
   out to destroy it, it makes more sense to offer licenses such as
   the GFDL as an alternative to licenses such as the `Creative
   Commons license with a commercial restriction'.

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

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

[Florian Weimer]

* David Kastrup:

> Well, ok, so we just substituted one idea I don't like with another
> one.  So what terms in the old licence were GPL-incompatible?

For reference, the old license was:

@ifinfo
This file documents the GNU Emacs editor.

Copyright (C) 1985, 1986, 1988, 1992 Richard M. Stallman.

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

@ignore
Permission is granted to process this file through Tex and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).

@end ignore
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
sections entitled ``The GNU Manifesto'', ``Distribution'' and ``GNU
General Public License'' are included exactly as in the original, and
provided that the entire resulting derived work is distributed under the
terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that the sections entitled ``The GNU Manifesto'',
``Distribution'' and ``GNU General Public License'' may be included in a
translation approved by the author instead of in the original English.
@end ifinfo

Those invariant sections are GPL incompatible because they restrict
modification in a rather drastic way.

I don't really think that invariant sections are a good solution.  If
I don't want my users to read them, I can modify the Info viewer to
hide them (or replace them with texts of my own), without actually
changing the manual itself.

> And, putting back the XEmacs manual problem for a moment, do we have a
> reasonable chance to place the GPL on the manual source code in a
> sensible way, without causing insurmountable problems for printed
> manuals?

In theory, one could dual-license it.  However, this might undermine
some goals of the GNU FDL.

> Since this problem does not seem restricted to GNU Emacs and its
> printed manual, is there a more appropriate list where we could try
> discussing how to cope with the general problem that gets exhibited
> here?

There are already ongoing deliberations between the Debian Project and
the FSF which deal with a very similar topic: the fact that the GNU
FDL is definitely *not* a free software license (software in the sense
of machine-executable code).  However, these discussions seem to be
stuck for some reason.

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

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    > To enable the FSF to be a `do what we do organization' rather than a
>    > `don't do what we do, do what we say' organization.
>
>    a) what precise purpose does the GFDL achieve for the GNU Emacs manual
>    that is not achieved by it being under the GPL (your explanation is
>    mostly about the contrast to Public Domain and/or BSD)?
>
> To be a `do what we do, not a do what we say' organization.

How does this hand-waving address the difference between GPL and GFDL?

Anyway, if the GPL (probably when combined with special exceptions)
does not deal satisfactorily with the problems arising in production
of tangible goods such as boxes with embedded controllers and printed
manuals, then it would be best if GPL version 3 would be written in a
manner that would not necessitate placing Texinfo manuals and similar
material tightly coupled to GPLed code under any incompatible licence.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Robert J. Chassell]

   >    > To enable the FSF to be a `do what we do organization' rather than a
   >    > `don't do what we do, do what we say' organization.
   >
   >    a) what precise purpose does the GFDL achieve for the GNU Emacs manual
   >    that is not achieved by it being under the GPL (your explanation is
   >    mostly about the contrast to Public Domain and/or BSD)?
   >
   > To be a `do what we do, not a do what we say' organization.

   How does this hand-waving address the difference between GPL and GFDL?

The GFDL is designed to enable commercial publishers who print on
paper or other material entity to survive.  The GPL is not.  

The idea is that software development will be paid for by hardware
companies, by trade associations, by governments, by universities, and
by programmers whose material income does come from the project at
hand.  In other words, cost recovery for someone writing code is, or
should be, different than cost recovery for someone getting attention
for and printing a book written by another.

At the moment, proprietary software companies and many documentation
publishers depend on the same method of cost recovery, which is to say
monopoly pricing enforced (ultimately, not most of the time) by
police.  Proprietary restrictions hinder both software creation and
documentation writing.

That is why I have said so often that the purpose of the GFDL is to
provide an alternative to a `Creative Commons license with a
commercial restriction' or similar license.

As for a single license:  I personally would like to see one rather
than two or many, but I am not sure that is possible.  Laws are
written mostly by lawyers.  Businesses that use software are often run
by people who know nothing about software (and the business may have
nothing to do with software except to use it as a tool -- it may train
horses or something like that).  Perhaps one license is possible.
Then again, perhaps not.

Incidentally, a great advantages of both the GPL and the GFDL is that
they can be read, perhaps with difficulty, by non-lawyers, and mean
more or less the same thing to them as to lawyers.  (I am told that
the main legality a non-lawyer like me needs to learn is that
`derivative works' are defined by judges, most of whom know nothing
about software.  The meaning of `derivative work' cannot be specified
in a license.)  Readability means that programmers who do not wish to
learn much law can grok the major interfaces between them and the
wider world.

Imagine if a programmer could not understand these interfaces without
becoming a different person -- imagine if a programmer were in the
same position as a typical politician, the one being unable to
understand the interface, the other being unable to understand the
software.  It is hard enough right now to deal with these issues:
doubtless you have noticed that almost all discussion by programmers
is addressed to programmers' issues rather than to non-programmers'
issues.  Imagine it were worse.

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

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

[Andy Piper]

At 11:43 AM 12/12/2004, Robert J. Chassell wrote:
>Why is it not possible?  Are you suggesting that the XEmacs people
>lack proper papers for contributions?  If so, this means they cannot
>ever ensure that the lawyers of a hostile organization with plenty of
>money will tell the organization's leaders that the software is legal.
>That is what I think you are suggesting.

That's either amusing or insulting. XEmacs explicitly does not collect 
papers because we believe that hinders development of the product. The only 
reason we have tried to collect papers is promote greater cooperation with 
the GNU Emacs project.

>This means that the XEmacs project is rhetorically ineffective.  Since
>I doubt that many people on it are concerned about business patterns,
>politics and the like, I do not think this issue is salient to them.
>I think they are mainly concerned with programming and wish the wider
>world would go away.

Please do not make assumptions about we are or are not concerned with. If 
anything the XEmacs project is much more concerned with these things than 
the FSF appears to be.

I personally believe that the FSF's approach has contributed to making 
Emacs (and XEmacs) largely irrelevant today. So you can protect the code 
from big, bad companies - I highly doubt that anyone in the real world 
actually cares anymore.

andy 

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 12 Dec 2004 01:16:59 -0500
> Cc: ben@666.com, Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org,
> 	xemacs-beta@xemacs.org
> 
> OK, for books it makes sense.  But it doesn't for material such as the elisp
> manual (which is not published).

??? The FSF sells printed copies of the ELisp manual.  I actually saw
them.

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

[David Kastrup]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sun, 12 Dec 2004 01:16:59 -0500
>> Cc: ben@666.com, Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org,
>> 	xemacs-beta@xemacs.org
>> 
>> OK, for books it makes sense.  But it doesn't for material such as
>> the elisp manual (which is not published).
>
> ??? The FSF sells printed copies of the ELisp manual.  I actually saw
> them.

Well, but it would not seem that there is much interest from
independent publishers, and that was supposed to be the driving factor
for choosing the GFDL instead of the GPL, if I understood the argument
correctly.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Robert J. Chassell]

   At 11:43 AM 12/12/2004, Robert J. Chassell wrote:
   >Why is it not possible?  Are you suggesting that the XEmacs people
   >lack proper papers for contributions?  If so, this means they cannot
   >ever ensure that the lawyers of a hostile organization with plenty of
   >money will tell the organization's leaders that the software is legal.
   >That is what I think you are suggesting.

   That's either amusing or insulting. XEmacs explicitly does not collect
   papers because we believe that hinders development of the product. ...

To me you sound as if your primary concern is in the `development of
the product' rather than its use by strangers who care nothing about
software.

As a technique, you have made yourself hostage to anyone who is
hostile to you and has lots of money.  That is what is meant by `does
not collect papers'.

You can hope to be perceived as irrelevant, in which case no one will
attack you.  That is fine.  But that also means you are doing no good
for society as a whole.

   >This means that the XEmacs project is rhetorically ineffective.  ...

   Please do not make assumptions about we are or are not concerned
   with. If anything the XEmacs project is much more concerned with
   these things than the FSF appears to be.

Well, please undertake actions that show you being effective as
salesmen.  I am not persuaded of that.  The FSF strategy is not very
powerful, but I cannot think of anything more effective, considering
the nature of the people who are part of GNU.  Please show me how you
have been better at affecting poltical and business change in
Washington, Paris, and Berlin.

I dislike this whole need for `papers', police support of legal
monopolies, and developers' hinderances; I want to see this harm
ended.  I want to see more software freedom.

   ... So you can protect the code from big, bad companies - I highly
   doubt that anyone in the real world actually cares anymore.

They do care.  That is why some companies lobbied for laws like the
DMCA.  That is why SCO got funding which they have used, among other
actions, to make statements that confused decision-makers who know
nothing about software.  Only the irrelevant are untouched.

   I personally believe that the FSF's approach has contributed to
   making Emacs (and XEmacs) largely irrelevant today. ....

Perhaps GNU/Linux is irrelevant, but neither Microsoft nor IBM think
so.  I do not think so.  As for Emacs, it may be a failed project; or
it may be an integrated user environment that is less interesting than
a graphic user interface; or it may be doing as well as a programmers'
tool can be expected.  In any case, Emacs is not the GNU project.

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.

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

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

[Robert J. Chassell]

   > ??? The FSF sells printed copies of the ELisp manual.  I actually saw
   > them.

   Well, but it would not seem that there is much interest from
   independent publishers, and that was supposed to be the driving
   factor for choosing the GFDL instead of the GPL, if I understood
   the argument correctly.

Evidentally, I have not been clear.  Nothing in this thread that I
said should have suggested that interest from independent publishers
drives the use of the GFDL with regard to the elisp reference manual.

Instead, I have tried to say that the goal is to persuade others to
choose the GFDL over a `Creative Commons license with a commercial
restriction' or similar license.  The GFDL is better.

Being a `do as we do' organization is necessary on account of the
characters of the people in the organization.  They are lousy at doing
one thing and saying something at odds with that action.  The GFDL
ends up both moral and practical.  These are the driving factors.

(Incidentally, as far as I can see, the timescale for measuring
success or failure is another generation or so.  My hope is that by
that time, societies will have decided that it is a good idea to
permit strangers to modify changeable works like technical
documentation, to permit strangers to manufacture copies of them that
use resources, and at the same time to permit the initiating
organizations to recover costs they have expended.  My fear is that
the strategy will have failed and that societies will have decided to
restrict your freedom to protect yourself from those who would hinder
development to their benefit.)

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

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

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> 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.

Well, if we are talking about the licences of Emacs, then it is not an
invalid view to be concerned with Emacs I'd say.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Dhruva]

On Sun, 12 Dec 2004 23:28:48 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Sun, 12 Dec 2004 01:16:59 -0500
> > Cc: ben@666.com, Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org,
> >       xemacs-beta@xemacs.org
> >
> > OK, for books it makes sense.  But it doesn't for material such as the elisp
> > manual (which is not published).
> 
> ??? The FSF sells printed copies of the ELisp manual.  I actually saw
> them.

...and I have brought them (just to confirm), they come in 2 volumes.

-dhruva

-- 
Proud FSF member: #1935
http://schemer.fateback.com/

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

[Brian Palmer]

On Mon, 13 Dec 2004 02:22:14 +0000 (UTC), Robert J. Chassell
<bob@rattlesnake.com> wrote:
> Evidentally, I have not been clear.  Nothing in this thread that I
> said should have suggested that interest from independent publishers
> drives the use of the GFDL with regard to the elisp reference manual.
> 
> Instead, I have tried to say that the goal is to persuade others to
> choose the GFDL over a `Creative Commons license with a commercial
> restriction' or similar license.  The GFDL is better.

If using the GFDL on the emacs manual is as a persuasive example rather 
than to benefit the emacs project directly with the restrictions of the GFDL, 
why wouldn't licensing it both under the GPL and as GFDL serve the same 
purpose? That'd make it clear to organizations that the GFDL is not
the same as GPL,
plus allow emacs itself as a free project tightly coupled to the manual, to 
benefit. (To give credit, David Kastrup's point on the tight couplings between
a GPLed project and the GFDLed project is spot on, I think).

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

[David Kastrup]

Brian Palmer <bpalmer@gmail.com> writes:

> On Mon, 13 Dec 2004 02:22:14 +0000 (UTC), Robert J. Chassell
> <bob@rattlesnake.com> wrote:
>> Evidentally, I have not been clear.  Nothing in this thread that I
>> said should have suggested that interest from independent
>> publishers drives the use of the GFDL with regard to the elisp
>> reference manual.
>> 
>> Instead, I have tried to say that the goal is to persuade others to
>> choose the GFDL over a `Creative Commons license with a commercial
>> restriction' or similar license.  The GFDL is better.
>
> If using the GFDL on the emacs manual is as a persuasive example
> rather than to benefit the emacs project directly with the
> restrictions of the GFDL, why wouldn't licensing it both under the
> GPL and as GFDL serve the same purpose?

Because it still is impossible to move GPLed material into a manual
that is supposed to be dual-licenced under the GPL and the GFDL, for
anyone except the copyright holder on the GPLed software?

It would solve some problems with Debian et al, in that their
guidelines would then permit them to distribute Emacs including its
manuals under the GPL: so those usages where the manual is not
actually intended to go into print are covered.  It would also mean
that a publisher wanting to print the Emacs manual under the GFDL
might have to get it from the FSF even though he might have a Debian
CD flying around (if patches to the manual are done GPL-only).  And it
might cause derived versions of the Emacs manual around that are not
publishable under the GFDL.

Really, we need a version of the GPL that applies tolerably well to
manuals...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Thien-Thi Nguyen]

   From: "Robert J. Chassell" <bob@rattlesnake.com>
   Date: Mon, 13 Dec 2004 01:59:20 +0000 (UTC)

   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, one of the many involved in this thread.  to what
extent any society has desire for self- and not-self-change is a concept
too vague to be useful, primarily because what is externally visible may
not be what is internally held (and if you are external enough, even
understanding what is visible is very difficult).  by not recognizing
this, you also demonstrate the lack of salesmanship you have been
talking about, which is at least consistent.

thi

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

[Robert J. Chassell]

      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

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

[Bruce Stephens]

David Kastrup <dak@gnu.org> writes:

[...]

> Because it still is impossible to move GPLed material into a manual
> that is supposed to be dual-licenced under the GPL and the GFDL, for
> anyone except the copyright holder on the GPLed software?

As far as I can tell the XEmacs people aren't asking for GNU GPL; the
XEmacs manual is distributed under conditions which look incompatible
with the GNU GPL.

Indeed, I just compared the text in the current xemacs.texi with
what's in emacs.texi version 1.10 (August 2000, just before the change
described as "Update for GFDL.  Not yet checked by rms."), and they
look very nearly the same (the only difference is that in emacs.texi
translations of the GNU Manifesto and similar sections have to be
approved by "the Free Software Foundation", but xemacs.texi says "the
author").

So presumably in 2000 the FSF chose to change the license, and the
XEmacs people didn't follow, either because they didn't like the GFDL
or because they felt they couldn't (changing licences is obviously
easier if one entity owns the copyright).

It seems a shame.  Not as embarrassing as Debian moving all GFDL
documentation to non-free (which hasn't happened yet, but seems not
unlikely), but still disappointing, IMHO.

<http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/emacs/emacs/man/emacs.texi?rev=1.10&content-type=text/plain>
<http://cvs.xemacs.org/viewcvs.cgi/*checkout*/XEmacs/xemacs/man/xemacs/xemacs.texi?rev=1.16&content-type=text/plain>

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

[Richard Stallman]

    OK, for books it makes sense.  But it doesn't for material such as the elisp
    manual (which is not published).

We published it in the past, and I hope that we or others will publish
it in the future.

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

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     OK, for books it makes sense.  But it doesn't for material such
>     as the elisp manual (which is not published).
>
> We published it in the past, and I hope that we or others will publish
> it in the future.

Is there some drawback that we'd have to encounter if things like the
Elisp manual were dual-licenced GPL and GFDL?  While I don't think
that this would help the XEmacs people with their current predicament,
it would at least guarantee that stuff like that does not get excluded
from Debian distributions; and with the electronic forms of the
manuals, the GPL appears more appropriate to me.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Karl Fogel]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> Instead, I have tried to say that the goal is to persuade others to
> choose the GFDL over a `Creative Commons license with a commercial
> restriction' or similar license.  The GFDL is better.

There's been much contrasting of the GFDL w/ the GPL, or the GFDL with
a "Creative Commons license with commercial restriction".

I've never meant to suggest either of those, but rather licenses
similar to the Creative Commons Plain Attribution or ShareAlike.
(Note: I'm not advocating using an actual Creative Commons license,
I'm just trying to shake us out of this rut in which the only
alternatives to the GFDL are the GPL or some overly-restrictive
Creative Commons license).

This thread has been very active, so I apologize if my question below
doesn't take into account something someone said.  I tried to read all
the posts, but might have missed a few.  Anyway:

For Emacs, what advantages does the GFDL have over (say) Creative
Commons Plain Attribution or Creative Commons Attribution-ShareAlike?

Again, this is only about the application of the GFDL to Emacs, *not*
about the GFDL in general.

-Karl

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

[Per Abrahamsen]

David Kastrup <dak@gnu.org> writes:

> Is there some drawback that we'd have to encounter if things like the
> Elisp manual were dual-licenced GPL and GFDL?  

I believe in general documentation for free software should be (dual)
licensed with the same license as the software itself, it makes it
much easier to move stuff between them.  Like reusing good code
comments and doc string in the manual, reusing parts of the manual as
doc strings or comments, or even embedding sections from the manual in
the code (like using a manual section as the basis for one of the
"assistants" Lars talked about).

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

[David Kastrup]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Is there some drawback that we'd have to encounter if things like
>> the Elisp manual were dual-licenced GPL and GFDL?
>
> I believe in general documentation for free software should be
> (dual) licensed with the same license as the software itself, it
> makes it much easier to move stuff between them.

Actually, you can't move from GPLed code into dual-licenced stuff
without having to forego the second licence, unless you are the
copyright holder.

However, in the case of the Elisp manual, this would at least be an
improvement for non-copyright holders as opposed to not being allowed
to distribute the manual at all after moving GPLed code into it.

> Like reusing good code comments and doc string in the manual,

Which could be done only by the copyright holder unless one would give
up the non-GPLed licence option.

> reusing parts of the manual as doc strings or comments,

Yes, that part would be important.

> or even embedding sections from the manual in the code (like using a
> manual section as the basis for one of the "assistants" Lars talked
> about).

This too.  I mean, having the manual available as hyperlinked
infopages actually _makes_ it pretty much an integral part of Emacs.
And for this purpose, it really should have a GPL-compatible licence.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Stephen J. Turnbull]

>>>>> "Bruce" == Bruce Stephens <bruce+usenet@cenderis.demon.co.uk> writes:

    Bruce> As far as I can tell the XEmacs people aren't asking for
    Bruce> GNU GPL; the XEmacs manual is distributed under conditions
    Bruce> which look incompatible with the GNU GPL.

That is correct.  We are not asking for the GPL.  We are asking for
the GNU Emacs (v19, I think) documentation license, which was,
unfortunately for the current situation, anonymous and unversioned.

I think of this license as approximately a special case of the GFDL.
Because both require that any redistribution take place under terms
_identical_ to the original, they are, however, mutually incompatible.

Whatever the FSF might decide to do with its policy on documentation
licenses, it shouldn't revert to a license that can only be specified
by quoting the whole thing; it would be asking for this situation all
over again.  So no matter how you slice it, XEmacs would require an
specific sublicense from the FSF to incorporate portions of GNU Emacs
documents in the XEmacs documentation.

    Bruce> So presumably in 2000 the FSF chose to change the license,
    Bruce> and the XEmacs people didn't follow, either because they
    Bruce> didn't like the GFDL or because they felt they couldn't
    Bruce> (changing licences is obviously easier if one entity owns
    Bruce> the copyright).

As far as I know, it didn't occur to us to change the license.  There
was no discussion that I can recall until perhaps two years later,
which came to the obvious conclusion that changing the license was
impractical, and the discussion was immediately dropped.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

[Robert J. Chassell]

    ... with the electronic forms of the manuals, the GPL appears more
    appropriate to me.

What specifically of the current form of the GFDL, as it applies
electronically, do you not like?

For example, I do not like the language in the license that talks of
publishing printed copies.  This suggests that `publisher' means only
`printed copy publisher'.  I would prefer to see the term `publisher'
be more general.  However, I do not know whether the term is necessary
for legal purposes.  My sense is that commercial restrictions should
apply to those who publish using `non-recoverable or rivalrous
resources',like spending resources to get attention, using printed
paper, or stamped CDs.  But I am not sure my language is right,
either.  (Note that technological change may decrease the cost of
vehicles -- something may replace printed paper or CDs -- but nothing
can reduce the cost of attention getting.)

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

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

[Robert J. Chassell]

    There's been much contrasting of the GFDL w/ the GPL, or the GFDL with
    a "Creative Commons license with commercial restriction".

    I've never meant to suggest either of those, but rather licenses
    similar to the Creative Commons Plain Attribution or ShareAlike.

Yes, I understand.  Unfortunately, you are not the one choosing the
license to apply.  I have seen items that ought to be free put under a
"Creative Commons license with commercial restriction".  We do not
need to convince anyone who is already using a free license.  They are
not harming us or others.

    (Note: I'm not advocating using an actual Creative Commons license,

I agree.  Neither am I.  Indeed, I think it was wrong to give free and
non-free licenses the same initial name, that of `Creative Commons'.
The language is confusing.  Rhetoric becomes very important in
persuading people who mostly are not listening, who do not care much,
and who are not professionals in the subject matter, such as music
creation or software.

    For Emacs, what advantages does the GFDL have over (say) Creative
    Commons Plain Attribution or Creative Commons
    Attribution-ShareAlike?

The two reasons I said before:  first, that when FSF is dealing with
the actual licenses of others, those two do not count.  The license
that counts is restricted.  Please remember, neither you nor I are
defining this issue.  Second, as I said above, when dealing with
strangers, language counts.

    Again, this is only about the application of the GFDL to Emacs,
    *not* about the GFDL in general.

Right.  This is what I am talking about:  the application of the GFDL
to Emacs.  

Note that my elisions are telling:  I am not talking about the
application of the GFDL to Emacs in a small community of like-minded
programmers, as some thought the Emacs community was 20 years ago.
Nor I am talking about the application of the GFDL to Emacs in a
larger community that is harmless to Emacs.

Unhappily, I am talking about the application of the GFDL to Emacs in
the current world, its default circumstances.

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

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

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     ... with the electronic forms of the manuals, the GPL appears more
>     appropriate to me.
>
> What specifically of the current form of the GFDL, as it applies
> electronically, do you not like?

I might be unable to bring across my point.  My issue is not with the
GFDL per se.  My issue is that it is not GPL-compatible, yet we use it
for something that forms an integrated and tightly coupled part of
Emacs and evolves with it.

And that defeats the "Public" in GPL since it requires the copyright
holder for normal maintenance work of derived versions.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Robert J. Chassell]

   ... My issue is not with the GFDL per se.  My issue is that it is
   not GPL-compatible, yet we use it for something that forms an
   integrated and tightly coupled part of Emacs and evolves with it.

   And that defeats the "Public" in GPL since it requires the copyright
   holder for normal maintenance work of derived versions.

I do not understand you.  First, the GFDL is not for code.  Second,
anyone can change the body of a GFDL's work.  

This means that you can modify code under the GNU GPL and then
document your modification.  And you may distribute the result,
attempting to charge if you wish for both code and documentation.  Or,
of course, you may give away both.  You have the freedom.

The copyright holder is irrelevant.  The only parts you may not
legally change are parts that do not deal with the subject.

This kind of invariance makes sense.  The invariance means either that
an author wrote something about the document, like why he wrote the
first draft, or that an initial publisher used `non-recoverable or
rivalrous resources'.  The latter is the key new feature:  it is
designed to restrict other publishers free riding, but not to stop
them from manufacturing and distributing copies of the work.

Previously, invariant sections were an ad hoc part of documentation
licenses.  True, they usually were not aimed at encouraging a
publisher (using non-recoverable or rivalrous resources) a little bit,
but without legally excluding all other publishers as the "Creative
Commons license with commercial restriction" does.  That is the main
new feature; and it could have been implemented in previous
documentation licenses.

Generally, people and organizations charge if they lose resources for
each item distributed and do not treat the used resources as a `lost
leader'.  Thus, book publishers give away some books as lost leaders
in order to gather attention and charge for the rest.  But if they
give away resources and never recover them, they will go broke if a
book is successful.

For the past half millenium, in Europe and in derived countries like
the US, the method for recovering resources involved in books has been
to prevent others from legally charging for copies that they produce.
If necessary, police enforce this ban.  

The GFDL is different.  It does not create a ban, but puts up a
barrier (that is what the front and back cover text requirement is
about).  The goal is that the barrier be somewhat high, but not too
high.  In contrast, the "Creative Commons license with commercial
restriction" and similar licenses put up a ban.

Please explain further how GFDL actions defeat the "Public" in GPL,
especially since invariant sections have existed in the licenses for
past documentation.

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

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

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    ... My issue is not with the GFDL per se.  My issue is that it is
>    not GPL-compatible, yet we use it for something that forms an
>    integrated and tightly coupled part of Emacs and evolves with it.
>
>    And that defeats the "Public" in GPL since it requires the copyright
>    holder for normal maintenance work of derived versions.
>
> I do not understand you.  First, the GFDL is not for code.  Second,
> anyone can change the body of a GFDL's work.

DOC strings and manual entries are material that are frequently copied
between those differently licenced items.  Customization entries link
into the manual, and manual entries contain code snippets doing
customization.  Code examples in the manual make obvious candidates
for copying into GPLed code for Emacs.

And so on.

> This means that you can modify code under the GNU GPL and then
> document your modification.  And you may distribute the result,
> attempting to charge if you wish for both code and documentation.
> Or, of course, you may give away both.  You have the freedom.

I am talking about working with existent code and manual entries.  Of
course, what you write yourself, you are free to licence as needed for
the case in question.

> The GFDL is different.  It does not create a ban, but puts up a
> barrier (that is what the front and back cover text requirement is
> about).  The goal is that the barrier be somewhat high, but not too
> high.

The barrier prohibits moving GPLed material into the manual unless you
are the copyright holder, and moving material out of the manual into
GPLed code.

> Please explain further how GFDL actions defeat the "Public" in GPL,
> especially since invariant sections have existed in the licenses for
> past documentation.

We already have established that the previous licence for the Emacs
Lisp manual had the same basic problems.  I am not talking about
returning to the old licence now (even though this would save the
XEmacs developers headaches), but whether it is a good idea to licence
Emacs with the integral Texinfo manuals under two incompatible
licences.  This has been the case even before we switched to the GFDL
as far as I can see.  But that does not mean that it was a good idea
at this time, and in the mean time, the Emacs Lisp manual has become
quite closer integrated with Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Robert J. Chassell]

   DOC strings and manual entries are material that are frequently
   copied between those differently licenced items.

Now I see what you are saying.  The legal question is, 

    when you are basing additions to a Texinfo manual on a large
    number of doc strings from functions, are the changes you are
    likely to make big enough so that the manual does not become a
    derivative work?

(Presumably, fair use means the issue is not relevant to a small
number of doc strings.  And the issue not relevant to additions that
are quite different.)

I don't know the legal answer.  Presuming that neither RMS nor anyone
else has thought of this, it becomes necessary to ask some people who
understand the laws in all the major countries of concern.  That is a
major undertaking.

My hunch is that a legally valid expectation is that any one's write
up will be sufficiently different, simply because he or she is trying
to write a document, not a doc string.  Put another way, only poorly
written documentation would be illegal....

But maybe not.  As for

  ... code snippets ...  [which include doc strings]

at the end of the node,
    (emacs)GNU Free Documentation License
says

    If your document contains nontrivial examples of program code, we
    recommend releasing these examples in parallel under your choice
    of free software license, such as the GNU General Public License,
    to permit their use in free software.

which handles this issue unless you are moving others' code into a
Texinfo manual without rewriting it more appropriately for a manual.
If my hunch is right, that would be no problem since it would be
reasonable to expect you to rewrite it suitably.  Otherwise, as far as
I can see, you have a reasonable point.

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

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

[Per Abrahamsen]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> I do not understand you.  First, the GFDL is not for code.  Second,
> anyone can change the body of a GFDL's work.  

With concepts such as "self-documenting editors", "litterate
programming" and "embedded documentation", the line between
documentation and code becomes blurry.  At least one of those concepts
should apply to Emacs :)

Which to me indicate that code and documentation for free software
ought to be covered by the same license.

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

[Stephen J. Turnbull]

>>>>> "Robert" == Robert J Chassell <bob@rattlesnake.com> writes:

    Robert>       To focus on Emacs when we are talking about licenses
    Robert> suggests to me that you are more concerned with the
    Robert> development of that product than with changing the
    Robert> political and business patterns of societies.

Not exactly.  Emacs is only part of my life, free software advocacy is
only part of my life.  In fact, living in a rather unfree (though very
comfortable) society, software freedom is only a small part of the
libertarian advocacy I should engage in.

I prefer the simplicity of advocating the _quality_ of free software
by producing it and giving it away, and of advocating the _extension_
of software freedom by _talking_ about it and engaging in other
political behavior, separately from development.  To me, the Emacs or
XEmacs license is an instrument to enable sharing, no more, no less.
It's not part of advocacy for me; I'm equally happy with whatever free
upstream license, permissive or copyleft.  It distresses me that
licensing issues (and related legal flummery), however necessary, get
in the way of sharing.

You can mix advocacy with development if you like; I'm happy that you
are free to do so.  Nor do I speak for Andy, or need to.  I don't know
what he thinks he's doing, and it doesn't matter to me as long as we
can share the code.  Different people doing things different ways:
that's freedom.  That's good.

    Robert> An organization has at least three options, none vague:

I am sorry, but although some of what you write about the business and
socioeconomic environment in this passage is accurate, much is quite
inadequate.  Especially beware of false trichotomies, the CC-with-
commercial-restriction does not fit any of the options as written.

    Robert> The goal of the GNU project is to change the wider
    Robert> society's default ground rules and default assumptions.

Which is why using the label "free" for a license that permits self-
serving restrictions was a strategic mistake IMHO.  I really don't see
a correspondingly large gain to offset the very real reputational
damage, eg among Debian community members.

It doesn't make any difference for XEmacs; the existing doc license
will forever be incompatible with any strong copyleft but itself.  But
personally I wish the FSF would amend the GFDL to remove the additional
encumbering restrictions, or simply rename it the GNU Documentation
License:

    "The GDL is a not-too-unfree documentation license that reserves
    certain non-economic rights to authors, while perpetually
    protecting the freedoms it does provide for users.  We use it
    ourselves to ensure that our advocacy of freedom always
    accompanies our documentation, while users will always be able to
    adapt the documentation to the needs of their derivatives of our
    free software."

Still unfree, but very hard to get upset about when you put it that
way.  :-)

   "Do I contradict myself?  Very well then; I contradict myself.
  I am large, I contain multitudes." -- W. Whitman, Song of Myself


-- 

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

[Robert J. Chassell]

   ... Emacs is only part of my life, free software advocacy is
   only part of my life.  

But your choice of licenses does not take up much time -- less time
than Emacs.  You need choose once and then the licenses do the work.

If you go by the default of copyright, you promote monopoly
restriction; if you go by the GPL, you promote freedom ...  but you
need not spend your time being an advocate who acts.

   I prefer the simplicity of advocating ...

These sound like actions you do.

   To me, the Emacs or XEmacs license is an instrument to enable
   sharing, no more, no less.

Right.  So you if you favor that kind of freedom, you will choose a
license that enables it.  You will not need to act beyond making the
choice (and filling out legal paper work, getting your employer or
university to permit you to do so, as needed).  It does not take much
time.

   ... It distresses me that licensing issues (and related legal
   flummery), however necessary, get in the way of sharing.

Well, we do not live in a world filled with people who always want to
share.  It would be much nicer if we did.  Please complain to those
who have caused these bad laws and please, if you feel like advocacy,
try to change them.  In any case, please do not help the bad guys
passively, when you can help the good guys passively (except for a
fairly short time when you choose licenses and/or handle legal paper
work that is imposed on you by the bad guys).

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

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

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> In any case, please do not help the bad guys passively, when you can
> help the good guys passively (except for a fairly short time when
> you choose licenses and/or handle legal paper work that is imposed
> on you by the bad guys).

Well, but that's no reason to cheer the good guys when they are
shooting themselves and their friends in the foot.

Anyway, could we keep off the picturesque rhetoric?  If there is
nothing new to say about the topic, nothing is gained by repeating the
already said things in an obfuscated way.

I guess we more or less got our differing points of view presented.

We have two different problems:

A) Emacs changed its manual licence from the old licence to the GFDL,
   and XEmacs can't or does not want to easily follow suit without
   contacting _their_ contributors.

B) Both the old as well as the new Emacs manual licence are
   GPL-incompatible and thus present problems for integrating work on
   the manual and the code for derived works that are not copyrighted
   all by the same legal entity.

It would appear to me that "A" is not something that we can reasonably
deal with in isolation: if we accompany every change of the licence of
the Emacs manual with an exception for old times' sakes, there is no
point in changing the licence in the first place.

However, A is in some manner an outgrowth of problem B, and if we got
B solved in a satisfactory way, it might mean that XEmacs developers
(like everybody else) would need to adapt at most _one_ more time.

One proposal of mine was dual GFDL/GPL licencing which still has the
disadvantage that third party code can be pulled into the manual by
others only while sacrificing the GFDL licence, so we probably will
still have the FSF as the primary responsible (non-public) source for
GFDL manuals.  It has the advantage that it can be accomplished rather
fast, and the disadvantage that it does not seem to solve any of the
more _urgent_ problems right now (certainly not the problem of the
XEmacs developers, except that they might be less uncomfortable with
the necessary relicensing then).

On the long run, I'd hope that the next version of the GPL would
become suitable to cover the generated of printed manuals in a
satisfactory way without the need for a separate licence.  However,
this will take quite long, and it does not appear to me that Richard
thinks it feasible at all.

Other choices are to let things stay as they are right now.

All of those choices don't look very appealing.  And there is little
sense in dressing them up with rhetoric about how free software and
its licences are either great or completely irrelevant.  Whether they
are great or irrelevant, we still have to pick them, and the cases
have more or less been made.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Richard Stallman]

      But
    personally I wish the FSF would amend the GFDL to remove the additional
    encumbering restrictions, or simply rename it the GNU Documentation
    License:

	"The GDL is a not-too-unfree documentation license that reserves
	certain non-economic rights to authors, while perpetually

In our judgment, it is free.  If you disagree, you're entitled
to your opinion.

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

[Robert J. Chassell]

   Anyway, could we keep off the picturesque rhetoric?  

It is not merely picturesque rhetoric, it is true:  you do not have to
spend all your time supporting freedom to be a fellow who helps others.
In the case of software, you can do this by choosing a license.  

Stephen J. Turnbull said

    ... free software advocacy is only part of my life ...

and suggested, although he did not say so, that choosing a good
license, and dealing with legal paperwork, takes a great deal of time.
But that is not true.  He framed the issue erroneously.

   We have two different problems:

   A) Emacs changed its manual licence from the old licence to the GFDL,
      and XEmacs can't or does not want to easily follow suit without
      contacting _their_ contributors.

Right.  Andy Piper said that

    XEmacs explicitly does not collect papers because we believe that
    hinders development of the product.

which means that XEmacs depends on `security by obscurity'.  This
means that if XEmacs becomes widely used, this policy may cause
unanticipated trouble.

   B) Both the old as well as the new Emacs manual licence are
      GPL-incompatible and thus present problems for integrating work
      on the manual and the code for derived works that are not
      copyrighted all by the same legal entity.

That might be true.  On the other hand, it might not -- waking up in
the middle of the night, I realized that the legal right to modify
that is inherent in both the GNU GPL and the GFDL may make it legal to
integrate work between the two.  I am not a lawyer and I don't know.

In my remarks I have been focusing on the invariant issues, the
`freedoms from', rather than on the `freedoms to'.  But the `freedoms
to' are also important.  I cannot tell you one way or the other.  

(As far as I am concerned, this is a bug, and I am glad you showed it
to me.  Like the GNU GPL, the GFDL should be understandable by lay
people with only a little legal knowledge and not much patience.  It
is not.)

   It would appear to me that "A" is not something that we can reasonably
   deal with in isolation: if we accompany every change of the licence of
   the Emacs manual with an exception for old times' sakes, there is no
   point in changing the licence in the first place.

True.

   However, A is in some manner an outgrowth of problem B, and if we got
   B solved in a satisfactory way, it might mean that XEmacs developers
   (like everybody else) would need to adapt at most _one_ more time.

Maybe.  But more likely more than one more time.  That is because of
the people who think that software and its documentation should be
restricted.  They will not `leave well enough alone'.  They will do
something that forces us to react.  

If, for example, the GPL depends on copyright, then anti-GPL people
will say, get rid of copyright for software!  (There is an effort to
do just this in the US.)  Companies such as Microsoft own thousands of
patents.  Patents enable worse restrictions than copyright.  (There is
an effort to introduce software patents into Europe, even though the
European parliament has voted against them.)

Moreover, some of people who are against software freedom can can
readily afford to fund think tanks, books, legal cases, patents,
lobbying, and FUD.  An anti-free software person who has the money
need not spend his time on the issue.  This means the conflict will be
ongoing.

And then there are mistakes on our side.  As you say, there is 

    ... no reason to cheer the good guys when they are shooting
    themselves and their friends in the foot.

The GNU GPL took a long time to become accepted.  The language for it
sometimes failed.  It is like RMS still calling Emacs an editor, when
it is an integrated computational environment that offers editing
facilities, just as BASH offers editing facilities in VIM or KDE
offers them in Koffice.  

There are failures on several sides.  People like me not explaining
well enough.  RMS not explaining well enough.

Another group are people like Andy Piper, who said

    I highly doubt that anyone in the real world actually cares
    anymore.

which suggests that all this licensing activity is a waste of time.  I
do not know how to talk to people like Andy.  

The question is how you view the world:  do you figure that the
non-programmers you must deal with are entirely, rather than mostly,
helpful and friendly?  Or do you figure that a few are not so good?
I am talking to people who think the latter, but not the former.

Or do you avoid thinking about non-programmers with reference to
programming?  I don't know how to talk with such people since I look
on licenses as an interface to non-programmers.

   On the long run, I'd hope that the next version of the GPL would
   become suitable to cover the generated of printed manuals in a
   satisfactory way without the need for a separate licence.

I would like that.  But I am not sure it is legally possible or
rhetorically useful.  After all, the purpose of the GFDL is to ensure
more freedom over all, and `freedom from' monopolies by permitting
certain publishers a limited `freedom to'.  That kind of attempted
balancing does not occur in the GNU GPL.

Put another way, you seldom buy a book for its paper, you buy it for
what specifically is printed in it.  Books are sold for their content
(not, as the jokes have it, for their covers; people are influenced by
covers because they expect them to indicate content).  On the other
hand, a computer is sold for its hardware, not for its software.
There is reason to separate the GFDL from the GPL.

(As for embedded systems:  it may be hard to change the software in an
embedded computer system like one in a car, but it is easy to change
the software in its parent computer.  Embedded computer systems are
not like books; they are not sold for their contained software.  On
the other hand, their software is more permanent than in desktop
computers.  So embedded systems form yet another category although
linked to its parents.)

   All of those choices don't look very appealing.  

I agree.  It is not an appealing world.  And it is getting worse.

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

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

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       But
>     personally I wish the FSF would amend the GFDL to remove the additional
>     encumbering restrictions, or simply rename it the GNU Documentation
>     License:
>
> 	"The GDL is a not-too-unfree documentation license that reserves
> 	certain non-economic rights to authors, while perpetually
>
> In our judgment, it is free.  If you disagree, you're entitled
> to your opinion.

If you want to produce a help sheet from the contents of the manual,
having to include the complete invariant sections might prove
prohibitive even where the scope and content of additional invariant
sections has not been chosen explicitly for encumbering further
distribution by a party in the middle.

But of course, this has been trodded out with the Debian people
already, and IIRC the GFDL does not meet their Debian Free Software
Guideline, which was quite closely modeled after the FSF's idea of
Software Freedom as expressed in various publications.

But it leads nowhere to discuss the _name_ of the licence.  The only
thing that is interesting is how it is applied, and to what.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Thu, 16 Dec 2004 11:58:12 +0100
> Cc: bob@rattlesnake.com, "Stephen J. Turnbull" <stephen@xemacs.org>,
> 	xemacs-beta@xemacs.org, andy@xemacs.org, emacs-devel@gnu.org
> 
> If you want to produce a help sheet from the contents of the manual,
> having to include the complete invariant sections might prove
> prohibitive

I don't think this is a problem, since in that case, only small
portions of the manual are copied.  And Richard said at the beginning
of this thread:

    I won't relicense such a large amount of material all together.

    If you show me specific parts you would like to use, I will consider
    relicensing them.

So I think the problem exists only if very large parts of the manual
are copied together.  Richard actually said that in the past, at least
in the context of copying material between doc strings and the manual
(which theoretically raises similar issues, since the code is under
the GPL).

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

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>       But
>>     personally I wish the FSF would amend the GFDL to remove the additional
>>     encumbering restrictions, or simply rename it the GNU Documentation
>>     License:
>>
>> 	"The GDL is a not-too-unfree documentation license that reserves
>> 	certain non-economic rights to authors, while perpetually
>>
>> In our judgment, it is free.  If you disagree, you're entitled
>> to your opinion.
>
> If you want to produce a help sheet from the contents of the manual,
> having to include the complete invariant sections might prove
> prohibitive even where the scope and content of additional invariant
> sections has not been chosen explicitly for encumbering further
> distribution by a party in the middle.

I haven't studied the GFDL, but IIUC, the issue raised here with the
GFDL is this:

It is not legal (execpt for the copyright owner) to take sections from
a GFDL'ed text and incorporating that text into a GPL program or other
GPL or GFDL (or similarly) licensed documentation without breaking the
GFDL of the original text.

Compare this to taking a section of one GPL program and including it
in another GPL program -- that's fully legal (IIUC).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

The people who consider these issues for Debian have arrived at an
extremely strict and mechanical way of interpreting their criteria,
which I think is very mistaken.

The FSF made this decision years ago, and it is not an open question
now.  Could you please move the discussion to gnu-misc-discuss@gnu.org?

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

[Stephen J. Turnbull]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

    sjt>       But personally I wish the FSF would amend the GFDL to
    sjt> remove the additional encumbering restrictions, or simply
    sjt> rename it the GNU Documentation License:

    sjt> 	"The GDL is a not-too-unfree documentation license
    sjt> that reserves certain non-economic rights to authors, while
    sjt> perpetually

    rms> In our judgment, it is free.  If you disagree, you're
    rms> entitled to your opinion.

That is exactly the point.  I _am_ entitled to my opinion, as are the
Debian Project, and the various BSD projects, and the OSI, as well as
the general public.  To the extent that the disagreement is widespread
and deeply rooted, the FSF has a public relations problem.

Now, I'm only one person, and my particular position is probably
unusual, and definitely extreme.  So maybe the public relations
problem pointed out here is "small" compared to the benefits of
insisting that the GFDL is "free".  That's for you to judge; I simply
wish to point out that the issue is not which definition of freedom is
correct, but that treating the existence of differences as negligible
harms us all.

Extremism-in-the-defense-of-freedom-is-no-vice-ly y'rs,

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

[Stephen J. Turnbull]

>>>>> "Robert" == Robert J Chassell <bob@rattlesnake.com> writes:

    Robert> It is not merely picturesque rhetoric, it is true: you do
    Robert> not have to spend all your time supporting freedom to be a
    Robert> fellow who helps others.  In the case of software, you can
    Robert> do this by choosing a license.

Excuse me?  Richard just denied exactly that possibility to us, in
<E1CctyU-0007l0-D7@fencepost.gnu.org>.  In general, authors of
derivatives of works licensed under strong copyleft have _no_ choice.

I can choose not to distribute my work on XEmacs, but _the FSF_ chose
XEmacs's licenses many years ago, leaving _me_ with _no_ choice[1] of
license.  That's what strong copyleft is all about, removing certain
freedoms in order to protect certain other freedoms, deemed to be of
overriding importance.  IIRC, the FSF openly acknowledges this on the
GNU web site among other places.  It's a reasonable compromise, but it
is compromise.

XEmacs's documentation problem is simply "collateral damage" in the
FSF's war against proprietary abuses.  Richard says "too bad."  It's a
clear inconvenience for us, and he could have been more gracious, but
he's exactly right.  It is both undesirable and unavoidable.

    Robert> and suggested, although he did not say so, that choosing a
    Robert> good license, and dealing with legal paperwork, takes a
    Robert> great deal of time.

You are correct that I did not say so.  However, I did not suggest
that choosing a license takes time.  I suggested that dealing with a
license chosen by someone else does.  That's what this thread is
about, at least for everyone who has posted except you.

    Robert> But that is not true.  He framed the issue erroneously.

Wrong.  You are trying to switch discussion from the difficulties of
dealing with someone else's license to the simplicity of choosing your
own.  That doesn't make my framing of _my_ issue erroneous.

[...]
    Robert> which means that XEmacs depends on `security by
    Robert> obscurity'.  This means that if XEmacs becomes widely

No "if", at least not if GNU Emacs is the standard of "widely used."
;-)

    Robert> used, this policy may cause unanticipated trouble.

Wrong again.  I am satisfied with the XEmacs strategy as I understand
it because I believe that there is no security, period.  The SCO case
proves that.  SCO did not attack "code of dubious provenance"; they
went after IBM's well-documented contribution.  If the meanest patent
shark in the ocean, IBM, doesn't know what "good papers" look like,
who does?  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.

"The Internet interprets censorship as damage, and routes around it."
Similarly, our (implicit) strategy is to interpret copyright claims as
damage, and to code around it.  (We already have to do that, with the
Emacs documentation.  With friends like these ... well, I'll take such
friends any day---and ask them to stop plinking BBs at my foot.)

Risky strategy?  Of course.  The FSF's strategy is less risky, but not
a sure thing.  (For example, it is always vulnerable to attack via a
completely independent patent on any technology it implements.)  In
return for risk reduction in the long run, it does, however, involve
known and certain damage to the interests of some free software users
and developers in the short run.  A reasonable compromise---as is
ours.  Any ecologist will tell you that monoculture itself is risky.
Vive la difference!  Let Freedom ring![2]

In the next paragraphs,

    A = practical difficulty of changing license of community-owned
        software
    B = incompatibility of GPL and GFDL

    dak>    However, A is in some manner an outgrowth of problem B,
    dak> and if we got B solved in a satisfactory way, it might mean
    dak> that XEmacs developers (like everybody else) would need to
    dak> adapt at most _one_ more time.

    Robert> Maybe.  But more likely more than one more time.

Doesn't worry me.  The big Problem A XEmacs faces with the FSF's old
Emacs documentation license (aka the current XEmacs documentation
license) is that it is unnamed and unversioned.  Satisfactory
resolution of B will involve a named versioned license so that a
permission statement of the form "may be redistributed under the GNU
Perfected License, version 1.0 or later, at your option" can be used.

    Robert> There is reason to separate the GFDL from the GPL.

IMO, this is very short-sighted.  Several hackers have pointed out the
convergence between code and documentation as exemplified by uh, well,
GNU Emacs itself.  Don't forget "literate programming".  The library
association's brief in the Eldridge case points out the importance of
cut and paste in compilations of existing documents.  I have musician
and film acquaintances who wish to have the same freedom to borrow the
recordings of others that I have to borrow the code of GNU Emacs.  I'm
sure there are classes of information that you and I would intuitively
agree are "not software" that I have not yet considered.

I don't see why they shouldn't all benefit from the same definition of
freedom as software.

There simply is no reason not to use the GPL, perhaps in a slightly
modified version to avoid referring to documentation as "the Program",
etc, except for reasons of encouraging commerce.[3][4]  Those reasons
apply with equal force to software, yet in the case of software are
rejected most vehemently by exactly the folks who insist that the GFDL
is a free license.  A rather unappealing combination.

    dak>    All of those choices don't look very appealing.

    Robert> I agree.  It is not an appealing world.  And it is getting
    Robert> worse.

It's always darkest before the dawn.  When Milton Friedman and Kenneth
Arrow can sign the same amicus brief for Eldridge, there is hope.


Footnotes: 
[1]  Yes, I have the option of delegating that choice to the FSF, and
in fact I have done so.  This eliminates the problem of
incompatibility between GNU Emacs and XEmacs licenses for my own
contributions, but still leaves me with _no choice of license_.

[2]  Sorry, David, but I do so love my own picturesque rhetoric.

[3]  Albeit on better terms than the "sorry for the legalese, but the
net effect is that copying without explicit permission is forbidden"
that graces O'Reilly's _X Window System_ series.

[4]  Of course there are clauses of the GFDL that deal with issues
like "technical means to prevent copying".  But it has long been
recognized that the GPL needs to be amended to deal with those issues,
and the GFDL's terms are arguably problematic.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

[Ben Wing]

> The people who consider these issues for Debian have arrived 
> at an extremely strict and mechanical way of interpreting 
> their criteria, which I think is very mistaken.
> 
> The FSF made this decision years ago, and it is not an open 
> question now.  Could you please move the discussion to 
> gnu-misc-discuss@gnu.org?

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

[a] XEmacs forked and kept the identical license
[b] 3 or 4 years ago -- i.e. 9-10 years after the XEmacs fork -- you changed
the license in a way that it cross-incompatible.
[c] I made a simple request -- will you cross-license the manual for us?
[d] you said no.

This is totally relevant to GNU Emacs.

Richard, please reconsider.  You have a reputation of antipathy towards
XEmacs.  If you're at all interested in mending fences a little, this would
be a very easy step -- simply declare that we are allowed to use the code
under our license (which was your license up through 2000 or so).  Otherwise
you give the impression of actively hindering the XEmacs project.

ben

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

[Miles Bader]

> Otherwise
you give the impression of actively hindering the XEmacs project.

Please, keep the tinfoil hats in the closet.

This state of affairs is no doubt annoying to xemacs, but there'sno
reason to believe that this was intentional.  Richard is pretty
consistent on this -- e.g., Debian, which is as good a friend as the
FSF has, is also annoyed by this issue.

Xemacs is certainly not without options, even if they want to use the
FSF text and Richard doesn't budge; for instance:

  (1) Xemacs could use this opportunity to try to get its records in order
      and try to identify what parts of its manual are problematic etc.

  (2) Richard mentioned that the what he object to is blanket changes.
      Perhaps there could be a mechanism by which xemacs requests license
      flexibility for each bit of the manual text it wants to use; if the FSF
      gave timely responses to such request, it might be only a minor
      inconvenience.  [I have no idea what exactly is acceptable to the FSF
      but ...]

-Miles

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

[Ben Wing]

>   (1) Xemacs could use this opportunity to try to get its 
> records in order
>       and try to identify what parts of its manual are 
> problematic etc.

I thought it has abundantly been explained why this is not possible even if
we wanted to do so -- we don't consider our records out of order.

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

[Ben Wing]

>   (2) Richard mentioned that the what he object to is blanket changes.
>       Perhaps there could be a mechanism by which xemacs 
> requests license
>       flexibility for each bit of the manual text it wants to 
> use; if the FSF
>       gave timely responses to such request, it might be only a minor
>       inconvenience.  [I have no idea what exactly is 
> acceptable to the FSF
>       but ...]

Richard, under what circumstances would you accept or refuse such a request?

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 <andy@xemacs.org> 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" <stephen@xemacs.org> 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
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

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

[David Kastrup]

"Ben Wing" <ben@666.com> writes:

>> The people who consider these issues for Debian have arrived 
>> at an extremely strict and mechanical way of interpreting 
>> their criteria, which I think is very mistaken.
>> 
>> The FSF made this decision years ago, and it is not an open 
>> question now.  Could you please move the discussion to 
>> gnu-misc-discuss@gnu.org?
>
> This is COMPLETELY relevant to this list, because the bottom issue is
>
> [a] XEmacs forked and kept the identical license
> [b] 3 or 4 years ago -- i.e. 9-10 years after the XEmacs fork -- you changed
> the license in a way that it cross-incompatible.
> [c] I made a simple request -- will you cross-license the manual for us?
> [d] you said no.
>
> This is totally relevant to GNU Emacs.

Uh, no.  It is relevant to XEmacs.  Since you more or less stated that
XEmacs developers are not to be bothered with issues like licences, it
is somewhat unclear what factual problem you would have with changing
the XEmacs manual licence to the GFDL.  That you don't feel like it is
not really sufficient.

To the extent that your problems are related to actual practical
considerations instead of "we liked the older licence better and did
not bother asking contributors whether they'd go with changes, since
they better be fine anyhow", they might also be relevant to Emacs.

It is my personal opinion that by far the most prominent distribution
channel for the Emacs manual is as part of Emacs, and so it should
also be available under the GPL (which would probably not help your
case, incidentally).  I'd be somewhat less inclined to state the same
thing for the Elisp tutorial: that is more like being a separate piece
of software, not as tightly integrated as either the Elisp manual and
the Emacs manual are with Emacs.

> Richard, please reconsider.  You have a reputation of antipathy
> towards XEmacs.  If you're at all interested in mending fences a
> little, this would be a very easy step -- simply declare that we are
> allowed to use the code under our license (which was your license up
> through 2000 or so).  Otherwise you give the impression of actively
> hindering the XEmacs project.

The question to solve for the licences of Emacs are what benefits
Emacs first, and free software in general second.

Licences like the GPL and the GFDL retain their force by having
relevant software with suitable copyright owners willing to defend
them.

The FSF maintains a large and significant body of free software as the
sole copyright holder, and it is paying a high price for it: the price
is that the FSF itself is unable to reap the benefits of the GPL.  It
can't reincorporate third party contributions without explicit
assignment.

The GPL implies the freedom to fork.  XEmacs developers have decided
to make use of that freedom, and have by the same token decided that
they would make use of that freedom also by relaxing their
contribution criteria and maintaining diversified copyrights, partly
not even tracking them.  Which you were free to do.  A different
significant fork from FSF-maintained software was egcs.  The egcs
project, in contrast, decided that they would not simplify matters in
a similar way: copyright assignments to the FSF were diligently
maintained.  As a result, this fork was able to get merged with the
FSF's own variant of GCC again.  Of course, egcs developers already
had seen the consequences of the Emacs/XEmacs fork, so it was easier
for them to decide differently.

Now with regard to the discussion on this list, it has not made
apparent by you

a) why the GFDL is a bad choice for Emacs manuals (I myself have
offered some opinions about that, but those mostly hold equally for
the previous licence).

b) why it would be technically impossible for you to change the XEmacs
manual licence to the GFDL: it does not seem like you have handed out
any written assurances that the licence is never going to change.

My personal guess would be "we don't like the licence".  Neither do I
for this purpose and have explained why.  But my dislike would be for
the old version of the licence, too.

It is pointless to say "well, everybody else but us should be affected
by the GFDL, so please give us an exception".  If there are arguments
good enough for you, they should also be good enough for everybody
else.  So please explain in detail what concrete problems you would
have with a licence change that other users and developers of free
software could reasonably also be expected to have.

As long as this is not particularly connected with Emacs itself, but
rather a general dislike of the GFDL, I have to agree with Richard
that this group does not seem the right place for it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Paul Pogonyshev]

David Kastrup wrote:
> b) why it would be technically impossible for you to change the XEmacs
> manual licence to the GFDL: it does not seem like you have handed out
> any written assurances that the licence is never going to change.

I think because contributing a piece of work implicitly means that you
agree to distribute it under the _current_ license.  So, to relicense
a piece of contributed work, you need an agreement from the author,
either got in advance (like FSF copyright assignment includes) or got
right before the license change.  Since XEmacs has many contributors
who hold their copyright, this means that license switch would require
collecting agreements from all of them, which might be practically
impossible.

That said, I agree with you that this is mostly an XEmacs problem,
largely caused by their policy of not collecting copyright assignments.
The situation is not nice, but I don't see why FSF should go against
its decision and its policies.  As Robert Chassell said (or meant),
FSF cannot ask other to use GFDL if it doesn't use it itself.  After
all, XEmacs isn't fully cooperative either, since FSF won't merge in
non-assigned code.  Yes, this is not a legal problem, but a matter of
FSF policy, but still...

Paul Pogonyshev

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

[David Kastrup]

Paul Pogonyshev <pogonyshev@gmx.net> writes:

> David Kastrup wrote:
>> b) why it would be technically impossible for you to change the XEmacs
>> manual licence to the GFDL: it does not seem like you have handed out
>> any written assurances that the licence is never going to change.
>
> I think because contributing a piece of work implicitly means that you
> agree to distribute it under the _current_ license.

Whose theory is that?  I don't see any of it in copyright law, and I
don't see any of it in the GPL.  This sounds suspiciously like the
"viral licence" theories where a contact with GPLed software magically
makes all of your software free for the taking.

This is simply not true.  To have software GPLed, you need to
explicitly licence it that way, regardless of whether it has come in
contact with other GPLed software or not.  Only if it has, you must
not redistribute a combined product under a different licence.  But
there is no automatic remedy involved: you always have _several_
choices to come into compliance: licence the whole under GPL, or
replace the GPLed parts by something different, or stop distributing
it.

> So, to relicense a piece of contributed work, you need an agreement
> from the author, either got in advance (like FSF copyright
> assignment includes) or got right before the license change.

To "relince" something it must have been licensed in the first place.

> Since XEmacs has many contributors who hold their copyright, this
> means that license switch would require collecting agreements from
> all of them, which might be practically impossible.

Well, this "practical impossibility" is exactly what Emacs development
has to put up with: collecting agreements from all contributors.

> That said, I agree with you that this is mostly an XEmacs problem,
> largely caused by their policy of not collecting copyright
> assignments.

It is not only collection of a copyright assignment (which makes
relicensing possible).  As far as I can see, their process does not
involve even getting _any_ formal licence to use the work.

As long as they are just relying on contributors playing nice with
them in case of necessity (and GPL v2 is going to be replaced with GPL
v3 at one time, too, and that will probably also mean that XEmacs has
to follow suit at one time), they might as well see how the
contributors will react to a licence change.

> The situation is not nice, but I don't see why FSF should go against
> its decision and its policies.  As Robert Chassell said (or meant),
> FSF cannot ask other to use GFDL if it doesn't use it itself.  After
> all, XEmacs isn't fully cooperative either, since FSF won't merge in
> non-assigned code.

Which is the FSF's choice.  The difference is that XEmacs has decided
not to bother about assignments and stuff, and due to that decision
they don't have such a general cooperation to offer in a manner useful
for Emacs.  In contrast, the FSF still has the choice to licence the
Emacs manual under different free licences because they bothered about
the assignment, and they bother about licences.

So the FSF, in contrast to XEmacs, has retained the technical
possibility to "cooperate" (namely abandon the business of trying to
choose a licence of their own and instead let the terms be determined
by XEmacs' different processes), simply because they have been more
careful.

I have yet to see a good reason why this should be necessary (I don't
think the "contributions are automagically licenced from the
contributor to the potential redistributor without explicit agreement
like the rest is" theory holds much legal merit) as well as desirable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Paul Pogonyshev]

David Kastrup wrote:
> Paul Pogonyshev <pogonyshev@gmx.net> writes:
> > David Kastrup wrote:
> >> b) why it would be technically impossible for you to change the XEmacs
> >> manual licence to the GFDL: it does not seem like you have handed out
> >> any written assurances that the licence is never going to change.
> >
> > I think because contributing a piece of work implicitly means that you
> > agree to distribute it under the _current_ license.
>
> Whose theory is that?  I don't see any of it in copyright law, and I
> don't see any of it in the GPL.

Mine, I guess.  Just to note, I'm not particularly familiar with all
this stuff, so take it lightly, please.  I'm just on that ``common
sense'' ground.

> This sounds suspiciously like the
> "viral licence" theories where a contact with GPLed software magically
> makes all of your software free for the taking.

I fail to see much similarity, but feel free to elaborate.

> This is simply not true.  To have software GPLed, you need to
> explicitly licence it that way, regardless of whether it has come in
> contact with other GPLed software or not.  Only if it has, you must
> not redistribute a combined product under a different licence.  But
> there is no automatic remedy involved: you always have _several_
> choices to come into compliance: licence the whole under GPL, or
> replace the GPLed parts by something different, or stop distributing
> it.
>
> > So, to relicense a piece of contributed work, you need an agreement
> > from the author, either got in advance (like FSF copyright
> > assignment includes) or got right before the license change.
>
> To "relince" something it must have been licensed in the first place.


I cannot understand what exactly you think about contributions without
signed papers.  Let's try to filter it out (again, I'm basing on my
common sense and little knowledge of copyright law, so, please, be
kind to my mistakes.)

So, let's assume John contributes a large patch (500 lines of code) to
XEmacs.  Since we are talking of XEmacs here, he is not asked for any
copyright assignments or other legal papers.

Now, what is the legal status of XEmacs + John's patch now?  (We assume
XEmacs is legally distributed under GNU GPL before the patch is added.)
I'm listing all possibilities I can think of.

Possibility 1.  John's patch is automagically licensed under GNU GPL
and ``license control'' is miraculously transferred to some mistical
``XEmacs spirit,'' that can change the license at whim, like FSF could
if it wasn't bound by our assignment papers.

This doesn't sound real.

Possibility 2.  John's patch is automagically licensed under GNU GPL,
but to relicense it, you need his blessing.  This is what I guessed
in the previous message based on XEmacs as a whole being distributed
under GNU GPL.

However, you wrote that John's code couldn't be licensed implicitly:
``To have software GPLed, you need to explicitly licence it that way,
regardless of whether it has come in contact with other GPLed software
or not.''  What does ``explicitly'' means, BTW?  I'm distributing a
program I wrote, with each file saying it comes under GPL and the GPL
text in `COPYING'.  Is this explicit enough?  Should John distribute
his patch and GPL text along with it to make it explicit?  Or is
signing legal papers the only option?  What is the difference between
licensing done by the project original author and its contributors in
terms of licensing?

Possibility 3.  John's patch is not licensed at all, because he didn't
explictly license it.

However, to the best of my knowledge of copyright law, you cannot
even _use_ non-licensed work, not to mention modify or distribute it.
This means that XEmacs people cannot legally merge John's patch in.
In other words, XEmacs + John's patch combination is illegal to use,
modify or distribute...

Possibility 4.  John loses the copyright on his contribution.

That would solve the problem, but placing something in public domain
is the decision of the author, so implicit lossage of copyright sounds
way less realistic than implicit licensing.  Besides, some of XEmacs
files do carry other than FSF's copyrights.

Possibility 5.  XEmacs does require some sort of explicit licensing of
contributions.

Again, that would solve all problems, but from what I've heard here,
this is simply not the case.


So, to summarize, if my reasoning is correct, there are only two options
left.

Either

	XEmacs is distributed under GNU GPL, because each contributor
	implicitly (and some of them explicitly, by assigning copyright
	to FSF) licensed it under that license.

Or

	XEmacs is used, distributed and modified illegally, because
	some parts of it are not licensed by copyright holders in any
	way.  This means that people working on XEmacs, as well as
	distributors and even common users can be sued for copyright
	infringement (or how do they call it.)

I personally don't feel easy about the second option.  I'd like to be
convinced that either the first or a third (missed here) option is
true.

Paul Pogonyshev

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

[Ben Wing]

> Which is the FSF's choice.  The difference is that XEmacs has 
> decided not to bother about assignments and stuff, and due to 
> that decision they don't have such a general cooperation to 
> offer in a manner useful for Emacs.  In contrast, the FSF 
> still has the choice to licence the Emacs manual under 
> different free licences because they bothered about the 
> assignment, and they bother about licences.

You seem to think that it is the duty of XEmacs to do whatever is necessary
to assure that GNU Emacs can use its code, even to the extent of hindering
the development of XEmacs itself.  In fact, if we had insisted on such a
policy, we could not have gotten the sorts of corporate assistance (Sun,
Amdahl, INS Engineering and others) that we got.

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

[David Kastrup]

"Ben Wing" <ben@666.com> writes:

>> Which is the FSF's choice.  The difference is that XEmacs has 
>> decided not to bother about assignments and stuff, and due to 
>> that decision they don't have such a general cooperation to 
>> offer in a manner useful for Emacs.  In contrast, the FSF 
>> still has the choice to licence the Emacs manual under 
>> different free licences because they bothered about the 
>> assignment, and they bother about licences.
>
> You seem to think that it is the duty of XEmacs to do whatever is
> necessary to assure that GNU Emacs can use its code, even to the
> extent of hindering the development of XEmacs itself.

You seem to think that it is the duty of Emacs to do whatever is
necessary to assure that XEmacs can use its manuals under XEmacs' own
conditions, even to the extent of reverting the licence choices of
Emacs itself.

Neither is the other's duty.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[David Kastrup]

Paul Pogonyshev <pogonyshev@gmx.net> writes:

> David Kastrup wrote:
>> Paul Pogonyshev <pogonyshev@gmx.net> writes:
>> > David Kastrup wrote:
>> >> b) why it would be technically impossible for you to change the XEmacs
>> >> manual licence to the GFDL: it does not seem like you have handed out
>> >> any written assurances that the licence is never going to change.
>> >
>> > I think because contributing a piece of work implicitly means that you
>> > agree to distribute it under the _current_ license.
>>
>> Whose theory is that?  I don't see any of it in copyright law, and I
>> don't see any of it in the GPL.
>
> Mine, I guess.  Just to note, I'm not particularly familiar with all
> this stuff, so take it lightly, please.  I'm just on that ``common
> sense'' ground.
>
>> This sounds suspiciously like the
>> "viral licence" theories where a contact with GPLed software magically
>> makes all of your software free for the taking.
>
> I fail to see much similarity, but feel free to elaborate.

It is the same "it comes into contact with GPL software, so it
magically gets licenced as GPLed software" theory.

>> This is simply not true.  To have software GPLed, you need to
>> explicitly licence it that way, regardless of whether it has come
>> in contact with other GPLed software or not.  Only if it has, you
>> must not redistribute a combined product under a different licence.
>> But there is no automatic remedy involved: you always have
>> _several_ choices to come into compliance: licence the whole under
>> GPL, or replace the GPLed parts by something different, or stop
>> distributing it.
>>
>> > So, to relicense a piece of contributed work, you need an agreement
>> > from the author, either got in advance (like FSF copyright
>> > assignment includes) or got right before the license change.
>>
>> To "reli[ce]nce" something it must have been licensed in the first
>> place.
>
> I cannot understand what exactly you think about contributions
> without signed papers.  Let's try to filter it out (again, I'm
> basing on my common sense and little knowledge of copyright law, so,
> please, be kind to my mistakes.)
>
> So, let's assume John contributes a large patch (500 lines of code)
> to XEmacs.  Since we are talking of XEmacs here, he is not asked for
> any copyright assignments or other legal papers.
>
> Now, what is the legal status of XEmacs + John's patch now?  (We
> assume XEmacs is legally distributed under GNU GPL before the patch
> is added.)  I'm listing all possibilities I can think of.
>
> Possibility 1.  John's patch is automagically licensed under GNU GPL
> and ``license control'' is miraculously transferred to some mistical
> ``XEmacs spirit,'' that can change the license at whim, like FSF
> could if it wasn't bound by our assignment papers.
>
> This doesn't sound real.
>
> Possibility 2.  John's patch is automagically licensed under GNU
> GPL, but to relicense it, you need his blessing.  This is what I
> guessed in the previous message based on XEmacs as a whole being
> distributed under GNU GPL.
>
> However, you wrote that John's code couldn't be licensed implicitly:
> ``To have software GPLed, you need to explicitly licence it that
> way, regardless of whether it has come in contact with other GPLed
> software or not.''  What does ``explicitly'' means, BTW?

If you are not assigning copyright, then a written and signed
statement is explicit enough for the law.

> I'm distributing a program I wrote, with each file saying it comes
> under GPL and the GPL text in `COPYING'.  Is this explicit enough?

The last time I looked, typical contributors were not distributing
complete versions of XEmacs.  Even if they were, if they change their
mind afterwards about their contribution, all you can demand is then
that they stop distributing XEmacs with their patch in it.

> Should John distribute his patch and GPL text along with it to make
> it explicit?

The GPL text is a text.  It's connection to the material must be
established.  It is not established by the files sitting in the same
directory.  If you have an exchange of consideration, like if you are
paying somebody, _then_ the material is licenced to you and, absent
any other written communication, it may be assumed that the
accompanying licence file is considered valid if it has been attached
by the selling party.  But if you, say, pay somebody for working on
XEmacs code and you don't put the GPL requirement in the contract, and
you pay him for code (not for work hours), then you may run into legal
trouble if he later claims he did not intend his work to be made
available to third parties.

> Or is signing legal papers the only option?  What is the difference
> between licensing done by the project original author and its
> contributors in terms of licensing?

Nothing.  If the original author changes his mind, explains that the
GPL licence file landed up in that directory by accident and he did
not have permission from management, anyway, and stops handing out
copies, and you have not given him anything in return, you can't drag
him to court for damages.

> Possibility 3.  John's patch is not licensed at all, because he
> didn't explictly license it.
>
> However, to the best of my knowledge of copyright law, you cannot
> even _use_ non-licensed work, not to mention modify or distribute
> it.  This means that XEmacs people cannot legally merge John's patch
> in.  In other words, XEmacs + John's patch combination is illegal to
> use, modify or distribute...

There you are.  If you need to go to court with a contributor that has
changed its mind, this is what you will get stuck with.  Lots of
business gets done every day without anything written down (life would
get complicated otherwise).  But if somebody changes his mind
afterwards, then the situation better be a standard situation that a
court can resolve without making it a major case.

> Possibility 5.  XEmacs does require some sort of explicit licensing
> of contributions.
>
> Again, that would solve all problems, but from what I've heard here,
> this is simply not the case.

It would solve the problem of legality.  It would not solve the
problem of having a single major copyright holder able to enforce
copyright in case of licence breaches (which is why the FSF demands
assignments instead of licences).

> Either
>
> 	XEmacs is distributed under GNU GPL, because each contributor
> 	implicitly (and some of them explicitly, by assigning
> 	copyright to FSF) licensed it under that license.
>
> Or
>
> 	XEmacs is used, distributed and modified illegally, because
> 	some parts of it are not licensed by copyright holders in any
> 	way.  This means that people working on XEmacs, as well as
> 	distributors and even common users can be sued for copyright
> 	infringement (or how do they call it.)

Or

        XEmacs is used, distributed and modified under the assumption
        that all of the various copyright holders (which might not
        even be tracked) have given their consent to do so and will
        never withdraw it.  Nobody can be sued for copyright
        infringement until it can be shown that this was done on
        purpose.  Merely distributors and users can be ordered to stop
        using copies of XEmacs with the respective code in it.  This
        will open the suitor for a counterclaim _if_ he can be shown
        to have distributed XEmacs himself.  In addition, if some
        party distributed binary-only versions of XEmacs, and the
        XEmacs team would try to sue him, he can have the case thrown
        out of court if he can show that XEmacs itself uses code from
        him without explicit permission.

> I personally don't feel easy about the second option.  I'd like to be
> convinced that either the first or a third (missed here) option is
> true.

When in doubt, ask a lawyer.  The above is not legal advice, it is
just one possible view.  The more possible views exist, the more
expensive court cases become, and the less predictable the outcome.
The FSF is a small organization that does not have the resources to go
to court with some company like SCO, and XEmacs is even smaller.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Richard Stallman]

    Richard, please reconsider.  You have a reputation of antipathy towards
    XEmacs.  If you're at all interested in mending fences a little, this would
    be a very easy step -- simply declare that we are allowed to use the code
    under our license (which was your license up through 2000 or so).  Otherwise
    you give the impression of actively hindering the XEmacs project.

I did not choose this license with a view to its effects on you; it is
the general FSF policy for manuals.  However, the fact that it is
inconvenient for XEmacs does not strike me as a disadvantage.  After
all, you have been uncooperative towards us for 10 years, and you
don't see that as a disadvantage.  We don't owe you anything, not even
small favors.

Despite my well-known and justified antipathy towards XEmacs, I
offered to consider changing licenses on parts.  However, the response
was an ungreatful threat, so I now withdraw that offer.  If I did even
the slightest thing for XEmacs now, I might give the impression of
being a pushover.


I ask all Emacs developers not to respond any further to whatever
they may say here about this.

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

[Stephen J. Turnbull]

>>>>> "Ben" == Ben Wing <ben@666.com> writes:

    Ben> David Kastrup wrote:

    >> Which is the FSF's choice.  The difference is that XEmacs has
    >> decided not to bother about assignments and stuff, and due to
    >> that decision they don't have such a general cooperation to
    >> offer in a manner useful for Emacs.

That's sad but true, although I would phrase it differently.

    Ben> You seem to think that it is the duty of XEmacs to do
    Ben> whatever is necessary to assure that GNU Emacs can use its

Not the duty; merely a precondition for any effort on the part of the
FSF.

    Ben> code, even to the extent of hindering the development of
    Ben> XEmacs itself.  In fact, if we had insisted on such a policy,
    Ben> we could not have gotten the sorts of corporate assistance
    Ben> (Sun, Amdahl, INS Engineering and others) that we got.

Which, you should recall, the FSF has deliberately foregone, to the
extent that accepting such assistance conflicts with the overriding
goal of promoting software freedom---which you should not confuse with
promoting free software.

OK, Ben, you tried, you didn't get what you wanted, but when we decide
we'd like to synch some parts of the manual, we can apply for the
specific relicensing then, as Richard suggested.



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Richard, please reconsider.  You have a reputation of antipathy
>     towards XEmacs.  If you're at all interested in mending fences a
>     little, this would be a very easy step -- simply declare that we
>     are allowed to use the code under our license (which was your
>     license up through 2000 or so).  Otherwise you give the
>     impression of actively hindering the XEmacs project.
>
> I did not choose this license with a view to its effects on you; it
> is the general FSF policy for manuals.

Definitely.

> However, the fact that it is inconvenient for XEmacs does not strike
> me as a disadvantage.

It strikes me as a disadvantage, though not because of XEmacs in
particular, but because it will be a disadvantage for _any_ derived
project, and the whole point of a public licence like the GPL is not
to put the copyright holder into a special position with regard to
software development.

> After all, you have been uncooperative towards us for 10 years, and
> you don't see that as a disadvantage.

You are speaking here for Ben Wing, presumably.  But Ben Wing is not
the only developer of XEmacs.  I know pretty well, for example, that
Stephen Turnbull, the current maintainer, considers the inability to
broadly contribute back code with the stringency required by the Emacs
project a disadvantage and has invested substantial amounts of work to
remedy this in the past.  But he as well as others are stuck with a
history they can't change at their will.

And that history is one of taking the "GPL" at its letter and spirit,
developing in the manner that the "Public" in "General Public Licence"
is suggesting, a manner that we as Emacs developers are not free to
enjoy because our laws make it important that there remain substantial
pieces of software which may be defended in court by a substantial
copyright holder without conflict of interests from other
contributors.

> We don't owe you anything, not even small favors.

Correct.  We don't owe them anything.  But the freedoms they enjoy are
the freedoms we are fighting for in the first place.

And where we find that our fight does not lead to the desired freedoms
for the recipients of our software, we need to double-check.  To meet
our own goals, not those of the others.

> Despite my well-known and justified antipathy towards XEmacs, I
> offered to consider changing licenses on parts.  However, the
> response was an ungreatful threat, so I now withdraw that offer.  If
> I did even the slightest thing for XEmacs now, I might give the
> impression of being a pushover.

Let me put on the record here that I'd not consider you to be a
pushover just because you are willing to judge requests for
relicensing on their merit piece by piece, as you agreed to before,
without letting yourself be swayed by some cheap rhetoric of Ben
Wing.  Even if Ben Wing was the only beneficiary of that process, we
have the unfortunate situation that a free project with a free
community is encountering problems with our choice of free licences in
the intended manner.

We need to look into this.  Maybe after considering their case in
detail we'll find that the situation is such that a licence change to
GFDL is something that their processes should have made possible in
the first place, and that there is nothing to be done on our side.

But it would be a mistake not to look into this possible problem
merely because the superficial beneficiary is XEmacs, and there are
some XEmacs developers some of us don't like.  It still is a case of
downstream maintenance of free software, and if we don't care about
the effects downstream from a copyright assigned pool, we might as
well forget about public licensing altogether.  In the long run, we
should strive for a solution that does not necessitate any exceptions.
But in the mean time, we should try to hold up the spirit of our free
licences, if necessary, manually and learn about the problems with
their application downstream.

> I ask all Emacs developers not to respond any further to whatever
> they may say here about this.

I'd offer to go here as a go-between if necessary where individual
more detailed requests are concerned.

I agree with you that there does not seem to be a persuasive case for
blanket permissions and agreements currently, and so I'll be happy to
take this discussion into private.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Robert J. Chassell]

Paul Pogonyshev <pogonyshev@gmx.net> asks,

    I'm distributing a program I wrote, with each file saying it comes
    under GPL and the GPL text in `COPYING'.  Is this explicit enough?

No.  I do not know whether you are connected to an employer or
university who owns your work.  

You may not have the legal rights either to distribute or to claim a
copyright on work done on your own time using only your own resources.

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