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
