While these issues are valid and some are quite problematic, they are not differences between documentation and software. All these things apply equally to software, and would give us just as much trouble if they ever arose for documentation. While the issues themselves are not the subject here, I think this sort of thing should be handled on a casewise basis. Trying to legislate for them would probably not work. Taking them one at a time: On Fri, Aug 22, 2003 at 02:36:03PM -0500, John Goerzen wrote: > There are some properties of documentation that make it a fundamentally > different beast from the software we deal with. Some are: > > 1. Lack of a clear differentiation between source code and compiled form. > > This is, in my opinion, the largest problem with applying DFSG to > software. > > As an example, I worked on a book in LyX, writing most of the code there, > and generating LaTeX code from it to print. Many would say the LyX > document is the source and LaTeX is "compiled", and that I must then > distribute the LyX. > > But after a point, LyX became not versatile enough, so I generated LaTeX > from it, threw out the LyX code, and hacked on the LaTeX from then on. > > As a second example: > > Somebody may take a HTML document, import it into Word, and modify it > there. Is the Word document the new source? What's the compiled one? I can construct exactly the same thing by taking a program written in Haskell, converting it to C, and then compiling the result. Note that this is supported by ghc and not particularly unusual. Or for something more mainstream, how about cfront, the original C++ implementation which translated the input into C? What is the "source code" if I then modify the C version and distribute binaries of the result? > 2. Automated or nearly-automated conversion from one format to another. > Converting, say, a Python program into a C version is not really possible > save by rewriting the entire program. But it's trivial to convert > documentation between all sorts of formats -- and formats that some may > think are hideous (ie, the HTML output from sgml2html or PostScript) > others may see as preferred. This is basically wrong; it is not fundamentally harder to convert program source code than it is documentation. The only appreciable difference is that a small number of documentation formats which are in common use were designed with this in mind, while equivalent programming languages are not currently in common use. I don't think this difference is significant, particularly since there are other documentation systems which are _not_ easy to convert in common use. > DFSG doesn't have any real rule to apply here. Some might cite > "derived works", but if you just reformat it, it's not really derived. > A license could exploit this loophole. Reformatting is most definitely creating a derived work. The term "derived work" is from copyright law, you can't change what it means. > 3. Tool depencies. > Is a document free if it requires non-free software to read? > > Is a document free if non-free software reads it best, but > free software is available to do a "reasonable" job? > > How far does "reasonable" go? > > We have seen this problem with software, for instance with Java-based > software. But there we have a clear idea of whether it works with, > say, Kaffe or not. It's not so clear here. Have you ever tried getting java programs to work with Kaffe? It's not so clear there either. They can fail in odd ways at unexpected moments. Or for a nasty one, try getting java programs to work with gcj. That will break in *really* weird ways on occasion. > If, say, mswordview was > the only option, but it deleted every table in the documentation, is > the documentation still free? What if the java program still works, but attempts to write files to disk fail? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
pgpB0lPUP8kT3.pgp
Description: PGP signature