documentation

[sambc at nights.force9.co.uk]

>[would you mind wrapping your lines?]

Unfortunately I can only use this email account from my ISPs rather poor webmail ATM. Normal service will be resumed when I get a chance to go home to my own computer (I've only had PC access at work lately).

>The LFS isn't documentation, it's a document trying to suggest a
>standard.  But really, unaffiliated documentation suffers higher
>bitrot - if you keep up, it's because you're working harder.

Linux From Scratch is not a standard... are you confusing it with the FHS?

It is cleatly a document (or documentation) providing instruction on how to build a linux setup from scratch - trust me, I've done it.

And yes, more bitrot is suffered, but that isn't always a problem when things are maintained, or don't change (as I think I said)

>Goodness, I didn't realize it was controversial - it's God's own truth
>to the technical writers I know.

Fine, agreed - but it can be overcome.

>> And in some cases documentation may be distributed as, say, SGML, to
>> be built into a more readable form by the user.
>
>And I would say that's not correct either.

Well, it can happen is all I said - I think saying it's impossible is a bit of a sweeping statement...

>> Further, a good way to implement patch-style updates for docs is used
>> on my sLODL, and in the GNU FDL to a certain extent (last I checked).
>
>Looking at the GNU FDL, I'm not seeing what you mean.

I take it back. I took inspiration from the FDL in terms of invariant sections, but they can't be useful ones in the FDL. If you want to see what I mean I will send you a copy or link to the sLODL. That goes for anyone.

>> but modify with patches is.
>
>For software.  We don't have an OSD for documentation licenses.

The same OSD can cover it, I feel (as do otehrs, it would seem). After all, it's the OSD, not the OSSD.

>The point of documentation is to be read.  If it requires building, it
>needs to be built before the reader gets to it.

Good point (for most readers) - but I'm sure there are some unfriendly peeps out there.

>How do you let someone browsing in IE from work read your derivative
>work?  They can't simply patch the provided documentation from within
>the browser, getting a seamless view of the new work.  You can't patch
>it for them, and distribute it via HTTP.

True. I said patching isn't necessarily a good idea previously.

>He's already stated he's going to distribute it in Word format or PDF -
>how do you patch those, anyways?

with diff and patch, like anything else. They do work on binary files you know (although the diffs are unreadable).

>> and you are in a position to make that judgement?
>
>As much as you are to decide his neeeds *will* be served here.  With
>groups like the LDP and FSF working on free documentation, I think it's
>at least obvious there are *better* venues.

I'm not saying the needs *will* be served here. I am saying they objectively *may* be served, and IMO *should* be served. I do not say will/won't/should/shouldn't absolutely and objectively.

And some people don't much like FSF, and LDP assumes the use of their license statement.

>> this is a list to discuss licensing, why not? I think they woule
>> serve a more clear and present need & purpose than a glut of software
>> licenses...
>
>There's a clear and present need to address the W3C software license.

Fair enough. What about all the other software licenses pending? Could we have a list again please someone, it seems to have been a while...


Sam Barnett-Cormack

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3