Re: GFDL freedoms
On Thu, Apr 14, 2005 at 03:11:10PM +0100, Matthew Wilcox wrote:
> On Thu, Apr 14, 2005 at 02:41:18AM +0100, MJ Ray wrote:
> > This inherits its definition of Transparent from the FDL, but
> > some DDs consider that awkward. Is there a better one?
> I wasn't aware that people had expressed problems with the definition
> of Transparent; it looked pretty good to me. I thought it better to
> go with terms already in use than invent something of my own, but I'm
> certainly open to suggestions.
It bases the idea of 'transparent' on 'can one edit it with a text
editor or a freely available paint- or drawing-editor,' rather than
looking at the file format specification itself. Aside from the fact
that the current wording completely bypasses anything that isn't text or
a picture (say you're writing a sound editor and want to include some
example sound clips in its manual), I don't think it's a good idea to
define the Freeness of a file format by the Freeness of the editors that
exist for it today -- rather, the Freeness of a file format should be
defined by the Freeness of the editors that /could/ exist for it, if
some people were to get their hands dirty and write an editor.
> > This conflicts with "Derived Works" by denying
> > some modifications (and do most understand that as "permit
> > all reasonable modifications"?)
> I think it's reasonable to deny some modifications. "Derived Works"
> doesn't say "must allow any modifications". Just like the GPL denies
> some freedoms in order to preserve others.
OK, I'll bite. What (interesting) freedoms are preserved by allowing
some section to be invariant? In other words, what makes this so
essential that we want to change our current policy of not allowing
non-modifiable bits in our distribution (with the exception of license
> > and it also contradicts with "No Discrimination Against Fields of
> > Endeavor" because no topic of a secondary section can used as the
> > main purpose.
> I don't think that's an interesting case though. Why would you take a
> document that has nothing to do with a particular subject and turn it
> into a document that has that subject as its main purpose? That seems
> ludicrous to me. Put another way: why is that a freedom you want to have?
Say you're still creating a sound editor. The manual contains a lot of
explanation on how to use the sound editor -- that is its main subject.
Part of the manual is an invariant section that contains a description
of how a Fourier transform is usually done, and how you can't do it in
some 'interesting' and efficient way, because that interesting and
efficient algorithm is patented, and how patents suck, and that people
should please support the 'no software patents' cause. This invariant
section isn't part of the main subject matter -- you don't need to know
how a fourier transform is calculated to be able to use a sound editor,
although the sound editor might want to perform this calculation once in
a while. And to use a sound editor, you don't really need to know what
the mess with software patents is.
Now imagine someone who's doing a study on available algorithms for
Fourier transforms, and wants to pick out parts of the text in the
invariant section to write his paper.
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
-- with thanks to fortune