On Sun, 02 May 2004, Raul Miller wrote: > On Sun, May 02, 2004 at 12:59:51PM -0700, Don Armstrong wrote: > > 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] > > 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? Not all jurisdictions have a concept of fair use, so licenses which rely upon such a concept generally are not free. > I think the phrase "technical measures" in the GFDL refers to the > concept discussed in this article from the WIPO copyright treaty: I agree that that is most likely what they were aiming at, and if you read this clause very narrowly, that might be the case. However, the term "technical measures" isn't particularly well defined, and so we have (as we generally do) read the license as conservatively as possible. I'm personally not averse to goal of this clause, which is to make sure that further copies can be made. It just needs to be written in a manner that is consistent with the DFSG. > "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. Sorry, I kind of elided over a critical point there. As most users in using the work digitally on a hard drive, for example, must necessarily make a copy (from network->hd->ram->vram->phosphorus FE), this clause applies to that specific class of users. Those reading the work in a hard copy form, for example, don't need to make a copy. [This poses a problem for jurisdictions without a concept of free use.] > 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 is the class that I'm refering too (poorly). That is, those who are required by law or contract to have all works in their possession on an encrypted medium, or in a tempested environment. > 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. Yes. There are others who are more expert on these particular issues than I and might have a differing opinion. > 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). You can construct arguments for them both applying. I tend to consider DFSG §4 as a specific exception to §3, so I rarely apply it unless it applies directly. In this case, because you are unable to modify a specific section, you are not able to modify the work. [That is, you can only modify a subset of the work.] It's different from the GPL issue, because DFSG §3 specifically states that you must be allowed to distribute those modifications under the same license, but it doesn't say that you need to be able to distribute those modifications under a different license.[1] > 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). Yes. However, at least in my opinion, we haven't encountered a case where the GFDL is merely contravening the spirit. It also seems to be contravening the letter as well. Don Armstrong 1: Some might argue that the GPL is explicitely grandfathered in by §10, but I prefer to test it against the other 9 points of the DFSG and use it as an internal consistency check of arguments that we make. -- This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_ http://www.donarmstrong.com http://rzlab.ucr.edu
Attachment:
signature.asc
Description: Digital signature