Re: The draft Position statement on the GFDL
I'm tying a number of loose quasi-threads together here.
On Mon, May 10, 2004 at 08:22:09PM -0400, Anthony DeRobertis wrote:
> (I think we must understand DFSG broadly, not narrowly, otherwise it'd
> allow things like 'you can change this software only for localization
> purposes')
I agree that some of the "DFSG restrictions" are in the mind of the
beholder rather than the text of the DFSG.
That said, DFSG4 would prohibit the above in the context of
anything that is considered source code.
On Mon, May 10, 2004 at 08:56:05PM -0400, Anthony DeRobertis wrote:
> Now, I want to create a derivative work of the GNU Emacs manual to
> advocate free software (look how great emacs is! only free software can
> do this! etc.) I have created a derivative work of the emacs manual, so
> I must include the invariants from the emacs manual. I believe these
> include several FSF and RMS essays about free software and
> documentation.
>
> Essays on free software "could fall directly within [the] overall
> subject" of advocating free software. Section 4(g) and 4(l) says I must
> include them. Section 1 says I must not ("if a section does not fit the
> above definition of Secondary then it is not allowed to be designated
> as Invariant.")
>
> This is quite inconsistent, and I think that probably makes the
> document undistributable. Hence, what I wrote below:
This can be resolved by thinking about the release history of the
document. In other words, the release which made the secondary section
invariant must satisfy the requirements of the secondary section.
In other words, I don't see this restriction as a limit on what can be
placed in the mutable parts of the document.
That said, this issue might be one that RMS is interested in.
On Mon, May 10, 2004 at 09:04:05PM -0400, Anthony DeRobertis wrote:
> Actually, I wasn't thinking of trademarks when I wrote that. The FSF's
> application of the GFDL typically includes A GNU Manual as a front
> cover text and Copies published by the FSF raise funds...
>
> If I modify the manual at all, it's no longer a GNU Manual. Leaving it
> there may be a false designation of origin, in violation of Title 15,
> Sec. 1125.
Why would that be? The FSF still retains copyright on the document.
> > Even if that code includes a class browser and allows introspection
> > into its implementation?
On Mon, May 10, 2004 at 09:07:54PM -0400, Anthony DeRobertis wrote:
> If you're thinking of a specific instance, please bring it up. It's
> much easier to comment on, then.
I don't have a concrete example here, that was hypothetical.
That said, imagine a smalltalk environment which included the usual
smalltalk class browser integrated with a debugger which let you debug at
various levels of abstraction including machine code in memory, on disk,
intermediate or bootstrap c code and smalltalk sources.
Let's also say that this smalltalk implementation was distributed
under a license which allows distribution of the following works:
unmodified originals
smalltalk instances built from unmodified originals which satisfy the test suite
patches to the unmodified originals including the test suite if documented
and made in good faith that the changes are important to the proper
functioning of the smalltalk environment
smalltalk instances built from patched sources which satisfy the patched
test suite
smalltalk applications built on any instances of the above, as long as
they do not also represent attempts to work avoid satisfying the terms
of the license.
[and lets say that the test suite in the unpatched sources verifies
support for browsing and debugging the unpatched sources in various ways.]
> I doubt removing the patch part of DFSG 4 would cause many problems.
How do you quantify "many"?
> > If so, what makes you think that chapters of a BSD manual which
> > incorporates a chapter from a GFDL book must all be licensed under
> > the GFDL?
On Mon, May 10, 2004 at 09:25:00PM -0400, Anthony DeRobertis wrote:
> That doesn't sound like it'd qualify for GFDL 7. Sounds like you'd be
> using Section 5.
In what way would section 7 not be satisfied?
> >>> And, as I said in the message you were responding to, while the GFDL
> >>> approach is unwieldy, it's less so than a "patches only" license
> >>> could be.
> >> Huh? A free patches-only license allows the results of compiling
> >> patched source code to be distributed.
> > And how does this help when what you want to distribute from that
> > program isn't a binary?
> If there is no "build time" then the first sentence of DFSG does not
> apply and that is not a free license. (BTW: DFSG 4 does not use the
> term 'binary'; I assume this is what you mean).
Let's say that the program, as originally created and distributed had
a "build time" and that the work you're trying to create as a result
does not.
Let's say that the work in question allows the distribution of "patch
files" (qualifying under 4) and certain other works built from the
unmodified sources and the patch files.
[As an aside, this is one of the things which has bothered me about the
DFSG from before it was officially released -- that patch files alone
aren't enough, and that we only implicitly require that binaries built
from the sources and patches also be distributable.]
On Mon, May 10, 2004 at 09:26:08PM -0400, Anthony DeRobertis wrote:
> > And we have the same problem with "patches-only" licenses.
>
> How so?
Binaries are a modified form of the sources.
For practical reasons, we wouldn't distribute something if we weren't
allowed to distribute binaries, but other than that the only real
restrictions here are in the rather specialized way we interpret the DFSG.
[Where we wind up arguing based on the implications an interpretation
would have if made fully general rather than on what the DFSG specifically
says.]
Basically, I think the DFSG has to deal with more special cases than it
has sentences, and some significant parts of it remain unwritten.
--
Raul
Reply to: