These are mostly copied from emails, edited for brevity. Multiple emails may be combined into one comment, so "I" may not always mean the same person. --- When the Document is included an aggregate, this License does not. ^ in --- Section 1, Paragraph 4 ends "The Document may contain no Invariant Sections." -- This is largely a comment and seems ambiguous. Consider striking altogether or changing to "Invariant Sections are not required." if this comment is deemed important to retain. --- Could the FDL allow redistributors to be required to configure a document (effectively, fill in template values) before distributing? This would allow authors to require that the support email address (say) be changed before distribution. --- I am concerned that version 1.2 of the draft will make it harder to get CD's full of FDL covered documentation. The extension of cover texts to any media that often has a cover is somewhat like the "obnoxious BSD advertising clause". If a CD has 100 FDL documents (esp. mixed in with an OS distribution) the creator of the CD will have to locate each of these and find space on the front and back covers to add all of these texts. A CD image available for download would have none of these requirements. Manufacturer's who sell these CD images on CD may find it too impractical touch these images. Section 7 appears to address these concerns, but it does not seem to apply to CD's. There are no covers that surround the individual items of the aggregation, so the only option is to put all cover texts on the cover of the CD itself. It seems possible (although this should be made clear) that this allows the covers to be inserted in front of the files in electronic form. I am not sure what prompted this section's expansion of applicability (would someone care to tell me?), but I feel that the requirement to include Cover Texts should be restricted to traditional media that are human-readable without machine aid. Also, to speculate on the motivations behind this alteration, I don't think e-books are going to take off in the general marketplace except for people who currently use audiobooks. I'll note here that the GNU FDL does not appear to address the phenomenon of Braille books at all. What about audio books? --- > If the required texts for either cover are too voluminous to fit > legibly, you should put the first ones listed (as many as fit > reasonably) on the actual cover, and continue the rest onto adjacent > pages. Hmm.... this seems familiar. Where have I seen a license before that required large amounts of invariant text to be printed, even if it was inconvenient and required more space, and a well written objection to it? Ah, yes, right here: https://www.gnu.org/licenses/bsd.html I'm only going to suggest that one should consider pots and kettles *very* carefully, in light of the above referenced commentary on the *BSD license before finalizing the new GNU FDL. Eliminating Invariant Sections as a permitted part of the FDL will also eliminate this potential problem. [fsf comments: This comment is based on a misunderstanding of the issue of the original BSD license. Its problem was requiring specific text to be included in all *advertisements about the program*; this is a problem because space in advertisements is limited. All this is explained in https://www.gnu.org/licenses/bsd.html. Nearly all free software licenses require certain text (the text of the license, at least, which may be quite long) to be included in the distribution of the program.] --- Some users would prefer not to include the whole license in the body of their document (maybe because the document is short). Could a web link or some other form of reference be allowed instead? The GFDL requires me to include a copy of the license in the documentation. The GPL only requires a copy of the license along with the software. I would be quite annoyed if my MagicPoint presentation (which I can edit with generic text editors) had to have a copy of the license inside it. Also, what if the document is an image? Inserting a copy of the license might be not be possible. --- The demands for the title page are somewhat confusing. Perhaps the GFDL could be half as long and twice as simple. I am sorry to say I find your GNU Free Documentation License draft too complex. --- I am disappointed that PostScript is considered an "opaque" format. It is a plain ASCII vector and text description format, though opaque bitmaps may be included. There exist Free utilities for the manipulation of EPS and PS images for those who do not wish to learn PostScript and manipulate the images with vi or emacs. My friend wrote his resume in raw PostScript. I've even taken to using his library to write a few quick papers lately. I use nothing but a Free text editor and Ghostscript. I would note that the FDL draft makes a distinction between the obfuscated HTML generated by automatic programs and hand-written. Perhaps such a distinction could be made for PostScript and PDF. --- I don't agree with the definition of transparent images. I don't think talking of delivery formats is proper policy here. Sometimes I write postscript with emacs (for example, I did it for my greeting cards), I don't understand why *such* postscript is considered Opaque. Similary, if I draw images using GIMP, I feel the Jpeg output is Opaque. --- A possible problem with the notion of a "generic" text editor: I would be that a lot of free text editors have trouble handling Unicode. But in the current climate, where Unicode has been widely adopted (if not supported), I think authors should be able to submit documents in Unicode. The restriction to "generic text editors" should not rule out Unicode. --- > Examples of suitable formats for Transparent copies include [...] > SGML or XML using a publicly available DTD [...] > Opaque formats include [...] SGML or XML for which the DTD and/or > processing tools are not generally available This is not really what the licence wants to say. An XML DTD only describes the tree structure of a document, not the semantics. Also it is perfectly possible to have an "open", specified XML document without having a DTD (e.g. by using an XML schema). So the existence of a DTD is orthogonal to Transparent-ness, really. Why not say something like this? | Examples of suitable formats for Transparent copies include [...] | SGML or XML languages for which semantic definitions are publically | available [...] --- In Section 1, paragraph 7, a transparent drawing is said to be one suitable for revising with some widely available drawing editor. This allows that it can be in some proprietary format and can only be revised by some proprietary drawing editor (which may be able to export it in many other formats). Perhaps a transparent drawing should be required to be in some open format, and able to be edited by some widely available drawing editor. --- As a specific example of where the GPL is better worded, instead of arbitrarily listing certain formats as Transparent and others as Opaque, it simply refers to "the preferred form for modification." As one person already noted, Postscript is not necessarily opaque. What about Power Point presentations created using Open Office? I would hardly call Open Office a "generic text editor." What about Lyx files? Is anything created using a WYSIWIG interface not free? In other words: --- > The "Cover Texts" are certain short passages of text that are > listed, as Front-Cover Texts or Back-Cover Texts, in the notice that > says that the Document is released under this License. A > Front-Cover Text may be at most 5 words, and a Back-Cover Text may > be at most 25 words. Don't restrict the number of words! If you do, though, allow more words to be used. 50 for the Front-Cover Text and 150 for the Back-Cover Text is more reasonable. You should also address the covers artwork, such as logo, color theme, etc. It should also be protected. --- As you know, the concept of "word" in non-English languages like Japanese is quite different from that of English(or other Latin-origin languages). Maybe 5 words is too short. Along these lines, the entire German constitution is only 5 words (sorry). Maybe articles and prepositions could be excluded (this is a slippery slope) Or how about more generic terminology "a short phrase" and "a short description" Or "Can not exceed the median of published titles multiplied by three." Or nth percentile. Maybe a description (a short phrase) and a clarifier (usually 5 words or less) if you want to nail it down. --- The FDL can be, but doesn't need to be translated. The reasoning of section 8 seems to be that perfect translations can not be made. However, a translator might be able to charge an inappropriate price for a translated document if the buyer is unable to read english. Would it be possible to require the translation of a simple statement like "This document was given in the pursuit of freedom, at no cost, by the original author", or something that would capture the spirit of the GNU/FSF/FDL? On the other hand, maybe this attempted solution would cause other problems, very similar to problems that might arise if a translated FDL was required. --- Under this license could a reader photocopy for a colleague a single page of a reference manual without also having to photocopy the license and various other invariant sections? (Possibly: see Fair Use. But it should possibly be explicit. Someone suggests: Maybe allow it if the quoted text is shorter than the invariant sections, or if the quoted text is shorter than one page [give a word count, pages can have weird sizes]) Whether or not such a use is indeed possible, I think it would be a common question, and should be addressed in an accompanying FAQ. --- It would be nice if public performance were addressed as part of the FDL. FDL-licensed lecture slides and lecture notes should allow public performance of lectures based on them -- this is currently not mentioned in the FDL. --- Is there a reason for the "(c)", or the "(C)", used in the document? As I understand it, these three characters are not a valid notice of copyright. That is to say, they are not a copyright symbol. On the other hand, the word, "Copyright" that starts the line is sufficient to indicate a copyright. See 17 USC sect. 401 (b) (1) for details. --- The GFDL should contain a sample notice for GPL/GFDL dual licensing of code snippets (as recommended in the last paragraph). --- > These Warranty > Disclaimers are considered to be included by reference in this > License, but only as regards disclaiming warranties. I find this sentence confusing for two reaons. First, the "as regards" phrase is loose and may not be proper English. Second, the phrases "Warranty > Disclaimers" and "disclaiming warranties" make it sound circular. The sentence that follows tries to clarify this sentence, but I think this one should be worked on to make it more precise. > (all of its principal authors, if it has less than five) Change "less" to "fewer" I find the convention of the uppercase "Entitled" awkward, even though I think you adequately define your use of it. --- > The "Invariant Sections" are certain Secondary Sections whose titles > are designated, as being those of Invariant Sections, in the notice > -that says that the Document is released under this License. > +that says that the Document is released under this License. If a > +section does not fit the above definition of Secondary then it is not > +allowed to be designated as Invariant. The Document may contain no > +Invariant Sections. In the first added sentence, I suggest strengthening this prohibition to declare application of the FDL to the Document null and void if a non-Secondary Section is declared Invariant. I am confused as to the meaning of the second added sentence. A Secondary Section is defined in version 1.1 as "a named appendix or a front-matter section of the Document" and the Draft does not alter this definition; therefore it does not seem logically possible that an Invariant Section can exist in such a way as to satisfy the requirements of the Draft GNU FDL. Of course, any document which contains no Invariant Sections has no trouble here, and if that is what the FSF intends to encourage, I fully support you, but I encourage you to make this more explicit. To reiterate: I unreservedly support the elimination of Invariant Sections altogether. --- > Examples of suitable formats for Transparent copies include plain > ASCII without markup, Texinfo input format, LaTeX input format, SGML > or XML using a publicly available DTD, and standard-conforming simple > -HTML designed for human modification. Opaque formats include > -PostScript, PDF, proprietary formats that can be read and edited only > -by proprietary word processors, SGML or XML for which the DTD and/or > +HTML designed for human modification. Examples of transparent image > +formats include PNG, XCF and JPG. Opaque formats include PostScript, > +PDF, proprietary formats that can be read and edited only by > +proprietary word processors, SGML or XML for which the DTD and/or > processing tools are not generally available, and the > machine-generated HTML produced by some word processors for output > purposes only. This may range beyond the scope of the GNU FDL, but it sure would be nice to somehow encourage the DTD and/or processing tools to be Freely licensed. I do not object to this alteration, but I am concerned about the possible phenomenon of a "proprietary DTD" and the possible impact it may have on Free documentation. The extremely hostile intellectual property environment in the United States today gives me concern that reverse-engineering or re-implementation of a DTD. Not just on patent, but copyright grounds; despite copyright's traditional role protecting only specific expressions of ideas, there are efforts underway to broaden copyright to cover ideas themselves, which is traditionally the venue of patents. The hyper-aggressive tactics of these authoritarian proprieteers is alarming, and I feel that the GNU FDL should spare no opportunity to ensure that its terms afford no purchase from which this sort of attack on freedom may be launched. [fsf comments: Even if one could copyright a DTD, it wouldn't prevent reimplementation. ] --- > +A section "Entitled XYZ" means a named subunit of the Document whose Is the term "subunit" really necessary? If "unit" or "portion" won't do, I suggest defining the term "subunit". --- I understand the change from "LIST THEIR TITLES" to "no Invariant Sections", since people tend to cut and paste the text and there are a lot of "LIST THEIR TITLES" texts out there. On the other hand, I think the license is complex enough to require people to think a little about it. Forcing to either type something (instead of doing blind-cut-and-paste) or show the world that you didn't think about the meaning of the license is a fair compromise, in my opinion. Thus, I preferred the "LIST THEIR TITLES" version. --- I would like to see an explicit statement within the License that failure to identify (or explicitly state the absence of) any Invariant Sections or Cover Texts either: A) Means that there are no Invariant Sections or Cover Texts; or B) Renders the GNU FDL inapplicable to the document. When Debian recently audited packages using the GNU FDL, we found several failures to properly identify Invariant Sections and Cover Texts. This is an important failure because it left the licensing ambiguous. I would like the GNU FDL to more strongly encourage its users to not leave such things open to question. --- One or more persons was responsible for authoring these changes, but their identities are not presently known. Either they should be identified so that questions may be directed to them, or rationale statements for each change should be published somewhere. On a couple of occasions I found myself wondering what the motivation for a particular change was. Thanks for subjecting this draft to an open and public review process. I think it would be interesting if you published all the (non-spam) feedback you receive on this Draft. --- One problem with Invariant Sections that I haven't seen mentioned before is that once a Secondary Section has been declared as Invariant, the main Document may no longer be modified to have as part of its overall subject the contents of the Secondary Section. That is, that subject is not part of the overall subject matter *now*, but once there is an Invariant Secondary Section added, it may never be in the future, either. For instance, if a Document has a Secondary Section which explains some mathematics, I am thereby forbidden to add any mathematics as part of the "overall subject" of the main document, even though a unifying mathematical theory may have been discovered since the original document was written, and would be of great use in simplifying and extending the original document. Additionally, I am now forbidden to add any significant amount of text to the GNU Emacs manual concerning the economics of Free Software development because of the Invariant Section on Funding Free Software. I understand that the intent of Invariant Sections is to prevent their removal, but they are also preventing the addition of other parts. For anything except absolutely trivial Invariant Sections, this is a severe limitation on the Freeness of the Document. --- Short version: The GPL incompatibility of GFDL is bad. If the GFDL were a software license, it would be non-free because of Invariant Sections. The latter is a popular thread, especially on debian-legal. If I release a piece of software with Invariant Sections in the code, it would immediately (and rightly) be flagged as non-Free. However, I could conceivably write a document with Invariant Sections under the GFDL and it would be considered Free under the GNU FDL, yet I could not include it in a piece of software licensed under the GPL, because it is not Free according to the GPL. However (and this is where it is important that the FDL is intended to be used for manuals for free software), this is a fairly common occurrence to want to do this - it is nice for a piece of software to display its documentation in reponse to the "Help" command. Under other circumstances, it is roundly condemned if one were to take a piece of Free Software and attempt to include a piece that is not Free by means of dynamic linking - yet it appears to be acceptable to add a piece of documentation to the software which would be labeled non-Free if it was included in the code, so long as it is done by dynamic loading at run time in response to a request for documentation. This strikes me as hypocritical. Languages like Knuth's Web where code and documentation are interleaved in a single file further blurs the line; if such languages become more popular in the future, or if currently used languages acquire such features, we will find that we do not have the Freedom to do so. I look to the Free Software Foundation to protect against such a future, not to create it. --- The GFDL has a number of requirements that don't seem to help. It requires me to preserve the network location of where Transparent versions can be found for four years. Even if it is no longer correct, and the original author can not be reached. This is probably not uncommon. This does not raise the quality of free documentation. --- The GFDL has a number of clauses about copying in quantity, Endorsements, Title Page, and Cover Texts that unnecessarily confuse anyone who wants to apply the license to their work. These, I suspect from the rationale given in the link above, are to encourage commercial use of the license. The thing is, I don't understand how they actually help. The document can still be replicated without paying anyone anything (which is the whole point). These conditions just confuse the person using the license. --- Overall, I think that the FSF should just get rid of the GFDL, and use the GPL for documentation. There might have to be a clarification of what object code means, but otherwise its application is straightforward. --- In Section 4, item K., preserving acknowledgements and/or dedications "in substance and form" seems a bit vague. --- The bottom of the document notes that this is a draft from January 2002 and the copyright at the top is 2000,2001. I suspect the copyright then to be inaccurate. --- I found the following sentence of the draft FDL at least unclear: "If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols." The syntax seems to decay towards the end. I suggest: "If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or describe in or with each Opaque copy how a member of the general network-using public can download a complete Transparent copy anonymously at no charge using public-standard network protocols." --- It is quite likely that the author would add backup locations in case the primary one is taken down, and it is not in a distributed system a la Eternity Service. Indeed, one could argue that "network locations" should be understood as "instructions on how to locate a copy on the network", eg a list of jump points that keep a current link. --- I was skimming over draft 1.2 of the FDL and clause 4.A. caught my attention - namely that the GPL and GPL have no analogous conditions requiring that a title of a previous version of the program or library can be reused for the distribution of the modified version only with the permission of the developers of that previous version. Have such analogous conditions been proposed for future versions of the GPL and LGPL? After all, title control is as important to software as it is to documentation. --- > If you have no Invariant Sections, write "with no Invariant Sections" instead > of saying which ones are invariant. If you have no Front-Cover Texts, write > "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise > for Back-Cover Texts. Shouldn't it be '... instead of "the Front-Cover Texts being LIST"'??? For native-speakers this is obvious, but for other people it might not be clear that there should not be an article before the "no" (I just had to referee a paper by some japanese Mathematicians, and you can't image how they screw up the articles!). If you cite exactly which parts should be replaced, I'd say you better include the exact parts and not just the position, so that the author again has to find out himself what exactly to replace. --- "+If a section in the Document is Entitled "Acknowledgements", +"Dedications", or "History", the requirement to preserve its title +(section 4) will typically require an altered title (section 1)." this statement of section "8 TRANSLATION" isn't very clear. what is the effect that this statement has on the requirements in sections 4 and 1? are you talking about 4.I. and 4.K.? is this saying that the requirements of section 4 don't apply to translations? "History", "Acknowledgements", "Dedications", "Endorsements" and any other sections that are named in the FDL and have special considerations explained in the FDL, should be defined in section 1. it will be easier for authors (like me) to know how to construct their document if all of the special sections are listed and defined in the same place. --- "+ Document (all of its principal authors, if it has less than five), + unless they release you from this requirement. C. State on the Title page the name of the publisher of the" Maybe this should say that when the author releases them, they should retain proof that the author released them from that requirement. so that anyone (including the author) can ask them the "prove it" when there is a dispute. --- I want to note that the FDL is not a valid license agreement with respect to Czech copyright law as some mandatory statements are missing. The Czech copyright law (121/2000 Sb.) requires that the following is specified in each license agreement: * the royalty fee, e.g. that the license is provided free of charge [49-2b] * the area of applicability, e.g. that the license is world-wide [50-3a specifies that the default is the area of the Czech Rep.] * the duration of the license, e.g. "whose duration is unlimited" [50-3b specifies that the default duration is two years] * it would help if the licensor, the licensee and the exact moment when the licensee accepts the license are specified more precisely. The same comments apply to the GPL and LGPL. --- I still have a problem when translating a document licensed under FDL, even its 1.2 draft. According to FDL, when I translate a document licensed under it, I must change the title because a translation is a modification. What is the definition of "a title distinct from that of the Document" stated in the section 4.A? Is a word-for-word translation enough, or do I have to append something like "(Japanese translation)"? It may be a good idea to clarify this point in the 1.2 release. ---- At the bottom of each online page (file: HTML, PDF, PS, ..) above the scroll redeable in all common resolutions must be a "front cover text". Maybe at the bottom as a "back cover" text, too. Example front cover text: "The original and probably updated version of this document may be found at URL". --- Should works which are explicitly written as companion works to an FDL textbook (workbooks and answer books) be covered by the FDL? This could be hard to enforce, but something like GPL sect. 2, 3rd-to-last paragraph would be a start.