Re: Results for Debian's Position on the GFDL
On 3/14/06, Glenn Maynard <glenn@zewt.org> wrote:
> (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.)
Ok, but the legal right to modify a work does not mean that you have
the practical ability. More to the point, the GFDL prohibits the use
of technical measures to enforce any of the more obnoxious clauses
of the GFDL.
And, I agree, that's ugly.
> > > 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".
...
> 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.
All you need is a broadly available shim -- for example, something to convert
word format to xml and xml back to word, to make it straightforward to
modify the word document in a generic editor.
Of course, no one has built such a thing, and to my knowledge no one plans
to design such a thing. But it's doable.
As an aside, I edit image files using vi, quite frequently (using it as
a text editor).
Yesterday, for instance, I wanted to document what psuedo-selectors
mean in a cascading style sheet. CSS doesn't support text output,
but it does support background images. So I wound up creating a
few hundred labels as images. A lot of that was done with a script,
but the base image and some of the tests were done using vi as a
generic text editor.
> > 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.
Nevertheless, Debian has not taken the stand that code in debian package
A must be reusable in debian package B.
No one (you included) has even cared to identify subsets of packages
where this is true. And we have some fairly broad subsets where code
is re-usable.
> > > 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.
That won't solve all the reusability issues.
> > > 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.
Nor does it disallow 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 ...)
I don't believe I've ever heard of anyone even suggesting that someone's
right to modify software should be revoked because their changelog
entries (or whatever) are legally ambiguous.
We don't have an equivalent to a notary public in this context, and I think
there's good reasons for that.
--
Raul
Reply to: