On 24 July 2013 08:43, Adrian Colomitchi <acolomitchi@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 discussion. 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 software. 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.