Re: The draft Position statement on the GFDL
On Sun, May 02, 2004 at 12:59:51PM -0700, Don Armstrong wrote:
> [Raul: As I assume you're not subscribed to -legal, I'm taking the
> liberty of Cc:'ing you.]
Thanks.
I should be subscribed now, but I was not previously. I appreciate
the attention.
On Sun, 02 May 2004, Raul Miller wrote:
> > any technical means of controlling copies (such as having the gnu
> > "cp" command installed on your system) could be seen as violating
> > the GFDL.
>
> Or chmod, for instance. Yes, this is largely agreed to be one of the
> most obvious and glaring bugs in this license.
>
> > 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".
>
> It's actually about both, specifically about the ability of you or
> others to read or further copy copies that you have made. Clearly on a
> computer, a copy that resides upon the hard drive is a copy that you
> (or the administrator) has made, so obstructing or controlling the
> further copying (or reading) of that copy is dissallowed by the
> license.[1]
Hmm... in the U.S., some such copies are explicitly outside the scope
of copyright law (17 USC 117). I guess the question is: what specific
problem(s) does this phrasing create?
I think the phrase "technical measures" in the GFDL refers to the concept
discussed in this article from the WIPO copyright treaty:
Contracting Parties shall provide adequate legal protection and
effective legal remedies against the circumvention of effective
technological measures that are used by authors in connection with the
exercise of their rights under this Treaty or the Berne Convention
and that restrict acts, in respect of their works, which are not
authorized by the authors concerned or permitted by law.
It's not clear to me why other kinds of technology (not associated
with any sort of right to intellectual property) which prevent use or
distribution should qualify as "measures".
When a user deletes a file, or ceases to provide power to the computer
which holds the file, this certainly prevents reading of the file
instance. However the purpose of deleting the file or turning off the
power is not to prevent "unauthorized people" from retaining copies.
Technological measures, as I understand it, means there are people who
do not have the right to see copies of the material in question, which
the measures are designed to prevent.
Mind you, my thinking might be flawed. If so, I'd appreciate it if
someone could spell out for me the relevant legal issues.
> > 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?
>
> It's a violation of DFSG §6 and §7, as it forms a useage restriction
> against a class of users (those who use the work digitally) or an
> endeavor (those who must have the work encrypted, or controlled.)
> [It's also a violation of Freedom 0[2], the ability to use a work for any
> purpose, in any purpose.]
"It forms a usage restriction against a class of users (those who use
the work digitally)" seems to be based on the assumption that technology
which does not represent rights management is restricted by this license.
I'm questioning this assumption, so I'd like to see some kind of rationale
for why this assumption is valid.
Also "... or an endeavor (those who must have the work encrypted, or
controlled)" has two diverging interpretations --
[*] Where the requirement for encryption or control is to prevent
unauthorized people from getting copies of the documentation.
This endeavor is contrary to the spirit of the DFSG, just as "people
who must distribute the software in a non-free fashion" is an endeavor
contrary to the spirit of the DFSG.
[*] Where the requirement for encryption or control has nothing to do with
digital rights management. This gets back to the question of whether or
not "non-rights management activities" count as "technological measures"
in the context of copyright.
> > 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.
>
> I'm not sure if it's been raised in the context of the DFSG, but as
> some people have been mixing and matching GFDLed works with GPLed
> works, or seem to want to, this was something that came up in
> discussion.
As long as we're being clear that this is not a DFSG issue, I have no
problem with discussing the scope of this problem. Any "must rename"
or "changes must be patches" license conflicts with the GPL, and we
consider many of these to be DFSG free.
> > Invariant Sections
> >
> > redistribution of derived works are allowed
>
> Redistribution of derived (or modified) works of specific sections are
> dissallowed. We have long held that licenses which require that
> specific parts of the functional work be unmodifiable are non-free
> because they violate DFSG §3.[3]
It seems to me that it's DFSG §4 which deals with the "unmodifiable
sections" issue. DFSG §3 simply requires that derived works be
redistributable and doesn't address any restrictions on the right to
redistribute derived copies (such as GNU's restriction where people
who don't distribute their own modificates to GPLed software under GPL
compatible terms lose the right to distribute derived works).
> > these points are not GFDL specific -- and aer more a problem in the
> > sense that the DFSG allows the GFDL than anything else.
>
> We, in general, have been viewing the DFSG as a set of guidelines,
> rather than a definition (vis. the OSI's OSD). As such, we really
> haven't had a problem with interpreting the guidelines broadly instead
> of narrowly, and thus capture these licenses which may pass the
> letter, but violate the spirit.
This seems reasonable.
Though if "GFDL violates the spirit of the DFSG while passing the letter"
is actually the case I'd rather have the description of the problem
explicitly state:
While the GFDL might meet the letter of the DFSG it violates the spirit
(and then characterize the "immutable sections" as the primary concern,
and "concern about ambiguous meanings of the phrase 'technological
measures'" as a secondary concern).
Once again, I might be mistaken (I often am) but if so, I'd prefer
that responses spell out the relevant reasoning (as opposed to simple
assertions).
Thanks,
--
Raul
Reply to: