Re: The draft Position statement on the GFDL
On May 10, 2004, at 22:22, Raul Miller wrote:
On Mon, May 10, 2004 at 08:22:09PM -0400, Anthony DeRobertis wrote:
[SNIP. Some stuff about possible problems with invariant sections
needing to be secondary, in face of topic changes]
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 is probably what is intended; however, it's not (AFAICT) what's
written.
That said, this issue might be one that RMS is interested in.
Personally, I think just about everything that keeps "GFDL with no
invariant sections, front or back cover texts, etc." from being free is
a bug. I just wish that the FSF would either clarify why those apparent
bugs are there, or fix them.
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.
The FSF only retains copyright on the document if I assign that
copyright to them. Otherwise, I retain the copyright on my portion.
(Think of me doing a substantial modification, not fixing a few typos).
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 would not find this a free license. The most non-free part of it,
IMO, is that I can't make changes that not "important to the proper
functioning of the smalltalk environment." Patches that, for example,
changed the language from Smalltalk to Python would not be allowed.
Second, I'd object to the requirement to keep the test suite up-to-date.
I doubt removing the patch part of DFSG 4 would cause many problems.
How do you quantify "many"?
I confess I have not done a count or even taken samples; that is just a
'gut feeling' from experience with examining licenses on this list and
seeing many of the licenses used in Debian.
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.
That's definitely a downside of that type of license: You can't.
(Though, for debian, this isn't a problem because we always have a
build time)
[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.]
We explicitly require that they are distributable. DFSG 4: "The license
must explicitly permit distribution of software built from modified
source code."
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.
DFSG 2 requires that we be able to distribute "compiled form."
Basically, I think the DFSG has to deal with more special cases than it
has sentences, and some significant parts of it remain unwritten.
That's quite possible.
Reply to: