The Grumpy Editor's guide to free documentation licenses [LWN.net]

The Grumpy Editor's guide to free documentation licenses

Posted Oct 27, 2004 10:53 UTC (Wed) by jamesh (subscriber, #1159)
In reply to: The Grumpy Editor's guide to free documentation licenses by dlang
Parent article: The Grumpy Editor's guide to free documentation licenses

given the variety of tools and formats available what is easily editable to one person may be completely useless to another person.

The "the preferred form for editing" language in the DSL license seems to cover that. PostScript might be the preferred form for editing certain documents, but if I generate the postscript with tex/dvips it certainly isn't.

This mirrors the case of software, where assembly might be the preferred form for editing for some programs while not being acceptable for other programs.

(Log in to post comments)

The Grumpy Editor's guide to free documentation licenses

Posted Oct 27, 2004 18:02 UTC (Wed) by dlang (subscriber, #313) [Link]

my point is that the prefered form for editing is going to be different for different people on the same document. it's a very nebulous term, far more so then for programs where there's a very obvious difference between source code and the binary result.

if yu had a programming toolchain that had you write your program in language A, run a tool that converted it into fully commented source code for language B, run a second tool that converted it into fully commented source code for language C, and then converted the result into machine code you could concievably prefer to modify the program in language B or C instead of A that the origional author used and it would be a far closer match to the documentation situation

The Grumpy Editor's guide to free documentation licenses

Posted Oct 27, 2004 19:02 UTC (Wed) by bfields (subscriber, #19510) [Link]

my point is that the prefered form for editing is going to be different for different people on the same document. it's a very nebulous term, far more so then for programs where there's a very obvious difference between source code and the binary result.

There are cases where it may not be clear which the preferred form is. There are also very common cases where it is quite clear (you probably don't hand-edit the postscript produced by latex/dvips or the average wordprocessor).

I'm having a hard time seeing how ambituity in the choice of preferred format is likely to cause a real problem in any case--the case we really want to prevent is someone modifying documentation and then claiming they only need provide you with some obfuscated version (nothing but the output of xfig->latex->dvips->ps2pdf for you!), in which case there's not really any ambiguity.

preferred form

Posted Oct 29, 2004 20:37 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Yeah, I've always hated the "preferred form" standard.

What we really want is just to stop someone from withholding the source code that he has as a means of stopping others from building on his work.

The requirement should be that you have to make available what you worked with to make the file you distributed. If you typed in a .o file with a hex editor, the .o is all you have to provide. If you used a special in-house markup language that you machine-translated to latex and then to dvi and then to Postscript that you distribute, you should have to provide the in-house markup on request.