Re: documentation
My inflationary three cents. Matthew C. Weigel replied to SamBC: I don't think I've seen where you addressed how the copyright notice on the GPL is not hypocritical. Unless he agrees that it is OK for licenses and software documentation to be held to different standards, 1. The GPL is not software documentation. 2. I doubt that software licences, considered as creative works, can really be fairly considered to be in the same conceptual category as general-usage software. 3. Anyone who seriously desires to effectively fork a licence need only rephrase it, apply a new name, and revise as desired. The amount of reinvention entailed would not be much compared to writing a replacement codebase. (In an academic context, it would be plagiarism, but such is not barred elsewhere, and is not to be confused with copyright violation.) Logically, your charge of hypocrisy would need to be accompanied by some showing that the accused claimed his values and goals must apply to creative works that are not themselves software. Which showing you have notably omitted -- possibly because you're aware that the GPL's author has never made such claims? The more sadly cynical among your readers might be led to suspect flamebaiting. -- Cheers, Rick MoenPotestatem capite! [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: documentation
-Original Message- From: Matthew C. Weigel [mailto:[EMAIL PROTECTED]] Sent: 29 August 2001 21:37 On Wed, 29 Aug 2001, SamBC wrote: How about the title? I'm not saying that the general principles don't apply to free documentation - I'm saying that the exact set of trade-offs, made with an eye towards bringing the principles into the real world, were developed specifically for the 'real world' of software. Therefore, the principles behind the FSG and OSD still apply, but the FSG and OSD themselves do not. You can certainly hold documentation to them, but that was not their intent. They still work as guidelines, which is after all all they are. For instance, would 4. Integrity of The Author's Source Code (either one) mean that you could distribute modified PDFs of a patch-only document (since PDF is definitely not the form of choice for editing documents, and should probably qualify for being a binary), but not TeX? What about HTML - should it be considered a binary form that you can distribute modified, or a source form that you can restrict to patches-only? I guess so - after all, TeX is not a viewing-friendly format. Things like HTML make life more difficult, and would have to be a per-license matter, with each document having a specific 'source form' - in something like TeX or SGML. No reason diff shouldn't still work. A lot of gnu stuff has been ported, and note mingw and cygwin, if people really want. But here we're debating technicalities, as we agree in principle that patches aren't good for docs. Yes. If we started with the assumption that printout was the final output, akin to binary executables, they would be fine - you'd download the source in, for example, TeX, apply the patches included with your version of the software, and print it out. But, most documentation is now viewed online, in 'raw' formats like HTML or nroff. What's more, you have - between HTML, man2html.cgi, and PDF plugins - the ability and motivation to distribute modified documents willy nilly. Or apply the patches and then render into a more widely viewable format. These questions have many possible answers usually applicable to a smaller range of cases There's a slim chance someone in the OSI is reading this, or your responses to it (at least the new webmaster hasn't killfiled me). Perhaps someone can explain why it *hasn't* been approved? Shouldn't it be a priority, so that the much-respected W3C can get a spot on sourceforge.net? They haven't listened yet... I hold out little hope. SamBC -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: documentation
[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
RE: re: documentation
In Europe at least, software under patent is legal fact, not opinion. Software processes are not patentable except as a part of an overall non-software process - each case seperately considered. See what I wrote above - *should* software methods be patentable... In Europe, there's a legal decision, which has no bearing on individual decisions. Just like everywhere else. Yes, you can ave an opinion, but it will do no good. In europe you cannot patent an entirely software process, nor can you patent an algorithm (as all algorithms are deemed to be natural) - you can patent implementations of algorithms, but not if they are software. IANAL, but I have looked into this deeply and spoken to people who AAL. Sam Barnett-Cormack -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: documentation
On Wednesday, August 29, 2001, at 06:26 AM, [EMAIL PROTECTED] wrote: I have to see that it's a matter of opinion. OSI Certification Mark applies only to software packages. Doesn't say anything that OSI only cares about software full stop. I guess we're reading it differently - dedicated to . . . the OSD, specifically through the . . . certification mark. . . . I have to say he seems to have misconceptions about simple copyright statements and more complex licenses (IANAL) - however, you reacted in entirely the wrong way, repeating yourself rather than refuting his new points correctly. Then please, help me out - since he apparently thinks I started mudslinging, and is ignoring me, say how *you* think he's wrong. All I can think of to say is, it's obvious upon examination that licenses are not themselves free. I think you took things too personally. You should've looked at his reasoning, seen it was wrong, and corrected it. I tried. Hypocrite is one of the few things I take seriously - and its use was not warranted. Not for me, and not for the entire group of license-discuss participants. If he'd called me a sicko communist pig-spanker, I'd be all sweetness and light. As for his reasoning, I once again enjoin you to address its problems. Secondly, the OSI does not specify that only software *licenses* are covered, merely that they only certify software products. You are reading into that in a possibly incorrect way. It says open-source software must. There is nothing to make anyone think that open-source documentation must or should pay any attention to it. While I don't think it's intended to specifically exclude documentation, I think it *is* intended to specifically address software. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: documentation
On Wednesday, August 29, 2001, at 06:36 AM, Linux From Scratch is not a standard... are you confusing it with the FHS? Hmm. Yes. I've never heard of Linux From Scratch. 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. Sure. The same OSD can cover it, I feel (as do otehrs, it would seem). After all, it's the OSD, not the OSSD. It started life as the Debian Free Software Guidelines. It was never put through any consideration for covering the slightly different world of documentation. It is ill-considered to tack on new duties. 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. Errr... peeps? Surely marshmallow cremes aren't too unfriendly... True. I said patching isn't necessarily a good idea previously. Obviously, I think it's worse than not just a good idea for documentation. 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). *In Windows*? What about MacOS? 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. The LDP does not assume the use of their license statement. They specify a set of requirements which must be met for distribution, and offer their default boilerplate as an example. Having spent more time thinking about these issues, and having a clear purpose to develop unaffiliated documentation, they are probably more appropriate. There is, as I have said, a case to be made for getting the OSI to look into documentation. It can not be made by him, with the arguments he has tried so far. 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... None of the other licenses have been waiting, what was it at last count, 13 months? None of the other licenses have already long ago received approval from the FSF as free software licenses, indicating that - since they're more restrictive - there should be no problems approving it here. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: documentation
-Original Message- From: Matthew C Weigel [mailto:[EMAIL PROTECTED]] Linux From Scratch is not a standard... are you confusing it with the FHS? Hmm. Yes. I've never heard of Linux From Scratch. http://www.linuxfromscratch.org/ - have a look, it's very good, and very effective. The same OSD can cover it, I feel (as do others, it would seem). After all, it's the OSD, not the OSSD. It started life as the Debian Free Software Guidelines. It was never put through any consideration for covering the slightly different world of documentation. It is ill-considered to tack on new duties. Point me at the bits which make a problem, aside from cases of obvious intelligent reinterpretation... Good point (for most readers) - but I'm sure there are some unfriendly peeps out there. Errr... peeps? Surely marshmallow cremes aren't too unfriendly... peeps = people. An irritating shortening I picked up somewhere a while back. Obviously, I think it's worse than not just a good idea for documentation. Different degrees of opinion, but we agree essentially 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). *In Windows*? What about MacOS? No reason diff shouldn't still work. A lot of gnu stuff has been ported, and note mingw and cygwin, if people really want. But here we're debating technicalities, as we agree in principle that patches aren't good for docs. And some people don't much like FSF, and LDP assumes the use of their license statement. The LDP does not assume the use of their license statement. They specify a set of requirements which must be met for distribution, and offer their default boilerplate as an example. Having spent more time thinking about these issues, and having a clear purpose to develop unaffiliated documentation, they are probably more appropriate. Presumably changed since I last looked. It was a while ago, but they said 'click here for license information for all LDP docs' or something equivalent... There is, as I have said, a case to be made for getting the OSI to look into documentation. It can not be made by him, with the arguments he has tried so far. Fine, and I'll join this with anyone else - who else is interested? 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... None of the other licenses have been waiting, what was it at last count, 13 months? None of the other licenses have already long ago received approval from the FSF as free software licenses, indicating that - since they're more restrictive - there should be no problems approving it here. I agree this is pathetic, especially with the standing of W3C online... but what can we do? Sam Barnett-Cormack -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: documentation
-Original Message- From: Matthew C Weigel [mailto:[EMAIL PROTECTED]] On Wednesday, August 29, 2001, at 06:26 AM, [EMAIL PROTECTED] wrote: I guess we're reading it differently - dedicated to . . . the OSD, specifically through the . . . certification mark. . . . You can always twist meanings that way. Proves nothing other than, as you say, we read it differently. Then please, help me out - since he apparently thinks I started mudslinging, and is ignoring me, say how *you* think he's wrong. All I can think of to say is, it's obvious upon examination that licenses are not themselves free. Well, you did start the mudslinging, but not entirely inappropriately IMHO. You just both calm down, be mature, and forgive each other. It seems the points have mostly been cleared up. I tried. Hypocrite is one of the few things I take seriously - and its use was not warranted. Not for me, and not for the entire group of license-discuss participants. If he'd called me a sicko communist pig-spanker, I'd be all sweetness and light. I think you took it too personally. He didn't mean you, he meant the whole principle, and but for one misconception was justified. Let it go, I say. As for his reasoning, I once again enjoin you to address its problems. I think I have. Secondly, the OSI does not specify that only software *licenses* are covered, merely that they only certify software products. You are reading into that in a possibly incorrect way. It says open-source software must. There is nothing to make anyone think that open-source documentation must or should pay any attention to it. While I don't think it's intended to specifically exclude documentation, I think it *is* intended to specifically address software. as I say in another email, obvious rewording sorts out all the probs I can see... SamBC -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: documentation
On Wed, 29 Aug 2001, SamBC wrote: It started life as the Debian Free Software Guidelines. It was never put through any consideration for covering the slightly different world of documentation. It is ill-considered to tack on new duties. Point me at the bits which make a problem, aside from cases of obvious intelligent reinterpretation... How about the title? I'm not saying that the general principles don't apply to free documentation - I'm saying that the exact set of trade-offs, made with an eye towards bringing the principles into the real world, were developed specifically for the 'real world' of software. Therefore, the principles behind the FSG and OSD still apply, but the FSG and OSD themselves do not. You can certainly hold documentation to them, but that was not their intent. For instance, would 4. Integrity of The Author's Source Code (either one) mean that you could distribute modified PDFs of a patch-only document (since PDF is definitely not the form of choice for editing documents, and should probably qualify for being a binary), but not TeX? What about HTML - should it be considered a binary form that you can distribute modified, or a source form that you can restrict to patches-only? Good point (for most readers) - but I'm sure there are some unfriendly peeps out there. Errr... peeps? Surely marshmallow cremes aren't too unfriendly... peeps = people. An irritating shortening I picked up somewhere a while back. Then I guess I don't understand what you're saying. *In Windows*? What about MacOS? No reason diff shouldn't still work. A lot of gnu stuff has been ported, and note mingw and cygwin, if people really want. But here we're debating technicalities, as we agree in principle that patches aren't good for docs. Yes. If we started with the assumption that printout was the final output, akin to binary executables, they would be fine - you'd download the source in, for example, TeX, apply the patches included with your version of the software, and print it out. But, most documentation is now viewed online, in 'raw' formats like HTML or nroff. What's more, you have - between HTML, man2html.cgi, and PDF plugins - the ability and motivation to distribute modified documents willy nilly. Presumably changed since I last looked. It was a while ago, but they said 'click here for license information for all LDP docs' or something equivalent... See 5. License Requirements at www.linuxdoc.org/manifesto.html. I agree this is pathetic, especially with the standing of W3C online... but what can we do? There's a slim chance someone in the OSI is reading this, or your responses to it (at least the new webmaster hasn't killfiled me). Perhaps someone can explain why it *hasn't* been approved? Shouldn't it be a priority, so that the much-respected W3C can get a spot on sourceforge.net? -- Matthew Weigel Research Systems Programmer [EMAIL PROTECTED] ne [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: documentation
Is it not plausible, though, that some documentation is outside a piece of software and yet still of interest to the Open Source software community? Not as a primary topic of discussion, no. Unaffiliated documentation suffers from bitrot at a much higher rate than affiliated documentation (and how often do you find out-of-date man pages in Linux?). accepted as true, but not necessarily universal or true (LFS being a good example) Like linuxdocs, there is much documentation like HOWTOs outside of software projects. And, for the most part, they document how the software used to be. For the most part, perhaps. But some documentation is outside software, which FSF seem to recognise in their (not very good IMHO) FDL. Yeah, but the main drive and interest is affiliated software. but there can be such a thing as good, well-maintained documentation which remains valid despite being outside a sfotware package, through two methods: 1) the author or others continue to maintain it. 2) it's about something so universal it doesn't change for years and years. 1) Source can be quite difficult to interpret 2) Not everyone is that capable. Then why does open source matter? I hope this is still a joke. Opensource matters for lots and lots of reasons, and being able to look at the source isn't the key one. Being able to modify it in some way is important, as are the none-source-specific parts of the OSD, such as redistribution. I am currently employed as a programmer, and my code will be left when I finish this job for others to maintain. So it needs to be clear. I need documentation on two levels as well as this to make it clear as glass - for developers, and for users. Documentation other than the source will *always* be needed. And should you be the one to write the documentation, or a third party? I should do essential documentation, and if anyone else feels the urge to do an in-depth analysis of techniques, or write a d.a.d.s. tutorial, that's all to the good. Well, the QPL was approved by OSI wasn't it? There's a significant difference between being able to distribute pristine source+patches versus pristine documentation+patches. One would normally expect to have to build source. And in some cases documentation may be distributed as, say, SGML, to be built into a more readable form by the user. 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). What if they hack Perl up, and distribute their own version. Obviously they want to help people out by giving away documentation as well, but now their version can't be as well documented as the pristine version of Perl without a lot of extra effort on their part (or a little non-obviousness for the reader). True, but aside from the point. Not in the least aside from the point! This is why the software and documentation needs to be licensed together - so that any changes you can make to the code, you can reflect in documentation. absolutely. so the external docs someone writes should say written to work with version x.y.z.blahblah - functionality with other versions may vary. No-modify licenses simply aren't free or open. but modify with patches is. I provided two suggestions - but I still don't think his needs will be served by us. and you are in a position to make that judgement? They would be useful, but I don't think that they are vital, nor relevant here. 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... SamBC
RE: Re: documentation
Can we have an answer from the OSI board as to the applicability of the OSD to documentation licenses before anything is put on the web pages please? It seems a contentious issue, as non-package documentation seems quite key to the world of open source. SamBC
re: documentation
Matthew C. Weigel wrote: On Mon, 27 Aug 2001 [EMAIL PROTECTED] wrote: What do you call a rant about how hypochritical us poor license-discuss folks are, ignoring virtually everything I said? If you're not out to save us, then you're just trying to show how smart you are. Oops. I never used the word poor. I DID use the word hypocrite. hypocrite: someone pretending to believe something they don't. yes, I said it seemed hypocritical to say OSI supports open-source yet it does not support open documentation, which is part and parcel of software. I still stand by that statement. Matthew's version of OSI's commitments: OSI supports open-source software through software licenses only. OSI does not support open documentation. If you want an open license for documentation, please note that open documents are not part of OSI's commitment. Go away. Whether this is OSI's commitment or not, I don't know. but this is your assertion of how OSI should operate. I also find it hypocritical that GPL has 1) a no-modify license, 2) that it's a document license, but that you reserve that style of license for GPL only, and you would not allow such a license, as a stand-alone entity. Which is to say, my agenda is to get on with the OSI's agenda. Whether OSI would prohibit a no-modify, open document license, I don't know. But I know you would not allow it if left to you. I'm not yet convinced that you are in line with OSI's commitment. There's a significant difference between being able to distribute pristine source+patches versus pristine documentation+patches. I see no need to draw a hard line between source and documents. All you do is exclude things that could otherwise be for the good of the open software community. My agenda here is to move you out of the way so that more relevant things can be discussed, or I can get back to work. you can now save yourself the time and effort of replying and simply get back to work. consider yourself ignored. You have nothing to say that is of use to my commitments. one final note: rant: to speak or shout in a loud uncontrolled or angry way I never ranted. I never sunk to the level of name-calling. I have yet to shout or get angry. I have not resorted to sarcasm. I have finally come to the point of dismissing you offhand. but you sir, are no gentleman. Greg London When a man assumes a public trust, he should consider himself as public property. -Thomas Jefferson
Re: Re: documentation
On Tuesday 28 August 2001 12:17, [EMAIL PROTECTED] wrote: Can we have an answer from the OSI board as to the applicability of the OSD to documentation licenses before anything is put on the web pages please? The webpage was only changed (actually only italicized[sp?]) to reflect that the *OSI cert mark* applies only to software: http://opensource.org/docs/certification_mark.html Nothing to do with the OSD has been altered. -- Steve Mallett | Just Stable, Open-Source Apps http://OpenSourceDirectory.org | [EMAIL PROTECTED] Project-Listing Maintenance In A Can: http://trovesendtwo.sf.net [EMAIL PROTECTED] (Aug 15th/01, I have nothing to do with license approval.) Non-cooperation with evil is as much a duty as cooperation with good. -- Mohandas Gandhi -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
re: documentation
John Cowan wrote: You keep ignoring the QPL and the Artistic License, ah, constructive help is so refreshing ;) thank you. someone did mention the QPL license earlier. I looked at it, but my concern is that it uses the word software everywhere. I was looking at licensing a MSWord document or PDF file. If that format is not considered software, then the entire license might not apply. I am not a lawyer, so I'm not sure if its a problem. There's also the notion of patches in QPL, and that could be widely interpreted when applied to a Word document. or the license might be voided if Word doesn't allow patches in the software sense. Even though there might be a document based way of doing ammendments or something similar. if its not a problem, then I'll just use QPL. (ok, and that bit at the end saying Disputes shall be settled by Oslo City Court. created visions of long flights to snow covered court rooms just to straighten out a legal issue.) b... ;) I've considered writing the document as a perl program, such that the program dumps the text to the screen. And then license the program as QPL. That might be an option, but then I lose any formating information and images that may have been in the Word document. as far as Artistic License goes, it has the same problems by refering to software. Plus, isn't it pretty much agreed that it's a shaky license? I know they're intending on rewriting it for Perl 6. and everyone else keeps ignoring the fact that you mean to allow patches. oh, you've noticed that too. ;) given OSI's approval process is so long, I don't think a new license would get approved in time to be of use to me anyway. which is pushing me in the direction of writing it as a perl program of some sort, and then licensing the program under QPL. I'll just have to deal with any images and formating issues somehow. perl/tk can handle jpegs, I think, so that will fix that problem. and the Text widget can create columns, etc. It'll just be a whole bunch of extra work to do the conversion. Also, not everything in Perl/Tk had a print method, (at least when I was contributing code to the Perl/Tk effort) which means it might be some hoop jumping to get a printable version of the document. I don't know if all the perl GUI widgets have print methods now or not. That might have changed. And all of this just because there's no license for Word documents, PDF's, etc. Rather than simply have a documentaion license, I have to do a bunch of work to make my document look like software so I can license it with an OSI approved license. It just seems odd to me. Greg London -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: re: documentation
You speak as if you have some authority over this list, demanding that people go elsewhere? Do you represent OSI? If so, it really should say so in your sig (included below)... I therefore assume that you do not, and ask that you be more polite. You have not reacted to anyone's points, merely reiterated your previous points. SamBC -- Matthew Weigel Research Systems Programmer [EMAIL PROTECTED] ne [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
re: documentation
Rob Myers wrote: [EMAIL PROTECTED] wrote: someone did mention the QPL license earlier. I looked at it, but my concern is that it uses the word software everywhere. If the license isn't copyrighted, just search replace. I just checked. QPL is copy/distribute/no-modify. Or define the software to be your document. uh, I didn't know you could do that. I don't like redefining a word to mean something else. reminds me too much of Humpty Dumpty. But if it's legally acceptable, then that would work. there wouldn't happen to be a lawyer on the list, would there? as far as Artistic License goes, it has the same problems by refering to software. Plus, isn't it pretty much agreed that it's a shaky license? I know they're intending on rewriting it for Perl 6. There's a revised artistic license available that addresses the concerns IIRC. ah, new information. I thought it was coming out with perl 6, which is a year or two before it sees the light of day. I'll look into it. Thanks, Greg London -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: documentation
On Tue, 28 Aug 2001 [EMAIL PROTECTED] wrote: [would you mind wrapping your lines?] Not as a primary topic of discussion, no. Unaffiliated documentation suffers from bitrot at a much higher rate than affiliated documentation (and how often do you find out-of-date man pages in Linux?). accepted as true, but not necessarily universal or true (LFS being a good example) 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. Goodness, I didn't realize it was controversial - it's God's own truth to the technical writers I know. 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. 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. No-modify licenses simply aren't free or open. but modify with patches is. For software. We don't have an OSD for documentation licenses. The point of documentation is to be read. If it requires building, it needs to be built before the reader gets to it. 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. He's already stated he's going to distribute it in Word format or PDF - how do you patch those, anyways? I provided two suggestions - but I still don't think his needs will be served by us. 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. 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. -- Matthew Weigel Research Systems Programmer [EMAIL PROTECTED] ne [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: documentation
-Original Message- From: David Johnson [mailto:[EMAIL PROTECTED]] SNIP The OSI does not approve documentation licenses, only software licenses. Is this mentioned anywhere on the OSI webpages? I ask only because this may explain the lack of any action for a particularly long period of time on a license I submitted... I will debate the appropriateness of this policy in a separate email. Most free documentation licenses are quite complicated and convoluted. This is primarily due to the fact that they are trying to make them as free/open as possible without risking the work's or author's artistic integrity. By requiring derivations to be distributed as patches, you can cut through a lot of this clutter, and end up with a simple license if you work it right. My license (sLODL) is IMHO a reasonable starting point as well (despite lack of OSI approval). Should be at http://www.simplelinux.org/legal/sLODL.html - but the entire website seems to have vanished... anyone can mail me if they want a copy and I'll send them one. Sam Barnett-Cormack
re: documentation
Matthew C. Weigel wrote: On Sun, 26 Aug 2001, Greg London wrote: If OSI has a commitment to furthering open source software, then a documentation license would greatly advance open soure. What good is software if you don't know how to use it? You've got the source, why don't you know how to use it? ;-) a dismissive statement, hiding behind backhanded humor. I run a perl training, part time, where I work. Everyone in my class wants to learn perl. why did they bother coming to me when they could just read the source code and figure it out for themselves? Because not everyone spends every waking moment of their life eating and breathing code. They want to use it to get their job done, but they want to spend time with their husbands and kids when they get home. I would like to write a Teach Yourself Perl kind of document and license it so that it is freely copiable and freely distributable. But I don't want people to modify my document and redistribute it How would that be open source, if people can't modify it? More specifically, why would the OSI or the FSF care about it, if it's contrary to their goals? I find it interesting, almost like I've stepped into a world of group-self-deception, bordering on hypocricy, that GPL as a document is licensed as copy/distribute/no-modify. But every response (so far at least) to a request for a license that codifies copy/distribute/no-modify has dismissed the request. The responses so far regarding a copy/distribute/no-modify license have said that such a license would: 1) not be open source 2) not further OSI's commitment to open-source 3) have no value to the rest of the world 4) would condemn it's document to instant out-of-dateness. Yet, the GPL license, as a document itself, licensed as copy/distribute/no-modify, is: A) considered the granddaddy of all open-source movements B) at teh top of OSI's list of open source licenses C) widely by programmers to license their software D) up-to-date, and was even released with a new version number You're only fooling yourselves if you assert 1-4, since I've seen the evidence to the contrary in A-D. What I'm hearing is that open-source MUST REQUIRE a copy/distribute/modify license, except for : the license that licenses the license. At which point, you need to switch to a copy/distribute/no-modify license, just for that little part. And then kid yourselves that you didn't pull a fast-one. So, I'm calling you on your conjuring trick. You wave your hands and say yeah, but that part's different. You cast a spell that say open source must be able to modify its text, but an exception to the rule is acceptable for our own licenses. And I'm telling you that Open-Source can embrace both. A General Public License (GPL) that says copy/distribute/modify and a General Document License (GDL) that says copy/distribute/no-modify. I'm telling you that Open-Source ALREADY embraces both, since GPL is licensed under GDL. It's not a big deal. It's already there. I'm just asking that it (GDL) be made a separate license (rather than rolled into the GPL) so that I can use the GDL in _my_ document. It's good enough for GPL to use the GDL, so it's good enough for me. And you're all running around like I'm going to bring fire and brimstone down from out of the sky. cats and dogs living together... total chaos... relax people, it'll be OK. It already **IS** OK. Greg Put the license down, and slowly move away from the keyboard!
RE: documentation
-Original Message- From: Matthew C. Weigel [mailto:[EMAIL PROTECTED]] Yes. And it's that subset that is of interest to the Free SOFTWARE and Open Source SOFTWARE community. Not the set of documents specifically outside that subset. Is it not plausible, though, that some documentation is outside a piece of software and yet still of interest to the Open Source software community? Like linuxdocs, there is much documentation like HOWTOs outside of software projects. True. Which is why people like RMS hold the opinion that the documentation is part of the software, to be held under the same license, or a similar license. But some documentation is outside software, which FSF seem to recognise in their (not very good IMHO) FDL. You've got the source, why don't you know how to use it? ;-) I would assume this is a joke, but I'll refute it anyway. 1) Source can be quite difficult to interpret 2) Not everyone is that capable. If open source eschews the political and philosophical issues of free software, then the biggest reason to use open source software is to have the source. Someone who plans on maintaining their code will need to make it pretty clear anyways. The software should be the documentation, but not in a bad way. No, no no! Software *always* needs documentation. I am currently employed as a programmer, and my code will be left when I finish this job for others to maintain. So it needs to be clear. I need documentation on two levels as well as this to make it clear as glass - for developers, and for users. Documentation other than the source will *always* be needed. Besides, some of the issues open source holds dear are the same as those of free software, but for practical reasons, not philosophical or political ones. I would like to write a Teach Yourself Perl kind of document and license it so that it is freely copiable and freely distributable. But I don't want people to modify my document and redistribute it (i.e. remove any references that it was my document), or roll it into a larger document and hide my name, or cut and paste parts of it into a hardcopy book and sell it. How would that be open source, if people can't modify it? More specifically, why would the OSI or the FSF care about it, if it's contrary to their goals? Well, the QPL was approved by OSI wasn't it? What if they hack Perl up, and distribute their own version. Obviously they want to help people out by giving away documentation as well, but now their version can't be as well documented as the pristine version of Perl without a lot of extra effort on their part (or a little non-obviousness for the reader). True, but aside from the point. I agree with the arguments of the previous poster - I will not post them again. I suggest documentation licenses (for standalone documentation outside of a piece of software) are vital, with a similar level of variety to the range of software licenses. They should be separate to deal with these specific issues. A BSD-style one is not necessary, as the BSD license will do (I believe). However, ones similar to each of GPL, LGPL, and QPL would be a good start. My two penn'orth Sam Barnett-Cormack
Re: documentation
Greg London wrote: David Johnson wrote: The OSI does not approve documentation licenses, only software licenses. Greg, There are some other open source or free documentation licenses. One place to look is http://www.gnu.org/licenses/licenses.html#FDL. There is also something like an open content license somewhere. As usual, there is some contoversy about which licenses are free, etc. Randy Kramer
RE: documentation
On Mon, 27 Aug 2001, SamBC wrote: Yes. And it's that subset that is of interest to the Free SOFTWARE and Open Source SOFTWARE community. Not the set of documents specifically outside that subset. Is it not plausible, though, that some documentation is outside a piece of software and yet still of interest to the Open Source software community? Not as a primary topic of discussion, no. Unaffiliated documentation suffers from bitrot at a much higher rate than affiliated documentation (and how often do you find out-of-date man pages in Linux?). Like linuxdocs, there is much documentation like HOWTOs outside of software projects. And, for the most part, they document how the software used to be. True. Which is why people like RMS hold the opinion that the documentation is part of the software, to be held under the same license, or a similar license. But some documentation is outside software, which FSF seem to recognise in their (not very good IMHO) FDL. Yeah, but the main drive and interest is affiliated software. You've got the source, why don't you know how to use it? ;-) I would assume this is a joke, but I'll refute it anyway. 1) Source can be quite difficult to interpret 2) Not everyone is that capable. Then why does open source matter? to make it pretty clear anyways. The software should be the documentation, but not in a bad way. No, no no! Software *always* needs documentation. See my reference about literate programming. And I do agree - I've already indicated that I think documentation should be part of the project. I am currently employed as a programmer, and my code will be left when I finish this job for others to maintain. So it needs to be clear. I need documentation on two levels as well as this to make it clear as glass - for developers, and for users. Documentation other than the source will *always* be needed. And should you be the one to write the documentation, or a third party? How would that be open source, if people can't modify it? More specifically, why would the OSI or the FSF care about it, if it's contrary to their goals? Well, the QPL was approved by OSI wasn't it? There's a significant difference between being able to distribute pristine source+patches versus pristine documentation+patches. One would normally expect to have to build source. What if they hack Perl up, and distribute their own version. Obviously they want to help people out by giving away documentation as well, but now their version can't be as well documented as the pristine version of Perl without a lot of extra effort on their part (or a little non-obviousness for the reader). True, but aside from the point. Not in the least aside from the point! This is why the software and documentation needs to be licensed together - so that any changes you can make to the code, you can reflect in documentation. No-modify licenses simply aren't free or open. I agree with the arguments of the previous poster - I will not post them again. I provided two suggestions - but I still don't think his needs will be served by us. I suggest documentation licenses (for standalone documentation outside of a piece of software) are vital, with a similar level of variety to the range of software licenses. They should be separate to deal with these specific issues. They would be useful, but I don't think that they are vital, nor relevant here. -- Matthew Weigel Research Systems Programmer [EMAIL PROTECTED] ne [EMAIL PROTECTED]
re: documentation
On Mon, 27 Aug 2001 [EMAIL PROTECTED] wrote: You've got the source, why don't you know how to use it? ;-) a dismissive statement, hiding behind backhanded humor. That's right. Dismissive of the attitude that the software itself should not provide adequate documentation. You've apparently written a book on Perl, so why not roll this document of yours into the Perl distribution? Improve the man pages. I run a perl training, part time, where I work. Everyone in my class wants to learn perl. why did they bother coming to me when they could just read the source code and figure it out for themselves? Obviously, because teachers are a helpful learning tool. How would that be open source, if people can't modify it? More specifically, why would the OSI or the FSF care about it, if it's contrary to their goals? I find it interesting, almost like I've stepped into a world of group-self-deception, bordering on hypocricy, that GPL as a document is licensed as copy/distribute/no-modify. But every response (so far at least) to a request for a license that codifies copy/distribute/no-modify has dismissed the request. Great, someone else who's going to save open source from the people who understand it. Why are people so enchanted with the name open source that they want to attach it to whatever they do? First, I dismissed the relevance of your request - but I still provided some helpful suggestions. What you need isn't open source, deal with it. The responses so far regarding a copy/distribute/no-modify license have said that such a license would: 1) not be open source Well, I was more interested in pushing the not be open source software angle. But yeah, it's not open. 2) not further OSI's commitment to open-source That's right. Most of us also agree that translating all software documentation into Latin doesn't further the OSI's commitment to open source. 3) have no value to the rest of the world It might have value. I still get people who think that the Newbie Guide is useful (except for this little thing, would you mind changing it?). 4) would condemn it's document to instant out-of-dateness. Not instant. But it would be condemned. It is the official stance of the OSI that restricting yourself to a single vendor for a product through things such as no-modify clauses leads to undue reliance on the health and interest of that vendor (in this case, you). Yet, the GPL license, as a document itself, licensed as copy/distribute/no-modify, is: A) considered the granddaddy of all open-source movements B) at teh top of OSI's list of open source licenses C) widely by programmers to license their software D) up-to-date, and was even released with a new version number You're only fooling yourselves if you assert 1-4, since I've seen the evidence to the contrary in A-D. What can I say here but you're being obtuse? Here's an interesting point: the GPL ain't software. Delve into the issue, a little bit, and you'll figure this one out - hell, you've apparently figured out perl. So, I'm calling you on your conjuring trick. You wave your hands and say yeah, but that part's different. Do some thinking and you'll agree. Here's a first step: how does one preserve the right to modify the software in the license, if the license itself can change? A General Public License (GPL) that says copy/distribute/modify and a General Document License (GDL) that says copy/distribute/no-modify. I'm telling you that Open-Source ALREADY embraces both, since GPL is licensed under GDL. It's not a big deal. Get a clue. The GPL is not documentation, any more than it is software. No one ever argued that the GPL is free software. It's good enough for GPL to use the GDL, so it's good enough for me. What a maroon. What you need is not open source. What you need is (C) Greg London. The right to distribute copies of this work including this copyright notice, whole and without modification, is granted provided no fee is charged. No other rights are granted. What you want is to be able to attach the OSI service mark to your document. People in Hell want icewater. -- Matthew Weigel Research Systems Programmer [EMAIL PROTECTED] ne [EMAIL PROTECTED]
Re: documentation
On Monday 27 August 2001 12:41 pm, Matthew C. Weigel wrote: Not as a primary topic of discussion, no. Unaffiliated documentation suffers from bitrot at a much higher rate than affiliated documentation (and how often do you find out-of-date man pages in Linux?). A bit off topic, but I find out-of-date man pages in Linux every day! However, I have rarely if ever found an out-of-date man page in FreeBSD. The reason is simple. GNU discourages man pages. -- David Johnson ___ http://www.usermode.org
Re: documentation
On Monday 27 August 2001 08:37 am, Randy Kramer wrote: There are some other open source or free documentation licenses. One place to look is http://www.gnu.org/licenses/licenses.html#FDL. There is also something like an open content license somewhere. As usual, there is some contoversy about which licenses are free, etc. The problem is, and what Greg was getting at, is that most of these licenses themselves to not meet the Open Source definition (nor the Free Software definition for that matter). In other words, the Open Content License is not open and the GNU Free Documentation License is not free. The ideal would be to have the documentation and software fall under the same license, but all too often the author has differing needs for the docs and the code. -- David Johnson ___ http://www.usermode.org
Re: documentation
[EMAIL PROTECTED] scripsit: Because there is currently no OSI approved license that says copy/distribute/no-modify. yet the defition appears to support one. You keep ignoring the QPL and the Artistic License, and everyone else keeps ignoring the fact that you mean to allow patches. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Please leave your values| Check your assumptions. In fact, at the front desk. | check your assumptions at the door. --sign in Paris hotel |--Miles Vorkosigan
re: documentation
On Mon, 27 Aug 2001 [EMAIL PROTECTED] wrote: Because there is currently no OSI approved license that says copy/distribute/no-modify. yet the defition appears to support one. I've addressed this. There's a significant difference between being able to distribute pristine source+patches versus pristine documentation+patches. One would normally expect to have to build source. I offered the opinion that pristine source ruins usability for documents much more than for software, and thus should not be covered. Keep in mind you're trying to apply guidelines for software to a non-software document. There are some changes. Great, someone else who's going to save open source from the people who understand it. Why are people so enchanted with the name open source that they want to attach it to whatever they do? misdirection and drama. I'm not out to save anyone. What do you call a rant about how hypochritical us poor license-discuss folks are, ignoring virtually everything I said? If you're not out to save us, then you're just trying to show how smart you are. Oops. My original email stated that I'm looking for a license based on the OSI definition prohibiting item #3 (derived works) by allowing #4 (patches). And my original email stated that you needed to go somewhere else. I'm not breaking the definition of Open Source. Your problem isn't even *relevant* to open source software! there simply isn't a license currently approved that does what I'm looking for. But my request was within OSI's own definition. From the OSD: }The distribution terms of open-source software must comply with the }following criteria: What software are you planning on distributing? If I am misunderstanding item #4 in the Definition, then perhaps there is no way to do what I want to do with an OSI approvable license. You misunderstood the preamble. if so, I'll move on. Then do so. Look to projects that are putting an effort into this, like the FSF or LDP. it was a relavent question. no need for flames. Do you still have copy of all the messages I sent, and the messages you wrote responding to them? Honestly, I tried to be helpful and point out that your problem isn't addressed by the OSI. : 4. Integrity of The Author's Source Code : The license may restrict source-code from being : distributed in modified form only if the license : allows the distribution of patch files with : the source code for the purpose of modifying : the program at build time. Unless, of course, you're waving your fists in the air about something that isn't part of the Open Source Initiative's commitment. Are you speaking for OSI, or for yourself? No, I don't speak for the OSI. Are you speaking your own agenda here rather than OSI's? If so, I'll politely ignore you henceforth. My agenda here is to move you out of the way so that more relevant things can be discussed, or I can get back to work. Which is to say, my agenda is to get on with the OSI's agenda. Yet, the GPL license, as a document itself, licensed as copy/distribute/no-modify, is: What can I say here but you're being obtuse? Here's an interesting point: the GPL ain't software. I was attempting to be very explicit. I understand the GPL isn't software. and I noticed the GPL isn't licensed under a software style license. it's licensed under a document style license. Good for you. You're right. And you're wrong. Its copyright notice is the type reserved for licenses themselves. Licenses don't change when people make derivative works. Documentation does. yes, there are times where it makes sense to license a piece of text as 'no-modify'. yes, exactly. yes, that's exactly the kind of license I'm looking for. I never said that there weren't times no modify was good. If I were to make my public key available, I sure as hell wouldn't want someone changing it. But a PGP key ain't documentation. Get a clue. The GPL is not documentation, any more than it is software. No one ever argued that the GPL is free software. its not software, and its not a document? It's not documentation. And no, it's not software. Never said it wasn't a document. you cannot put the GPL license in some meta-world where the rules do not apply. Actually, I can. The GPL is a document that is copyrighted by FSF and licensed under a copy/distribute/no-modify license. It does not merit special protection from the rest of the world. Yes, it does. It's good enough for GPL to use the GDL, so it's good enough for me. What a maroon. ah, name-calling, a new low. I must ask if you're representing OSI, or are these your own opinions? Why would you assume that I represent OSI? Because I quote and paraphrase text from their website? And what makes you think me calling you a name started this? OSI's home page starts out with this commitment: :Open Source Initiative (OSI) is a non-profit corporation dedicated to :managing and promoting the Open
re: documentation
On Mon, 27 Aug 2001 [EMAIL PROTECTED] wrote: Which got me wondering. Exactly what world do you live in that software is NOT considered a document, controlled by copyright law? The world where software is covered as much by patent law, trade secret law Where I'm from it's a legal fact, and there is no opinion in the matter. There is always an opinion - should software methods be patentable, or does the DMCA appropriately represent the well-accepted cost/benefit analysis of copyright? -- Matthew Weigel Research Systems Programmer [EMAIL PROTECTED] ne [EMAIL PROTECTED]
Re: documentation
On Thursday 23 August 2001 12:03 pm, [EMAIL PROTECTED] wrote: I'm looking for an open-source license for some documentation. It would follow the definition of open-source given here: http://www.opensource.org/docs/definition.html I would be looking for a license that does not allow item #3 (Derived Works), but would allow #4 (Distribution of patch files with source). The OSI does not approve documentation licenses, only software licenses. Most free documentation licenses are quite complicated and convoluted. This is primarily due to the fact that they are trying to make them as free/open as possible without risking the work's or author's artistic integrity. By requiring derivations to be distributed as patches, you can cut through a lot of this clutter, and end up with a simple license if you work it right. I would look at the QPL software license as a starting point. -- David Johnson ___ http://www.usermode.org
Re: documentation
BTW, is it me or does the [eFAQ] link on the archive: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3 not work? I get an email that includes the following line: ezmlm-manage: fatal: unable to open text/faq: file does not exist You are correct. I've forwarded that onto the mailing-list maintainer. -- Steve Mallett | Just Stable, Open-Source Apps http://OpenSourceDirectory.org | [EMAIL PROTECTED] Project-Listing Maintenance In A Can: http://trovesendtwo.sf.net [EMAIL PROTECTED] (Aug 15th/01, I have nothing to do with license approval.)
Re: Documentation licenses revisited
Admittedly, I do not know anything about DNA or whether genetic code mapping is like source code, but your point sounds like the kind of argument I certainly would support. Rod This begs the whole question, how can copyleft and milder forms of copyright licensing be applied to all IP? Case in point, the biotech industry's inability to share database access. Celera is making a public scandal by charging public universities big bucks for access to their genome database, meanwhile the entire genomics industry is a battleground of competing proprietary standards. And proteomics promises to practically drown us all in proprietary data that's impossible to interrelate. Surely, of all the code that should be public, we should have "source" access to our own DNA? ~jake Jake Bowman Market Architecture 408.910.6594 [EMAIL PROTECTED]
Re: Documentation licenses revisited
This begs the whole question, how can copyleft and milder forms of copyright licensing be applied to all IP? Case in point, the biotech industry's inability to share database access. Celera is making a public scandal by charging public universities big bucks for access to their genome database, meanwhile the entire genomics industry is a battleground of competing proprietary standards. And proteomics promises to practically drown us all in proprietary data that's impossible to interrelate. Surely, of all the code that should be public, we should have "source" access to our own DNA? ~jake Jake Bowman Market Architecture 408.910.6594 [EMAIL PROTECTED] --- David Johnson [EMAIL PROTECTED] wrote: A while ago you may recall that I inquired as to free and open licenses for documentation. I chose the FDL at that time since the document in question was for software covered by the GPL. I am now creating a roleplaying game with some other people that needs a free and open license. It may be some months before it is released. I have come up with a simple documentation license based on the BSD license. I realize that the OSI is not in the business of approving non-software licenses, but I am submitting it to the list to garner comments and suggestions. Why not the FDL or another free documentation license? I desire a non-copyleft license for a variety of reasons, but probably the greatest reason is that I want a short and simple license. Why no "invariant" clauses? I thought long and hard about this one, but it turns out that the only invariant sections I actually want are the copyright, license and disclaimer. I'm not sure about the disclaimer. It seemed odd to me to include the standard warranty disclaimer. My rationale for the current disclaimer is to guarantee that that full attribution is attached, and the lack of any responsibility for derived works. Here it is in "templatized" form... --- Lore Document License Copyright (c) [year], [author] Redistribution, publication and use of this Document, with or without modification, alteration or translation, is permitted provided that the following conditions are met: (1) Redistributions or publications of this Document must retain the above copyright notice, this list of conditions, and the following disclaimer. (2) Neither the name of the copyright holders nor the names of any contributors to the Document may be used to endorse or promote products derived from this Document without specific prior written permission. This work is a copy of, or based on a copy of, [title], copyright © [year] by [author]. Distribution of, or derivation from, [title] in no way implies endorsement or warranty by [author]. --- Thanks... -- David Johnson ___ http://www.usermode.org __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
