Re: Copyright from the lcs-projekt!? [email@example.com: Re: First cut at testing and validation]
David Welton said:
> Have you read RMS' comments regarding documentation? They are, as
> usual, quite relevant and on the mark.
> This is just an excerpt - I think reading the whole thing is a
> valuable use of time, and would recommend it.
> While a blanket prohibition on modification is unacceptable, some
> kinds of limits on the method of modification pose no problem. For
> example, requirements to preserve the original author's copyright
> notice, the distribution terms, or the list of authors, are ok. It
> is also no problem to require modified versions to include notice
> that they were modified, even to have entire sections that may not
> be deleted or changed, as long as these sections deal with
> nontechnical topics. (Some GNU manuals have them.)
> These kinds of restrictions are not a problem because, as a
> practical matter, they don't stop the conscientious programmer from
> adapting the manual to fit the modified program. In other words,
> they don't block the free software community from doing its thing
> with the program and the manual together.
> However, it must be possible to modify all the technical content of
> the manual; otherwise, the restrictions do block the community, the
> manual is not free, and so we need another manual.
In other words, restrictions on modifiability are OK if they allow
programmers to keep the program and manual in sync. Since the
programmer can modify the program, he/she should be able to modify the
manual to at least the extent necessary to make the manual reflect the
program. RMS's exact rationale is given in the two paragraph
immediately preceeding the three you quoted:
As a general rule, I don't believe that it is essential for people to
have permission to modify all sorts of articles and books. The issues
for writings are not necessarily the same as those for software. For
example, I don't think you or I are obliged to give permission to
modify articles like this one, which describe our actions and our
But there is a particular reason why the freedom to modify is crucial
for documentation for free software. When people exercise their right
to modify the software, and add or change its features, if they are
conscientious they will change the manual too--so they can provide
accurate and usable documentation with the modified program. A manual
which forbids programmers to be conscientious and finish the job, or
more precisely requires them to write a new manual from scratch if
they change the program, does not fill our community's needs.
This unfortunately doesn't address technical documents that don't
relate to specific pieces of software. Since the stand on free
software documentation is pragmatic (what is best for our community),
not ideological (immutability is bad), how we deal with
non-software-specific technical documents should also be equally
pragmatic (whatis best for our community), rather than ideological.
My personal opinion is that for most non-software-specific technical
documents, requiring modifiability would not benefit our community, and
for some, it would even be detrimental.
I plan on writing RMS and soliciting his opinion on the matter. I'll
Buddha Buck firstname.lastname@example.org
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice