On Tue, Mar 14, 2006 at 03:06:58PM -0500, Raul Miller wrote: > For the DRM issue to be significant, we'd have to have reason to > believe that a judge would not be familiar with the legal meaning of > the phrase "technical measures" in the context of copyright law. > Other meanings of "technical measures" would lead to ludicrous > conclusions (for example: once we've started giving someone a copy we > must keep spamming copies, never being allowed to stop).
Encrypting a document (whether via GPG or HTTPS) sure seems like a technical measure to obstruct the reading of copies. > And the Opaque issue only applies when the transparent copies are not > distributed. It's simple enough to include the transparent copies in > any .deb, and it's simple enough to file an RC bug report against any > package with GFDL'd content which doesn't include the transparent > copies. Maybe I'm misunderstanding the issue you're referring to. My issue with the "transparent copies" bit is that it prohibits converting the document to, say, a Word document. The GPL allows it: I can convert it to Word, and make that my source form (using it for all future modifications, throwing away the original HTML and all that). The GFDL prohibits this. The "Transparent copies" definition is being used like "source" in the GPL, but narrowed to exclude source forms that the FSF doesn't like (even entirely open formats, if they can't be edited with "generic text editors".) > As for the other issues you call out, I don't think this GR really > says much about them: Where these elements are invariant, the > GR doesn't say anything about GFDL licensed documents which > contain them. Where they're not invariant, the restrictions > imposed are not any more obnoxious than practical restrictions > on software for non-legal reasons, or practical restrictions on > patch clause dfsg software. I think that, prior to this, the patch clause exception was the biggest blunder in the history of the DFSG: calling software which you're never allowed to reuse code from Free. Code reuse is one of the basic goals of free software. It's the biggest error not so much because of the software under these licenses (which are few), but because it's been used to argue as you have: "patch clauses even prohibit putting code in version control; since we allow that, we should allow all kinds of other onerous restrictions, too." I had hoped that this might be fixed some day, but this GR moves things a couple miles in the other direction and I no longer retain any such hope. > It's never been clear to me that the Dissident test is a accurate > reflection of the DFSG. I can think of many ways for a dissident to If a dissident is placed in serious danger if his identity is revealed, I can't think of any way he could work around a license that requires revealing his identity. > work around such problems (except for dissidents who more slavishly > follow their government's suggestions than most non-dissidents -- but > I don't think that's a serious issue). I'm not sure what you mean by "follow their government's suggestions". If the license says "identify yourself", and identifying myself working on cryptography software will get me thrown in a dark cell, what "government suggestion" am I slavishly following? Copyright law itself? "The government" isn't the operating force in the dissident test, anyhow. The dissident test is not simply about dissidents and governments; that's the case used as a test, and for explaining the problem, but the test is applicable much more generally. That's why it's a test. I might work for a company that feels threatened by Free Software, and doesn't want its employees contributing to it. (I don't, to be clear; we actively contribute to free software.) If I was to spread Free Software, and was discovered, I might find myself without a job, so I'd do so anonymously. The Dissident test deals with the many reasons one might need to remain anonymous in order to exercise DFSG freedoms. (If you're thinking about "you've probably signed over your copyright already", then use "future employers won't hire you". Free licenses shouldn't prohibit anonymity.) > Maybe none of this is new, but aside from the Opaque and DRM issues, > none of the proposals or supporting material on vote.debian.org > indicate that any of these issues are to be taken seriously. That's the problem: license problems are not being taken seriously. The GR casually (and, without another GR, permanently) ignores all of these issues, saying "from now on, every issue you find in the GFDL is to be ignored, preemptively labelled free", and probably also "any freeness issues are automatically OK if you can find them in the GFDL". The DFSG must now be read to allow mandating identifying yourself, making random section headers invariant, prohibiting converting to formats the author doesn't like, and so on. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]