Re: Unidentified subject!
Richard Stallman wrote:
The question at hand is whether Debian should accept or reject
GFDL-covered manuals. The argument for that is that there are many
such manuals and they would be useful to include, and the DFSG can
be interpreted to accept it.
As one of those more inclined to listen to the rationale behind the
GFDL, and as one who still leaves open the possibility that the
DFSG might allow for something very much like the GFDL, I
certainly hope that you do not intend the above to be an exhaustive
list of the arguments in favor of including GFDL-licensed manuals
in Debian. The arguments appear to be:
1) There are many GFDL manuals.
2) The many GFDL manuals would be useful to include.
Obviously Debian (and the FSF) would not accept such arguments in
other contexts. For instance, one would not make much headway in
either circle regarding the inclusion of proprietary software by
arguing either of:
1) There are many proprietary software programs.
2) The many proprietary software programs would be useful to
include.
It is obviously a great inconvenience to replace all the GFDL
manuals with new manuals licensed in a DFSG-consistent way. I
doubt anyone here disputes that. (If they do, they are welcome
to write all the replacement manuals and report back when they
are done.) But what we must find is an argument that clearly
demonstrates why the GFDL should be seen as consistent with the
DFSG.
Part of such a demonstration might include an explanation of
the many tough decisions that the FSF had to make when drafting
the GFDL, and the rationales behind each part. With a greater
understanding of these tough issues, Debian developers might
say, "Wow. They're right. That is a tough issue to deal with
and we cannot think of any better way to write a license to
deal with that problem. Hmmm, perhaps the GFDL is as free as
we can get regarding this issue."
If instead Debian developers say, "No. We don't think that is
the best licensing solution to the problem you describe. What
if instead the license said XYZ?" Then we are now making
progress toward drafting an improved version of the GFDL that
just might please everyone.
Collaborating in such a way is not easy, and I'll admit that
few here have demonstrated the will to keep their egos/tempers
reigned in long enough to have such a fruitful discussion.
Perhaps that is where Bruce Perens' efforts will be helpful.
But, I earnestly believe that if you took the parts of the GFDL
that list members have pointed out as particularly egregious
and described in detail what you were trying to accomplish and
why the current version of the GFDL seems/seemed to you the
best way to accomplish that, then at least some list readers
would have one of the above reactions described and progress
toward common ground could begin to be reached.
If I remember the list's complaints well enough, some key areas
to address would be:
1) Invariant sections
(a) Why have them?
(b) Why have each part of the license that deals with invariant
sections be precisely as it is? Could there be another way of
meeting the goals stated in (a) above that would be agreeable
to each group?
2) GPL Incompatibility
(a) Why make the GFDL incompatible with the GPL?
--Assumed a "Yes" answer to the question:
--(i)Does the FSF agree that the GFDL is GPL-incompatible?
3) No DRM
One of your previous messages to this list suggested to me that
you might not have intended some of these problems and were
"looking into it". So,
(a) What's the status of that?
4) Transparent and Opaque Copies
Jeremy Hankins wrote: "Under certain circumstances the document
may not have a transparent version (for example, after being
modified with a proprietary word processor). This would make it
impossible to meet the requirements of section 3 ("Copying in
quantity") of the GFDL."
(a) Did the FSF intend this effect?
(b) What changes to the license could both remove this problem and
still be acceptable to the FSF?
I think answers to these questions are critical if progress is to
be made. If the FSF simply says, "This is our license. Now it is
solely up to you to include manuals licensed in this way or not."
then I think it is pretty clear that the consensus here will not
favor the GFDL. This would be a shame both because of the enormous
work it would create in replacing manuals, and because I still
believe that with several tweaks to the GFDL many here would find
it DFSG-consistent.
--
Brian W. Carver -- http://rurnt.com/brian ,''`.
Try a free operating system at http://www.debian.org : :' :
Support EFF! http://www.eff.org `. `'
They're defending YOUR rights online! `-
Reply to: