Re: Suggestion to maintainers of GFDL docs
On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith [EMAIL PROTECTED] wrote a message of 25 lines which said: * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. Can you actually write this section and post it here? Because I have a practical problem: finding a free licence for an important documentation I'm currently writing (and one which is not included in a specific software) and, after getting a headache from reading hundreds of previous postings in debian-legal, I still have difficulties to find a proper licence. Practical advices are welcome. I believe it is easier to bash the GFDL than to write a proper alternative.
Re: Suggestion to maintainers of GFDL docs
Stephane Bortzmeyer [EMAIL PROTECTED] writes: On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith [EMAIL PROTECTED] wrote a message of 25 lines which said: * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. Can you actually write this section and post it here? Because I have a practical problem: finding a free licence for an important documentation I'm currently writing (and one which is not included in a specific software) and, after getting a headache from reading hundreds of previous postings in debian-legal, I still have difficulties to find a proper licence. Practical advices are welcome. I believe it is easier to bash the GFDL than to write a proper alternative. The MIT/X11 license and the GPL would both work, depending on whether you want a copyleft. The MIT license can probably be used just by itself. To use the GPL, though, you should probably put in a section which explains how your document can be viewed as software, along the lines of: This section is for clarification only. It is intended to expand on the wishes of the author, but should not be interpreted to change the license or copyright status of the work. The author intends that the LaTeX2e source for this document be treated as the preferred form for modification, which is to say the Source Code. All other formats -- even open, transparent formats such as plain text or HTML -- are hard for the author to use in integrating changes to his copy of the document, and so should be considered Object Code. Again, this isn't a binding statement, and any distribution in a preferred form for modification, such as plain text or clean HTML, is acceptable as Source Code under the license. Distribution in a closed, hard to modify format such as PDF, generated HTML or PostScript, or a Microsoft Word document should always be treated as Object Code. I hope that's useful to you. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Suggestion to maintainers of GFDL docs
* Brian T. Sniffen ([EMAIL PROTECTED]) wrote: The MIT/X11 license and the GPL would both work, depending on whether you want a copyleft. The MIT license can probably be used just by itself. To use the GPL, though, you should probably put in a section which explains how your document can be viewed as software, along the lines of: This section is for clarification only. It is intended to expand on the wishes of the author, but should not be interpreted to change the license or copyright status of the work. The author intends that the LaTeX2e source for this document be treated as the preferred form for modification, which is to say the Source Code. All other formats -- even open, transparent formats such as plain text or HTML -- are hard for the author to use in integrating changes to his copy of the document, and so should be considered Object Code. Again, this isn't a binding statement, and any distribution in a preferred form for modification, such as plain text or clean HTML, is acceptable as Source Code under the license. Distribution in a closed, hard to modify format such as PDF, generated HTML or PostScript, or a Microsoft Word document should always be treated as Object Code. perhaps change 'clean HTML' to 'w3c valid HTML', with a link to w3c.org's validation site? and possibly avoid referring directly to MSWord as well - a reference to 'binary, closed file formats' would probably do the same job. iain -- wh33, y1p33 3tc. If sharing a thing in no way diminishes it, it is not rightly owned if it is not shared. -St. Augustine
Re: Suggestion to maintainers of GFDL docs
iain d broadfoot [EMAIL PROTECTED] writes: * Brian T. Sniffen ([EMAIL PROTECTED]) wrote: The MIT/X11 license and the GPL would both work, depending on whether you want a copyleft. The MIT license can probably be used just by itself. To use the GPL, though, you should probably put in a section which explains how your document can be viewed as software, along the lines of: This section is for clarification only. It is intended to expand on the wishes of the author, but should not be interpreted to change the license or copyright status of the work. The author intends that the LaTeX2e source for this document be treated as the preferred form for modification, which is to say the Source Code. All other formats -- even open, transparent formats such as plain text or HTML -- are hard for the author to use in integrating changes to his copy of the document, and so should be considered Object Code. Again, this isn't a binding statement, and any distribution in a preferred form for modification, such as plain text or clean HTML, is acceptable as Source Code under the license. Distribution in a closed, hard to modify format such as PDF, generated HTML or PostScript, or a Microsoft Word document should always be treated as Object Code. perhaps change 'clean HTML' to 'w3c valid HTML', with a link to w3c.org's validation site? It would be nice if that worked, but there's plenty of obfuscated HTML code which is valid. If you want to claim HTML as a preferred form of modification for any of my documents, I really want it to be hand-written. Others might prefer Dreamweaver-compatible HTML, though. and possibly avoid referring directly to MSWord as well - a reference to 'binary, closed file formats' would probably do the same job. Yes, that might be better. I'd avoid the words closed and binary, as MS is already trying to redefine both. Perhaps formats of proprietary word processing programs. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Suggestion to maintainers of GFDL docs
* Brian T. Sniffen ([EMAIL PROTECTED]) wrote: iain d broadfoot [EMAIL PROTECTED] writes: * Brian T. Sniffen ([EMAIL PROTECTED]) wrote: The MIT/X11 license and the GPL would both work, depending on whether you want a copyleft. The MIT license can probably be used just by itself. To use the GPL, though, you should probably put in a section which explains how your document can be viewed as software, along the lines of: This section is for clarification only. It is intended to expand on the wishes of the author, but should not be interpreted to change the license or copyright status of the work. The author intends that the LaTeX2e source for this document be treated as the preferred form for modification, which is to say the Source Code. All other formats -- even open, transparent formats such as plain text or HTML -- are hard for the author to use in integrating changes to his copy of the document, and so should be considered Object Code. Again, this isn't a binding statement, and any distribution in a preferred form for modification, such as plain text or clean HTML, is acceptable as Source Code under the license. Distribution in a closed, hard to modify format such as PDF, generated HTML or PostScript, or a Microsoft Word document should always be treated as Object Code. perhaps change 'clean HTML' to 'w3c valid HTML', with a link to w3c.org's validation site? It would be nice if that worked, but there's plenty of obfuscated HTML code which is valid. If you want to claim HTML as a preferred form of modification for any of my documents, I really want it to be hand-written. Others might prefer Dreamweaver-compatible HTML, though. true, i hadn't thought of that - clean is better than valid. :D and possibly avoid referring directly to MSWord as well - a reference to 'binary, closed file formats' would probably do the same job. Yes, that might be better. I'd avoid the words closed and binary, as MS is already trying to redefine both. Perhaps formats of proprietary word processing programs. hmmm, even that might not cover enough - we wouldn't want OOo Write format to be treated as Source Code presumably. perhaps it should be chopped back further, to say that the Source must always be directly editable as text rather than requiring to be parsed _before_ editing - that would cover plaintext, LaTeX, HTML etc and block PDF, PS MS, OOo, Abi, etc etc etc. 'Distribution in any format that requires parsing to be editable should be considered Object Code' or similar? maybe limit the allowed parsing to `cat $FILENAME`... :D iain -- wh33, y1p33 3tc. If sharing a thing in no way diminishes it, it is not rightly owned if it is not shared. -St. Augustine
Re: Suggestion to maintainers of GFDL docs
iain d broadfoot [EMAIL PROTECTED] writes: and possibly avoid referring directly to MSWord as well - a reference to 'binary, closed file formats' would probably do the same job. Yes, that might be better. I'd avoid the words closed and binary, as MS is already trying to redefine both. Perhaps formats of proprietary word processing programs. hmmm, even that might not cover enough - we wouldn't want OOo Write format to be treated as Source Code presumably. Actually, if I can get free software which can read it and parse it into something useful to me, I'm content with that. I'd prefer more, but requiring that it's easily editable using free software is enough. perhaps it should be chopped back further, to say that the Source must always be directly editable as text rather than requiring to be parsed _before_ editing - that would cover plaintext, LaTeX, HTML etc and block PDF, PS MS, OOo, Abi, etc etc etc. 'Distribution in any format that requires parsing to be editable should be considered Object Code' or similar? maybe limit the allowed parsing to `cat $FILENAME`... :D But I actually do write documents in raw PostScript, by hand. It's quite readable, well-commented code, too. The requirement that source be plain text seems... short-sighted. A month after that goes into recommended text, someone *will* show up here with an illuminated manuscript they want to distribute, and the calligraphy's important... oh, there you go: ideally, this text should work for non-English text, and for documents which have embedded graphics. Plain text really doesn't satisfy either of those. Since this isn't actually license text, but merely accompanying clarification, it's probably OK to be sloppy and request plain text, or must be editable with free software. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Suggestion to maintainers of GFDL docs
A Microsoft Word document is probably source code rather than object code: people do edit Microsoft Word documents, and people don't usually do automatic translations into Microsoft Word format (though they do sometimes, for example when exporting from another word processor). Anyway, I don't think people distributing Word versions of free documentation is likely to be much of a problem in practice, so I would advise against concocting dodgy clarifications of the GPL that attempt to prohibit this practice. Distribution of optimised PDFs and the like without providing the corresponding source is clearly disallowed by the GPL. Edmund
Re: Suggestion to maintainers of GFDL docs
iain d broadfoot [EMAIL PROTECTED] writes: plain text would simply mean that i can type `vim something`, and have the text appear in front of me. presumably, those strange foreign chaps already have their systems set up to handle those strange foreign chars. But *I* don't. So it's not a preferred form for modification to me. i'm never entirely convinced of the need for inline images, but i can certainly see that they _would_ be used if available. The argument doesn't need them to be inline, just graphics which need to fall under the same license as the text. .fig is very close to plain text, but really not parsable by humans above a very simple level. Since this isn't actually license text, but merely accompanying clarification, it's probably OK to be sloppy and request plain text, or must be editable with free software. but that allows MSWord docs, since i can edit them with Abiword, OOo etc... *Some* word docs might, then, be considered open. Certainly, I've been unable to open others in reasonably up-to-date Abiword or OpenOffice. maybe request a plain text version alongside any other formats? or must be editable with free software and must be saved in a Free format? Since these are just suggestions from the author, I see no harm in any of these. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Suggestion to maintainers of GFDL docs
On Tue, 22 Apr 2003, iain d broadfoot wrote: but that allows MSWord docs, since i can edit them with Abiword, OOo etc... maybe request a plain text version alongside any other formats? or must be editable with free software and must be saved in a Free format? I'm not sure where this requirement is coming from. It goes quite a bit further than the GPL requires for software. The source code for a work means the preferred form of the work for making modifications to it The main ambiguity is preferred by whom, and IMO the reasonable interpretation is preferred by the person who copies or distributes a binary under section 3. Whatever form the modifier prefers to work in is acceptible. In very few cases would this form be so opaque as to be unconvertable into some usable format by the next person downstream who had a different preference. I wouldn't mind a clause requiring the format to be documented well enough that a parser could be written, but it's going to far to require that there already exist free software (by some definition) to edit it. Further, there are plenty of free binary editors, and it's going to be darned hard to define what level of editing features beyond that are required to qualify as acceptible. As long as there's a machine-readable stream of bytes which the upstream author reasonably claims is the complete work in her preferred editing format, the work can be considered free, IMO. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: Suggestion to maintainers of GFDL docs
* Mark Rafn ([EMAIL PROTECTED]) wrote: On Tue, 22 Apr 2003, iain d broadfoot wrote: but that allows MSWord docs, since i can edit them with Abiword, OOo etc... maybe request a plain text version alongside any other formats? or must be editable with free software and must be saved in a Free format? I'm not sure where this requirement is coming from. It goes quite a bit further than the GPL requires for software. The source code for a work means the preferred form of the work for making modifications to it it's not a requirement by any means, just a clarification of the author's desires. iain -- wh33, y1p33 3tc. If sharing a thing in no way diminishes it, it is not rightly owned if it is not shared. -St. Augustine
Re: Suggestion to maintainers of GFDL docs
On 20030416T094049-0400, Peter S Galbraith wrote: * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. And what if this new section listing reasons _not_ to use this license were made... invariant! If we were to add to each GFDL'd document a section (invariant or not) saying, essentially, that we consider GFDL a non-free license (what else can that section say?), we would have to start moving such documents to nonfree at the same time. Otherwise we'd be hypocrites. Personally I believe that simply moving them to nonfree is far more effective than such an added section. Look at the publicity our stance against KDE used to generate when it had its license problem. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgpCgRIpUXBQM.pgp Description: PGP signature
Re: Suggestion to maintainers of GFDL docs
On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote: Consider this a suggestion to maintainers of packages that contain documentation that are under the GFDL, especially if it contains invariant sections. Imagine if an Emacs user visited Info and saw this: * Menu: * Distrib:: How to get the latest Emacs distribution. * Copying:: The GNU General Public License gives you permission to redistribute GNU Emacs on certain terms; it also explains that there is no warranty. * GNU Free Documentation License:: The license for this documentation. * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. Debian can't legally distribute such an info document. Because the GFDL is incompatible with the GPL, it is prohibited to even create an info document from GFDL'd texinfo source. See #183860. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgp1MByC1oaVL.pgp Description: PGP signature
Re: Suggestion to maintainers of GFDL docs
Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote: On 20030416T094049-0400, Peter S Galbraith wrote: * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. And what if this new section listing reasons _not_ to use this license were made... invariant! If we were to add to each GFDL'd document a section (invariant or not) saying, essentially, that we consider GFDL a non-free license (what else can that section say?), we would have to start moving such documents to nonfree at the same time. Otherwise we'd be hypocrites. You're quite right. Forget about making it invariant. Personally I believe that simply moving them to nonfree is far more effective than such an added section. Look at the publicity our stance against KDE used to generate when it had its license problem. You're probably right. But I still wouldn't encourage the use of the license without the invariant parts being used since it allows derived works to add them. Peter -- Peter S. Galbraith, Debian Developer [EMAIL PROTECTED] http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E
Re: Suggestion to maintainers of GFDL docs
On Thu, Apr 17, 2003 at 02:34:36PM +, Brian M. Carlson wrote: Debian can't legally distribute such an info document. Because the GFDL is incompatible with the GPL, it is prohibited to even create an info document from GFDL'd texinfo source. See #183860. Hrm, if that's the case, we can't distribute, eg, the pcl-cvs.texi file either -- after all, it's licensed under a verbatim copying only license, but has the \input texinfo line at the top. I don't think that is the case though, for two reasons: (1) we don't actually distribute pcl-cvs anything that's made use of the TeX stuff; so we haven't made copies of texinfo.tex, and don't need to be concerned with its copyright (2) the TeX output probably comes under the exemption in section 0 of the GPL -- `...the output from the Program (texinfo.tex) is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).' Either reason alone should be enough to make this not a real concern. The FSF might like to clarify their intentions here. Bug cc'ed. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpyyf3bgYuxH.pgp Description: PGP signature
Re: Suggestion to maintainers of GFDL docs
Peter S Galbraith [EMAIL PROTECTED] writes: And what if this new section listing reasons _not_ to use this license were made... invariant! I think writing such a new section is a reasonable thing, but of course, we can't make in invariant without violating our own principles.
Re: Suggestion to maintainers of GFDL docs
On Fri, Apr 18, 2003 at 04:16:57AM +1000, Anthony Towns wrote: On Thu, Apr 17, 2003 at 02:34:36PM +, Brian M. Carlson wrote: Debian can't legally distribute such an info document. Because the GFDL is incompatible with the GPL, it is prohibited to even create an info document from GFDL'd texinfo source. See #183860. Hrm, if that's the case, we can't distribute, eg, the pcl-cvs.texi file either -- after all, it's licensed under a verbatim copying only license, but has the \input texinfo line at the top. I don't think that is the case though, for two reasons: (1) we don't actually distribute pcl-cvs anything that's made use of the TeX stuff; so we haven't made copies of texinfo.tex, and don't need to be concerned with its copyright (2) the TeX output probably comes under the exemption in section 0 of the GPL -- `...the output from the Program (texinfo.tex) is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).' In this case, texinfo.tex is akin to a header file that a program. The program would be TeX (or a variant that implements the TeX macro language.) However, this only applies to DVI and PDF forms of this work. The info documentation is generated by makeinfo, which does not put any significant chunks of itself within the output. Simon
Suggestion to maintainers of GFDL docs
Consider this a suggestion to maintainers of packages that contain documentation that are under the GFDL, especially if it contains invariant sections. Imagine if an Emacs user visited Info and saw this: * Menu: * Distrib:: How to get the latest Emacs distribution. * Copying:: The GNU General Public License gives you permission to redistribute GNU Emacs on certain terms; it also explains that there is no warranty. * GNU Free Documentation License:: The license for this documentation. * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. And what if this new section listing reasons _not_ to use this license were made... invariant! If the FSF wants to give redistributors a soapbox, perhaps we should use it. Peter
Re: Suggestion to maintainers of GFDL docs
On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote: * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. And what if this new section listing reasons _not_ to use this license were made... invariant! If the FSF wants to give redistributors a soapbox, perhaps we should use it. We already have a soapbox -- debian-announce@lists.debian.org and www.debian.org. We don't need to tie our opinions to technical documentation to have them heard. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpyeMndpa6xy.pgp Description: PGP signature
Re: Suggestion to maintainers of GFDL docs
Anthony Towns aj@azure.humbug.org.au wrote: On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote: * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. And what if this new section listing reasons _not_ to use this license were made... invariant! If the FSF wants to give redistributors a soapbox, perhaps we should use it. We already have a soapbox -- debian-announce@lists.debian.org and www.debian.org. We don't need to tie our opinions to technical documentation to have them heard. Sure, but doing it this way might drive the point across a lot better. These info files advertise this license to potential authors, so having a rebuttal in the same place is effective. Anyway, it's just an idea. And it's up to individual package maintainers anyway. If we ever publish such a list, I might use it in such a way. Peter
Re: Suggestion to maintainers of GFDL docs
On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote: Consider this a suggestion to maintainers of packages that contain documentation that are under the GFDL, especially if it contains invariant sections. Imagine if an Emacs user visited Info and saw this: * Menu: * Distrib:: How to get the latest Emacs distribution. * Copying:: The GNU General Public License gives you permission to redistribute GNU Emacs on certain terms; it also explains that there is no warranty. * GNU Free Documentation License:: The license for this documentation. * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. And what if this new section listing reasons _not_ to use this license were made... invariant! If the FSF wants to give redistributors a soapbox, perhaps we should use it. Although incredibly clever, this is not the sort of thing that we should do. It would be very hypocritical to use a non-free mechanism to try to advance free documentation. Plus, it would make people angry; and who needs to anger more people? Simon
Re: Suggestion to maintainers of GFDL docs
Simon Law [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote: Consider this a suggestion to maintainers of packages that contain documentation that are under the GFDL, especially if it contains invariant sections. Imagine if an Emacs user visited Info and saw this: * Menu: * Distrib:: How to get the latest Emacs distribution. * Copying:: The GNU General Public License gives you permission to redistribute GNU Emacs on certain terms; it also explains that there is no warranty. * GNU Free Documentation License:: The license for this documentation. * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. And what if this new section listing reasons _not_ to use this license were made... invariant! If the FSF wants to give redistributors a soapbox, perhaps we should use it. Although incredibly clever, Thanks! this is not the sort of thing that we should do. It would be very hypocritical to use a non-free mechanism to try to advance free documentation. Well, I suppose the section wouldn't need to be invariant to be effective. It could simply mention that it _could have been invariant_ and that's why the license isn't very protective of freedom. Plus, it would make people angry; and who needs to anger more people? Simon Perhaps. I admit that my judgement might be affected by the current discussion with Georg Greve. But the section wouldn't need to be written in an inflammatory manner. In fact it would be much more effective if it were not. I'm just worried that a lot of projects will use this license because it's the FSF-approved method. That's what we did at http://gri.sourceforge.net and I will change that now that I know better. Luckily, it's not too late for us. But for other projects with a great number of contributors it's probably already very difficult to change the license. This issue needs more visibility. Peter
