all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: rms@gnu.org
Cc: Carsten Dominik <dominik@uva.nl>, emacs-devel@gnu.org
Subject: Re: Copyright question
Date: Fri, 13 Jun 2008 11:51:09 +0200	[thread overview]
Message-ID: <86ve0dirxu.fsf@lola.quinscape.zz> (raw)
In-Reply-To: <E1K70Yc-0004QV-5G@fencepost.gnu.org> (Richard M. Stallman's message of "Fri, 13 Jun 2008 00:06:34 -0400")

Richard M Stallman <rms@gnu.org> 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




  parent reply	other threads:[~2008-06-13  9:51 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-12 14:43 Copyright question Carsten Dominik
2008-06-12 19:30 ` David Hansen
2008-06-12 19:33 ` Stefan Monnier
2008-06-13  8:19   ` Carsten Dominik
2008-06-13  9:59     ` David Kastrup
2008-06-13 22:48     ` Richard M Stallman
2008-06-14 13:15       ` Carsten Dominik
2008-06-14 20:11         ` Don Armstrong
2008-06-15 17:55         ` Richard M Stallman
2008-06-12 19:40 ` Glenn Morris
2008-06-12 20:47   ` Juanma Barranquero
2008-06-12 20:51     ` İsmail Dönmez
2008-06-12 23:31       ` Glenn Morris
2008-06-13  8:55         ` Andreas Röhler
2008-06-13  9:44           ` Alan Mackenzie
2008-06-13  9:36             ` Miles Bader
2008-06-13 13:35               ` Stefan Monnier
2008-06-13 10:35             ` Andreas Röhler
2008-06-13 11:00               ` David Kastrup
2008-06-12 21:08     ` David Kastrup
2008-06-12 21:31 ` Don Armstrong
2008-06-12 23:03   ` Bastien
2008-06-13  3:13     ` Alfred M. Szmidt
2008-06-13  4:06 ` Richard M Stallman
2008-06-13  7:58   ` Stephen J. Turnbull
2008-06-13  9:51   ` David Kastrup [this message]
2008-06-13  9:58   ` Alan Mackenzie
2008-06-13 22:48     ` Richard M Stallman
2008-06-14 12:03       ` Alan Mackenzie
2008-06-14 19:16         ` Glenn Morris
2008-06-14 19:28         ` Eli Zaretskii
2008-06-14 21:36         ` David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86ve0dirxu.fsf@lola.quinscape.zz \
    --to=dak@gnu.org \
    --cc=dominik@uva.nl \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.