On 24 July 2013 08:43, Adrian Colomitchi <acolomit...@gmail.com> wrote:

> d. use the documentation to "sing it" (make a musical arrangement and
> transform it in an 10-hours boring opera; or "transpile" the letters or
> words in the documentation on notes/rhythm/instruments somehow and
> distribute it as a sheet music)

I would like to see an example of somebody doing this!

More seriously though, I think we may have lost the point of this

If I change an open source program, chances are the original documentation
no longer applies any more. So I really should be updating the
documentation too. If however there are barriers to updating the
documentation, e.g. for some misconceived reason the copyright owner
decided to make that part invariant, then I won't update it. The best I
could do is attach an amendment to the documentation, which isn't in the
best interests of the end user - they have to read the documentation, and
then the amendments just to try and work out how to use my version of the

The same arguments have been made with RFC documents. I might want to
create a new standard that is based on an existing standard - giving it a
new name of course, but as most RFCs restrict making changes, I can't
legally do that.

Another common example given on the Debian mailing lists is if I want to
produce a condensed version of the documentation, e.g. one that will fit on
a single A5 sheet of paper for example. It may not be possible if I have to
include invariant sections.

It really doesn't matter if it is software or documentation or some
combination of the two. What matters is if it restricts my freedoms to
innovate and try new things. I think invariant sections of the FDL does
just that.

PS. You can start by singing this email.
Free-software-melb mailing list

Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/

Reply via email to