Re: The draft Position statement on the GFDL
On Tue, May 11, 2004 at 09:33:52AM -0700, Josh Triplett wrote:
> both the freeness and inaccuracy problems. Obviously, if the license is
> not free, it can require you to jump through as many hoops as it wants
> in order to get something you can distribute.
It can, though we might not want to distribute it in some cases.
> >>>Exactly.
> >>
> >>A Free license should allow you to create a derivative work of the
> >>document, instead of just referring to it.
> >
> > It does.
>
> To rephrase: A Free license should allow you to create a derivative work
> of the _entire_ document, instead of just referring to it, without
> having to include unmodified Cover Texts or Invariant Sections (either
> because they are inaccurate or just because they are not modifiable).
My point of view is that "must allow derivative works" isn't completely
general -- that it's fine if there are some kinds of limits on what kinds
of derivations much be allowed. The obvious example is that we have
no right to expect that the license allow the creatition of derivative
works under some arbitrarily different license.
> > Coreutils documentation is not at all structured like a man page.
> > I think it would be better to copy the ideas and not the content.
>
> True, but it should still be possible to copy the content, or the
> license is not Free. Also, you might want to copy _portions_ of the
> content when making the manpage.
I think I understand what you mean, but also don't see that this is a
DFSG issue. There's some basis for this in the social contract, but
probably not as a hard and fast rule.
> Suppose busybox didn't exist, and you were writing it. For your
> documentation, you take the coreutils manual and modify it to document
> your commands, with information about what #defines must be enabled for
> each option to be available. Suppose also that the coreutils manual had
> the standard GNU Cover Texts and a couple of Invariant Sections.
Yeah.
Then again, I'd be much more bothered by the non-modular nature of glibc.
I wouldn't even want support for many kernel calls, let alone much of
the superstructure provided by glibc.
Also, once I'd written busybox, I couldn't really use the gnu
documentation excerpts unchanged, because I'd have made many
simplifications to how things work.
> Apart from those issues, all three are unmodifiable, which violates DFSG3.
Being unmodifiable violates the usual "fully general" interpretation of
the DFSG. Unfortunately, that interpetation isn't really fully general
(and, if carried to the limit, would only allow us to distribute public
domain software).
> > Ok, but where is the language stating this?
>
> Consider what it would mean for a program. A license that required
> derived programs to include a copy of the unmodified program (or a
> specific unmodified portion of the program) in the compiled version of
> the derived program would be obviously non-free. Now s/program/document/g.
And, just as obviously, the interpretation that supports this only
allows software which can be distributed under any license whatsoever
[that's public domain software].
Perhaps it's worth noting that, as it was originally written, the DFSG
did not stand on its own but was a part of the social contract.
--
Raul
Reply to: