[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Results for Debian's Position on the GFDL



On Tue, Mar 14, 2006 at 07:15:21PM -0500, Raul Miller wrote:
> On 3/14/06, Glenn Maynard <glenn@zewt.org> wrote:
> > Encrypting a document (whether via GPG or HTTPS) sure seems like a technical
> > measure to obstruct the reading of copies.
> 
> In the general case, this is not a technical measure to enforce the copyright
> holder's legal rights on the recipient of the copy.

It has many uses; that is one of them.  The same is true of encryption.

> If the recipient is not allowed to decrypt the document, except under legally
> restrictive circumstances, that's a different story.

For what it's worth, I fully agree with trying to disable the legal teeth
of DRM.  That is, I think people should be allowed to use technical measures
to do whatever they want, but I should be legally allowed to circumvent it.
"Security-by-encryption" is one thing; "security-by-jail-time" is quite
another.

(I don't think any special attempt to prevent the technical measures
themselves are necessary, since the GPL's source requirements already
did that: an encrypted, locked, unmodifiable copy is not source.)

> > 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).
> 
> Not necessarily.
> 
> As a counter example: A word document is not the preferred form for working
> with .c source code, in the general case.

You're nitpicking my example, not what I was saying.  The GPL allows it,
for works where Word documents are a plausible "preferred form for
modification".  This makes it a reasonable source requirement, ultimately
"give me the form which you actually use to make changes to the work".

The "transparent copies" requirement smells like a source requirement,
but it's more than that: it prohibits changing the source form to a Word
document, even if it's a work where Word is suitable (eg.  not general C
source code), and even if it really is your preferred form for modification.

The GPL doesn't prohibit doing so; it says "any form can be source, if it
really is source, but you can't lie and handwave and pretend an obscured
bogus format is source if it's not".  (That's why the GPL does allow Word
as a source format for C code, if the C code is example code in a manual,
while *not* allowing you to hide your changes to the Linux kernel by
distributing the source as a Word document and calling it "source" when
it's not.)

(Defining "source" is one thing the GPL did amazingly well at.)

> > 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.
> 
> That's allowed.
...
> Of course, in some specific cases a word document might be acceptable.
> Likewise, in some specific cases a word document might be transparent.

   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 

You can't revise a Word document with a generic text editor.  I doubt
the format--which, I believe, changes incompatibly with each revision of
Office--is public, either.  The "transparent copies" definition seems to
very deliberately exclude Word documents, so using Word as your source
format seems to be prohibited.

> > 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.
> 
> I don't see any votes on this issue.  Perhaps other people in Debian
> disagree with you?

Code reuse is fundamental to Free Software.  I'd find disagreeing with
that to be akin to disagreeing that source availability or permission
to make changes to the work are fundamental--so far from my understanding
that I can't imagine how anyone could hold that view.

That said, my confidence in Debian's concept of "freedom" has taken a
dive just recently, and I'm much more inclined to agree that Debian
Developers may not consider code reuse important.  (But the same change
in my perception of the opinions of Debian applies to the other core
elements of Free Software.)

> > 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.
> 
> Well, it wouldn't "just happen" by itself.  First you'd need a solid core of
> acceptable software to build a distribution on.  Once you have that it's
> reasonable to go about organizing the distribution in terms of
> how the code can be reused.  Until then, this is a development issue,
> not a package management issue.

I'm sorry, you lost me.  Debian is already a solid core of software without
patch clauses; only a tiny handful of software in Debian have them.  All it
would take to fix this would be to remove those (none of which are critical
to Debian, though--like any software--no doubt some people find them very
important) and to have a successful GR to strike the patch exception.  I
don't expect that to "just happen", which is why, from time to time, I raised
the issue on Debian lists for discussion.

Aside from the patch exception, the DFSG is consistent on this: "must
allow modifications and derived works, and must allow them to be
distributed under the same terms as the license of the original software".
That's in line with my own practical understanding of the issue: while
you can't reuse any code with any other code, you ordinarily *can* reuse
code with other code under the same license.  (That's just license
compatibility.)  Patch clauses are the exception: you can't reuse it *at
all*.

> > 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.
> 
> The dissident can use pseudonyms, proxies, ambiguity, and obscurity.

As far as I can tell, the GFDL does not allow using a pseudonym.

   "Both covers must also clearly and legibly identify you as the publisher
   of these copies."

Pseudonyms would not identify me; the very purpose of a pseudonym is to
not be personally identified.  Ambiguity would also violate this
requirement.  I'm not sure what you mean by "obscurity"; "use my name,
and hide in a cave where nobody can find me"?  I don't understand
the "proxies" example, either.  (If the only way I can redistribute is
to give it to someone else and ask him to do it for me, then I can't
redistribute ...)

(By the way, this case is different in details from other typical Dissident
cases, since the requirement is for distribution, not modification; but
freedom to redistribute is just as critical as freedom to modify.)

> I think you're overgeneralizing.

I disagree, but again, I hope you're right.

-- 
Glenn Maynard



Reply to: