Re: Copyright question

[David Kastrup]

Richard M Stallman <address@hidden> writes:

> Debian's policy is foolish and unfriendly to us.  So we do not cater
> to it.  If they don't like the results, they should change the policy.

There are two points at issue here.  One is standalone documents
(typically perused in one piece), and one might disagree or not disagree
with Debian: only the documents themselves are affected.

But in this case we have documentation where the most important form is
the info form, and it gets more and more intertwined with Emacs as
whole, to a point where we distribute both together because they form an
integrated whole.

Now the GPL states for modification:

    c) You must license the entire work, as a whole, under this
    License to anyone who comes into possession of a copy.  This
    License will therefore apply, along with any applicable section 7
    additional terms, to the whole of the work, and all its parts,
    regardless of how they are packaged.  This License gives no
    permission to license the work in any other way, but it does not
    invalidate such permission if you have separately received it.

But this means that if somebody comes across an Emacs without Emacs
manual, and a separate Emacs manual, that he can't legally recombine
both into one project.  Also freely copying and pasting back and forth
between Emacs code and Emacs manual is not permitted.

While I have no problem with the GFDL as a licence for the printed Emacs
manual and a separately distributed manual, I find that in its form
integrated in the Emacs distribution, the borders between manual and
code are more or less arbitrarily set by the copyright holder, and they
become inviolable for any subsequent person working on them.

And that sort of defeats the purpose of a "public" license in that the
copyright holder remains the only person capable of doing essential
maintenance and restructuring tasks.

So even while we need not bend over for Debian's sometimes rather wild
ideas in particular with regard to the GFDL, my problem here is not with
the GFDL per se, but that GFDL and GPL don't mix and are incompatible.
And yet we form an integrated whole without a really sharp functional
borderline and distribute it, and people have to adhere to the fuzzy
borderline and hope for the best legally.

For that reason, I would very much welcome dual-licensing GPL/GFDL where
the principal form of a manual will be info, and where code and manual
form as tightly a whole as it does nowadays with Emacs.  Since the GPL
demands redistribution of the corresponding machine-readable source, I
doubt that the dual-licensing will lead to much GPL-licensed output in
actual print.

So in short: never mind what people (in particular Debian) think about
the GFDL per se, but the GPL incompatibility is something that worries
me where the documentation is an integrated part of a GPLed project.

And Emacs is probably the boilerplate example.  Of course, we got there
gradually: at one point the manual was much more concise, and much more
a separate thing (and we also distributed it separately and DOC strings
and customization menus did not link into it).  While the GFDL was not a
problem for the Emacs manual at the start, I think at the current point
of time making it dual-licensed GPL/GFDL would put the "Public" in GPL
for Emacs as a distributed whole project back into perspective.

In the end, this is for the copyright holder to decide, so there is not
much sense in fighting or debating about it, in particular on
Emacs-devel.  So I'll try very hard not to debate or defend this view of
mine.  I just felt I should state it since I have the feeling that Emacs
is moving more and more into making the manuals an integrated part of
it, and I feel that this makes our way of distributing it more
problematic with regard to the spirit of the "Public" in "GPL".  Because
I feel less and less like we ourselves are distributing the work "as a
whole" under the terms of the GPL, and yet demand that others do.

A dual-license would remove that concern for me.

-- 
David Kastrup