| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
The Grumpy Editor's guide to free documentation licenses
The Grumpy Editor's guide to free documentation licenses
Posted Oct 27, 2004 1:47 UTC (Wed) by dlang (subscriber, #313)Parent article: The Grumpy Editor's guide to free documentation licenses
one term that you used frequently that I see as an issue is the refernce to an 'editable format'
given the variety of tools and formats available what is easily editable to one person may be completely useless to another person.
I've been known to create postscript files directly from vi for example, many people would not consider .ps files editable, but the content may not exist in any other format.
I agree that the idea of making a document unable to be modified makes it less useful, but at the same time I don't believe that all documents should need to be modified (exerpts pulled from them possibly, but not the same document modified) an example of documents in this class are the internet RFC's. there are all sorts of reasons to use parts of them in other documents, but absolutly no reason for anyone to modify a document and call it RFC3501 for example.
(Log in to post comments)
The Grumpy Editor's guide to free documentation licenses
Posted Oct 27, 2004 10:53 UTC (Wed) by jamesh (subscriber, #1159) [Link]
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.
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.