Re: The draft Position statement on the GFDL
Manoj Srivastava wrote:
> Hi,
>
> Raul miller posted this mail on debian-private, with an
> explicit permission to quote it elsewhere. I am doing so now.
>
> manoj
>
> On Tue, Apr 27, 2004 at 05:24:15PM -0500, Manoj Srivastava wrote:
>> Can you refute the hard facts found on
>> http://people.debian.org/~srivasta/Position_Statement.xhtml?
>
> I see several topics there:
>
> DRM Restriction
>
> One question here, is what does "control copying" mean? In a very general
> sense, making a copy is controlling a copy, and likewise not making a copy
> is controlling a copy. Therefore, any technical means of controlling
> copies (such as having the gnu "cp" command installed on your system)
> could be seen as violating the GFDL.
>
> However, on re-reading the license, I see that the clause in question
> actually reads:
>
> "obstruct or control the reading or further copying of the copies
> you make or distribute"
>
> In other words, clause isn't about copying, but about "further copying".
> I believe this indicates that once you've given a copy to someone else,
> you've not placed specific technical obstacles in the way of them making
> copies. In other words, once distributed, the distributor has given up
> legal control of the copy.
"Make or distribute" is the biggest problem here. If it said "make and
distribute", you might be correct. As it is actually written, it requires
that you not place specific technical obstacles in the way of people
reading or making copies of the copy you *make*, even if you don't
distribute it at all.
As it is, this does seem to prohibit "chmod -r" on a shared computer. Is
that really OK?
Frankly, if it was changed to "make and distribute", this would probably
evaporate as a complaint.
> I'm fairly confident the phrase "technical measures to obstruct or
> control" refers to the concept of having a legal right to obstruct
> control the reading or copying of the document after distribution.
I wish it meant that. That's just not what it says though. It refers
specifically to technical measures, but not to legal rights. If it said
"You may not use technical measures to prevent recipients from having or
exercising the rights they would otherwise have...", it would be just fine.
In a funny sort of mirror image, the biggest problem with the DMCA is that
it prohibits circumventing technical restrictions *even* when this is done
solely for otherwise legal purposes. If it prohibited circumventing
technical restrictions in order to circumvent legal restrictions, that
would be quite different.
> More specifically, since the GFDL is a legal document, the primary
> effect of this clause is to deny someone the right, in court, of claiming
> someone else has subverted the barriers they placed on copying.
It denies the right to make private copies. It appears to allow the
copyright holder to sue me if I make a private copy without separate
permission.
While the FSF may not interpret it this way, this is what it says, and we
have to expect that other copyright holders will take it at its word.
It appears to be legally possible to prohibit private modifications, so we
can't rely on that.
Although this is not explictly prohibited by the DFSG, it seems very much
against the spirit of it, and would cause no end of trouble if anyone ever
attempted to enforce it.
> I don't see that this is a problem in the context of the DFSG. If it is,
> could you spell it out more clearly?
>
> Alternatively, if you think I've mis-interpreted this section of the
> license, could you spell out the interpretation you're seeing in some
> fashion [which isn't self contradictory]?
Yep -- see above. :-)
>
> Transparent and Opaque Copies
>
> Again, I don't see that this is a problem in the context of the DFSG.
> I see that the restrictions are different from GPL restrictions, but
> the DFSG does not require all licenses be GPL compatible.
This part *may* be OK. But wasn't this discussed in detail?
>From Manoj's draft position statement:
"Section 3 (Copying in Quantity) of the GFDL states that it is not enough to
just put a transparent copy of a document alongside with the opaque version
when you are distributing it (which is all that you need to do for sources
under the GPL, for example). Instead, the GFDL insists that you must
somehow include a machine-readable Transparent copy (i.e., not allow the
opaque form to be downloaded without the transparent form) or keep the
transparent form available for download at a publicly accessible location
for one year after the last distribution of the opaque form."
This seems moderately oppressive. But assume that that's OK; there are
bigger problems.
>From the GFDL:
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the general
public, that is suitable for revising the document straightforwardly with
generic text editors or (for images composed of pixels) generic paint
programs or (for drawings) some widely available drawing editor, and that
is suitable for input to text formatters or for automatic translation to a
variety of formats suitable for input to text formatters. A copy made in an
otherwise Transparent file format whose markup, or absence of markup, has
been arranged to thwart or discourage subsequent modification by readers is
not Transparent. An image format is not Transparent if used for any
substantial amount of text. A copy that is not "Transparent" is called
"Opaque".
Now, this is not a good set of definitions.
>From Manoj's draft postion statement:
Matthew Garrett Notes:
Awkward. Even if the Microsoft Word file format was well described, it
would not be modifiable in a "generic text editor". The GPL requires
distribution of source in "The preferred format for modification" - the
GFDL limits what that preferred form may be. The lack of definition of
"copy" here makes things unclear - if my only source is a formatted Word
document, does a plain text output of the contents qualify as a transparent
version? Without clarification, this may prevent certain types of
derivative work being produced, which would be a violation of DFSG 3.
Anthony DeRobertis elucidates:
You missed the requirement to include transparent copies (more on that
later -ms). You have used MS Word as the problem with the definition of
transparent sections. More interesting ones are OpenOffice and Lyx. Also,
music is interesting, too.
--
This is the serious freeness issue with "Transparent" and "Opaque" formats;
the overly specified definitions mean that certain types of documents don't
appear to have any transparent formats (notably word processing files, even
ones for Free word processors, and sound files of any sort). Which makes
it impossible to make certain kinds of derivative works. :-P
If these were defined in broader, less restrictive terms, this would not be
a problem.
> We already have this "incompatible license" issue in other contexts.
>
> Invariant Sections
>
> I agree the GFDL's invariant sections are troublesome. However,
> redistribution of derived works are allowed, so Clause 3 of the DFSG
> isn't the issue.
Well, it allows some derived works, but not all. Generally clause 3 has
been interpreted to mean that the license must allow derived works in
*general*, not merely certain derived works.
Interpreting it to allow licenses to contain arbitrary restrictions on what
derived works are permitted would open up loopholes the size of whales.
For a quick example, it would immediately allow Sun's Java into main; it
would allow all those other licenses which only permit conformant
implementations; it would allow licenses which permitted derivative works
to be made only for purposes of porting; etc.
Now clearly some restrictions on modification are free restrictions: those
which are legal requirements even for public domain works; those which
require appropriate attribution or lack thereof; those which require
preservation of legal notices.
However, requiring that all derived works have a huge honking hunk of
unmodifiable text in the middle of them, with a specific title, listed in
the table of contents, untranslated, does not seem to be a reasonable
restriction!
--
> Clause 4 might be a problem, but there is no specific place where a
> change is disallowed in the source code.
Well, actually, it does; the GFDL disallows any change which removes
Invariant Sections from *any* form of the work. This clearly includes the
source code as well as any other form.
>From clause 4:
'The license may restrict source-code from being distributed in modified
form _only_ if the license allows the distribution of "patch files" with
the source code for the purpose of modifying the program at build time.'
Given a texinfo source file, the GFDL license does not explicitly allow the
distribution of patch files to remove the Invariant Sections at build time;
although this is probably implicitly permitted.
And further in clause 4:
'The license must explicitly permit distribution of software built from
modified source code.'
And the GFDL does *not* explictly permit distribution of the PDF, info, or
other files built from the modified texinfo source.
> The requirement that the
> resulting text be unchanged is probably the key sticking point.
Yep.
<snip>
--
There are none so blind as those who will not see.
Reply to: