sambc at nights.force9.co.uk
sambc at nights.force9.co.uk
Wed Aug 29 10:36:03 UTC 2001
>[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
>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...
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
More information about the License-discuss