Draft Debian Position Statement about the GNU Free Documentation License(GFDL)

This document is being put together to attempt to address some concerns that members of the Debian legal team have about the GNU Free Documentation License. This document attempts to present the reasoning behind the conclusion that the GNU FDL is not regarded as a license that can easily satisfy the Debian Free Software Guidelines. The intention is to craft a document that can be presented to the project membership as a statement that can be issued under section 4.1.5 of the Debian constitution (the developers may issue such position statements using the general resolution protocol). Please note that only the first part of this document shall be issued as the position statement — the Contributions and Support Documents section is auxiliary, and it shall not be part of the position statement issued by the project.


Introduction

Beginning in 2001, concerns regarding the compatibility of the GNU Free Documentation License with the Debian Free Software Guidelines came to the attention of the debian-legal mailing list.

In early 2002, the Free Software Foundation announced that it would be revising the GNU FDL and producing a new version, issued a draft, and solicited feedback from the community.

Towards the end of 2002, the FSF released version 1.2 of the GNU FDL, but their new version did not address several of the DFSG-related concerns of the Debian Project. An additional year's worth of discussions with representatives of the FSF did not persuade the Debian Project that its interpretation of the license or its own guidelines are incorrect; neither did they persuade the FSF that substantial alteration of the FDL's terms were warranted.

The problems with the GFDL fall into three major categories, which are treated in detail below.

The DRM restriction

Section 2 (VERBATIM COPYING) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to "technical measures to obstruct or control" reading and copying. This means that:

  1. It is not limited to the act of distribution (i.e., it applies to private copies as well).
  2. It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time.
  3. As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions.

Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction.

Transparent and Opaque copies

Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form.

It is our belief that as long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the transparent form. This is a paraphrase from the GPL FAQ

The requirements for redistributors should be to make sure the users can get the transparent form, not to force users to download the transparent form even if they don't want it.

Invariant Sections

This is the most troublesome part of the GFDL.

The GNU FDL includes a number of conditions that apply to all modified versions that disallow modifications. Specifically, Section 4 of the GFDL describes the invariant sections that must be unaltered in their text and in their titles in any derived works. These invariant sections must be secondary sections; a secondary sections is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject.. These parts include:

However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, which state:

	  3. Derived Works
	  
	  The license must allow modifications and derived works, and
	  must allow them to be distributed under the same terms as the
	  license of the original software.
	

As such, we cannot accept works that include "Invariant Sections" and similar unmodifiable components into our distribution.

In addition to the simple restrictions of freedoms imposed by the Invariant Sections, they also cause practical problems:

There is some concern that the requirements to list the authors of the modification on the title page and the history sections of the GFDL covered work (especially since these sections are otherwise invariant) appear to prohibit anonymous modifications to a document. (This may fail the Dissident Test).

Freedoms for Documentation

Analogous to the software program freedoms, we need to articulate the freedoms required for the subset of software called documentation.

  1. The freedom to read the text, for any purpose.
  2. The freedom to study how the text is written, and adapt it to your needs. Access to the text in the preferred form for modification is a precondition for this. This includes the ability to modify the work to fit in low memory situations, reference cards, PDA's, embedded devices, etc.
  3. Freedom to reformat the document into a preferred format or medium (converting to braille, or speech, or hardcopy, or postscript, etc).
  4. The freedom to redistribute copies so you can help your neighbor.
  5. The freedom to improve the text, and release your improvements to the public, so that the whole community benefits. Access to the preferred form for modification is a precondition for this. For program documentation, this implies being able to change the documentation to reflect the changes in the program.
  6. Freedom to translate the text into any other language.
  7. The freedom to keep your modifications, or even your possession of a copy of the text, confidential.

Conclusion

It is not possible to borrow text from a GFDL'd manual and incorporate it in any free software program whatsoever. This is not a mere license incompatibility. It's not just that the GFDL is incompatible with this or that free software license: it's that it is fundamentally incompatible with any free software license whatsoever. So if you write a new program, and you have no commitments at all about what license you want to use, saving only that it be a free license, you cannot include GFDL'd text.

The GNU FDL, as it stands today, does not meet the Debian Free Software Guidelines. There are significant problems with the license, as detailed above; and, as such, we cannot accept works licensed unde the GNU FDL into our distribution.


Contributions and Support documents

The following are comments by Branden Robinson:


Beginning in 2001, concerns regarding the compatibility of the GNU Free Documentation License with the Debian Free Software Guidelines came to the attention of the debian-legal mailing list. (A version of the word diff between versions 1.1 and 1.2 of the GFDL may make for easier reading -- Steven Augart).

In early 2002, the Free Software Foundation announced that it would be revising the GNU FDL and producing a new version, issued a draft, and solicited feedback from the community.

Towards the end of 2002, the FSF released version 1.2 of the GNU FDL, but their new version did not address several of the DFSG-related concerns of the Debian Project. An additional year's worth of discussions with representatives of the FSF did not persuade the Debian Project that its interpretation of the license or its own guidelines are incorrect; neither did they persuade the FSF that substantial alteration of the FDL's terms were warranted.


Unfortunately, most of this discussion has been confined to the debian-legal mailing list, with the result that people like me who do not follow debian-legal are not aware of the situation, and, for the most part, do not know the details of the issue involved.

If the concerns of the people on debian-legal are shared by the developer body at large, we may have a potentially serious issue. The first step to determine this is making people aware of the issues involved. The next would be to see if we can reach a determination of the position the project at large want to take on this issue.

Having a common position for the project on this issue would also help in trying to resolve the concerns; having a common voice, and knowing what the project wishes to do about packages that ship with GFDL licensed material would help our representative to better project Debian's position.

This is the reason for this document; it encapsulates the concerns that Debian folks have raised over in debian-legal, along with an annotated version of the GFDL. I have tried to be inclusive, and have incorporated in this one document all the concerns that have been voiced by various people on debian-legal. This is a work in progress, it is meant to be discussed and modified by the developer body. It needs to be integrated into a coherent position statement, and the polish that it currently lacks needs to be remedied.

At this stage, I have distinguished between my commentary (which has largely not been honed in a discussion), and mature commentary from mavens on debian-legal; and I have attributed each contributor separately. Over time, I hope to use this document as the basis for crafting a common position statement by the developers, which we can issue under section 4.1.5 of the Debian Constitution.

I need your help to create and refine this position statement.

Overview

The problems with the GFDL fall into three major categories.

  1. The "DRM" restriction
  2. Transparent and Opaque copies
  3. Invariant Sections

Annotated GNU Free Documentation License


GNU Free Documentation License

Version 1.2, November 2002

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.


Matthew Garrett Notes:

While not a Freeness issue, it should be noted that gdb at one point included sections marked as secondary that did not fit these criteria. Though possibly unsurprising that a complicated license may be misused in the early days before it is well understood, the fact that GNU could make such mistakes suggests that many GFDL works may end up with invalid licensing terms.

There is also evidence that people are using invariant sections in a manner not envisaged by the authors of the GFDL: Look at Ralf Hildebrandt: /~hildeb/postfix/postfix_sobigf.shtml, with the following license statement: Permission is granted to copy and/or distribute this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being THE WHOLE DOCUMENT (each section is invariant). No Front- or Back-Cover Texts are provided.


Back to the GFDL:

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. 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 zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

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.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".


Matthew Garrett Notes:

Awkward. Even if the Microsoft Word file format was well described, it would not be modifiable in a "generic text editor". The GPL requires distribution of source in "The preferred format for modification" - the GFDL limits what that preferred form may be. The lack of definition of "copy" here makes things unclear - if my only source is a formatted Word document, does a plain text output of the contents qualify as a transparent version? Without clarification, this may prevent certain types of derivative work being produced, which would be a violation of DFSG 3.

Anthony DeRobertis elucidates:

You missed the requirement to include transparent copies (more on that later -ms). You have used MS Word as the problem with the definition of transparent sections. More interesting ones are OpenOffice and Lyx. Also, music is interesting, too.


Back to the GFDL:

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, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include 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, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.


The following is from Jeremy Hankins:

Various parts of a work under the GFDL can be both unmodifiable and non-removable. These parts include:

  • Invariant Sections
  • Cover Texts
  • Acknowledgements
  • Dedications

We believe that certain restrictions on modification do pass the DFSG. Such restrictions might include a requirement that the name be changed from the original when it is modified, or that a disclaimer be added (e.g., "This document does not necessarily represent the opinion of Mr. Foo"), or even that a changelog be kept. But in this case both the fact that these sections are entirely unmodifiable and that they are non-removable violate the DFSG.


Back to the GFDL:

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.


The following is from Jeremy Hankins:

This goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to "technical measures to obstruct or control" reading and copying. This means that:

  1. It is not limited to the act of distribution (i.e., it applies to private copies as well).
  2. It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time.

Matthew Garrett notes:

One of the big issues. Note "Make or distribute". chmod a-r'ing a GFDLed document that you have downloaded could be against this term, as could distributing a copy over an encrypted link ("Obstruct or control the reading" is not clarified to apply merely to the recipient).

Nathanael Nerode comments:

This was intended to attack DRM systems, but it is far too broad. It applies to private copies made and not distributed. "Technical measures" is not defined. The natural interpretation includes activities like encrypting a copy, storing it on an encrypted file system, or even storing it on a file-sharing system with non-world-readable permissions. This is evidently not free.

Hopefully the FSF will fix this some time -- in my opinion, replacing "make or distribute" with "make and distribute" would be a good start.

Responses to some of these concerns

In a reply to Josselin Mouette's message mentioning restrictions on storing it on an encrypted file system, Richard Stallman said

That's a new one on me. I don't think the GFDL restricts the use of encrypted file systems.

He further clarified the reason for this.

This means that you cannot publish them under DRM systems to restrict the possessors of the copies. It isn't supposed to refer to use of encryption or file access control on your own copy.
I will talk with our lawyer and see if that sentence needs to be clarified.

However, he has declined to comment on the changes that are being contemplated.

I've decided not to do that. The development of GNU licenses is not a Debian issue.

The issue of outright banning DRM mechanisms remains a concern. It has been argued that by itself it is a violation of the DFSG.

Andrew Suffield comments:

Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. I consider the GFDL to have gone too far.


Back to the GFDL:

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.


Matthew Garrett notes:

This does apply to CDs as well, as they're considered to have covers. However, section 7 prevents this from being an extra issue with aggregated works.


Back to the GFDL:

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.

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 computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.


The following is from Jeremy Hankins:

Under certain circumstances the document may not have a transparent version (for example, after being modified with a proprietary word processor). This would make it impossible to meet the requirements of section 3 ("Copying in quantity") of the GFDL.

Anthony DeRobertis adds:

The perceived problem is this: Let's say I want to put a GFDL document on my FTP site, in an opaque form. My FTP site is popular, so it will distribute copies numbering more than 100.

I think its reasonable that if I just put a transparent form alongside the PDF, that should be all I have to do. Instead, the GFDL seems to read that I must somehow "include a machine-readable Transparent copy" (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for (forgive me if I'm mistaken about the time) one year.

Basically, the problem is if the answer to this question from the GPL FAQ applies to the GFDL as well.


Back to the GFDL:

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  • A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

Matthew Garrett notes:

A restriction, but free under DFSG 4.


Back to the GFDL:

  • B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
  • C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
  • D. Preserve all the copyright notices of the Document.
  • E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
  • F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
  • G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
  • H. Include an unaltered copy of this License.
  • I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
  • J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
  • K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

Matthew Garrett notes:

Unmodifiable content - fails DFSG 4.

Anthony DeRobertis adds:

Clauses b and i above seem to prohibit anonymous modifications to a document. If the requirements about listing authors on the title page and the history require an actual name, it seems this might fail the Chinese Dissident Test.


Back to the GFDL:

  • L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

Matthew Garrett notes:

Unmodifiable content - fails DFSG 4.

Anthony Towns states:

The GNU FDL includes a number of conditions that apply to all modified versions that disallow modifications, particularly sections K and L above. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, which state:

	    3. Derived Works

	    The license must allow modifications and derived works, and
	    must allow them to be distributed under the same terms as the
	    license of the original software.
	  

As such, we cannot accept works that include "Invariant Sections" and similar unmodifiable components into our distribution, which unfortunately includes a number of current manuals for GNU software.

Thomas Bushnell, BSG, has posted the following

Thomas Bushnell, BSG, in an email message, commented, in part: It is not possible to borrow text from a GFDL'd manual and incorporate it in any free software program whatsoever. This is not a mere license incompatibility. It's not just that the GFDL is incompatible with this or that free software license: it's that it is fundamentally incompatible with any free software license whatsoever. So if you write a new program, and you have no commitments at all about what license you want to use, saving only that it be a free license, you cannot include GFDL'd text.

First, GFDL'd manuals can contain "invariant sections" which cannot be changed or removed. This is a restriction on modification which isn't permitted for free software licenses. Moreover, it is not a trivial restriction or one that imposes minimal costs. Invariant sections can be very large, and the pieces of a GFDL'd manual that one wants to copy might be small. (For example, a description of how to use a single function, if copied from the Emacs manual, requires the inclusion of many kilobytes of extraneous text from invariant sections.) Such restrictions are not allowed in free software licenses.

Second, there are restrictions on what formats a GFDL'd manual can be distributed in, which work to prohibit encryption and the like. No such restriction exists for free software licenses.


It seems to me that the desire to have these sections is to piggy back political sections on to technical documentation. In other words, there is a captive audience, and since they need the documentation, they are being forced to also accept political speeches with it. This does not sit well with a project like Debian, since our charter includes keeping in mind the needs of our users; and protecting users from being forced to accept contents unrelated to the code the manual is documenting seems to be in line with what we do.

This is an expansion of something that Brian T Sniffen suggested

Analogous to the software programs freedoms, we need to articulate the freedoms required for the subset of software called documentation

  1. The freedom to read the text, for any purpose.
  2. The freedom to study how the text is written, and adapt it to your needs. Access to the text in the preferred form for modification is a precondition for this. This includes the ability to modify the work to fit in low memory situations, reference cards, PDA's, embedded devices, etc.
  3. Freedom to reformat the document into a preferred format or medium (converting to braille, or speech, or hardcopy, or postscript, etc).
  4. The freedom to redistribute copies so you can help your neighbor.
  5. The freedom to improve the text, and release your improvements to the public, so that the whole community benefits. Access to the preferred form for modification is a precondition for this. For program documentation, this implies being able to change the documentation to reflect the changes in the program.
  6. Freedom to translate the text into any other language (Esperanto, Hindi, Icelandic).
  7. The freedom to keep your modifications, or even your possession of a copy of the text, confidential.

Back to the GFDL:

  • M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

Matthew Garrett notes:

Unmodifiable content - fails DFSG 4, but can be removed so that's not a problem.


Back to the GFDL:

  • N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

Matthew Garrett notes:

Fails DFSG 4?


Back to the GFDL:

  • O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.


Matthew Garrett notes:

Restrictions on the contents of things that are "special" under the license. This doesn't prevent you from putting extra stuff on the front cover anyway, so isn't a problem.


Back to the GFDL:

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.


Nathanael Nerode notes:

Invariant Sections and related problems

The other problems with freeness lie in the rules on "Invariant Sections", "Cover Texts", "Acknowledgements", and "Dedications". These are not modifiable, and not even removable. First of all, the Invariant Sections are clearly not freely modifiable themselves, which means that they are not free in the "free software" sense of the GPL. Since they are "Secondary Sections", off-topic by definition, some people may not care about that.

But Invariant Sections and Cover Texts constitute a restriction on the modifiability of the technical material -- the documentation -- in the GFDL-covered document, because they can't be removed, ever. The documentation is forever shackled to the Invariant Sections. This makes documentation licensed under the GFDL with Invariant Sections not free (in the sense of 'free software' as used in the GPL).

Clearly not all restrictions on modification make a work non-free; some are trivial. (The requirement to accompany any version of the work with accurate copyright notices and copies of the license, for instance, is a trivial restriction). But this is not a trivial restriction; it is a troublesome one for many reasons:

  • Being forced to retain inaccurate Invariant Sections (or Cover Texts, or Dedications).
  • Being forced to retain obsolete Invariant Sections (or Cover Texts, or Dedications).
  • Being forced to retain technically inappropriate Invariant Sections or Cover Texts, etc. (I had been informed that this had happened with the Wikipedia, but this is apparently not correct.)
  • Being forced to retain Invariant Sections even in extremely space-tight environments (such as a reference card). (The President of the FSF has indicated that he believes this would be satisfied by accompanying the reference card with a "second volume" containing the Invariant Sections. This is, however, a very questionable interpretation of the text of the license.)
  • Being forced to retain untranslated Invariant Sections in a translation.
  • Being unable to use material from the document for a new document whose primary topic is that of an Invariant Sections (because the Invariant Section must be retained, and must be Secondary, but would no longer be Secondary).
  • Invariant Section "bloat". The natural response to several of the above problems is to add new Invariant Sections, saying "I think the old Invariant Section is inaccurate/obsolete/offensive" or "This is a translation of the old Invariant Section". These will accumulate and will also be non-removable.

Because the GFDL with Invariant Sections or Cover Texts is non-free, the Debian project is considering removing all manuals under such licenses from Debian.

Beyond its non-free status, the GFDL has additional serious practical problems:

  • It's GPL-incompatible in both directions. This means that you can't legally extract text from a GFDL'ed manual and put it into integrated help strings in a GPL'ed program. And you can't extract code or comments from a GPL'ed program and put it into a GFDL'ed manual. (Without getting explicit permission to relicense from every copyright-holding contributor, that is.)

Please see Nathanael Nerode's page for additional details.


Back to the GFDL:

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.


Matthew Garrett notes:

If I submit a patch to GCC including documentation with an invariant section describing why "Open Source" is a preferable term to "Free Software", the invariant section must be included if my documentation is to be used. Theoretically, this may not be an issue - pragmatically, it results in a situation where a patch under the same license as the original documentation cannot be accepted (although in the gcc case I'd have to sign over the copyright to the FSF, who could then remove the invariant section).


Back to the GFDL:

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.


Matthew Garrett notes:

Requires a potentially large body of (say) English text in a foreign version. Awkward, but not really an issue for Debian due to it only applying to invariant sections.


Back to the GFDL:

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.


Practical problems with the GFDL: Barak Pearlmutter

  • incompatibility with the GPL.
  • not a full copyleft (because people can add invariant sections thus distributing the document under terms more restrictive than those imposed on the materials they received)
  • lack of clarity (even debian-legal can't figure it all out; even the FSF makes mistakes in labeling invariant sections; even wikipedia used it incorrectly; even with lots of helpful explanations from RMS himself there is considerable lack of understanding on just what the GFDL actually requires)
  • possibility of obsolescence, via dated invariant sections
  • possibility of obsolescence, via changes in technologies (such as the disappearance of printed matter, or the particulars of file formats and access restrictions)
  • difficulty in modifying invariant sections of GFDLed documents not under unified central control (need permission from many contributors or their estates/agents, which becomes more difficult with time)
  • can be very difficult or impossible to repurpose chunks (eg copy regexp chapter)
  • does not "lead by example" (if all software used the GPL, all code would be freely available and sharable. if all documentation used the GFDL, differences in invariant sections and cover matter would impede sharing. perhaps licenses should lead by example to the world we all want: a world where sharing is always unimpeded)
  • is causing a lot of fighting and bad feeling between people who have the same goal and who should be cooperating and helping each other

Some of these do not impact the FSF in its productions of manuals, due to the FSF's possession of copyright assignments, and its ability to "break the rules" as necessary. They would however affect more distributed groups attempting to communally maintain software that includes GFDL'ed documentation. They would even affect groups that want to exchange & share materials despite having highly divergent technical goals. As we all know, one of the FSF's central tenets is that everyone should have the right to modify and share. So it seems to me that these issues may concern the FSF even if they do not directly affect it.

Anthony DeRobertis adds:

Let's say that I fork a version of GCC. I think we all agree this is allowed under the GPL, and, indeed has been done in the past. I make significant changes.

Now, I need a manual for my new compiler fork. I naturally look to the GNU's GCC manual. However, there are two problems I see in particular:

  1. The FSF's Front-Cover Text is:

    A GNU Manual

  2. The FSF's Back-Cover Text is:

    You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.

I see this as a problem because my new manual has to include false statements on the covers. It isn't a GNU manual anymore, and the FSF certainly doesn't publish copies. Putting "A GNU Manual" on the cover would, I think, be a violation of Title 15, Sec. 1125(a). So, as a consequence, I can not distribute my manual at all.

I'm not sure I can modify GNU manuals at all with those front and back cover texts, because the moment I do, those texts are no longer true.

Riku Voipio adds:

Adding a GFDL document to rescue disks may prove impossible as the document may not fit in the disk with the invariant sections included.

Survey conducted on debian-legal mailing list by Branden Robinson

In August 2003, the following survey was posted to the debian-legal mailing list, requesting the opinion of subscribers regarding one of a pair of related questions that have been asked with increasing frequency on that list, and in a few other forums around the Internet.

Does the GNU Free Documentation License, in its current form, satisfy the Debian Free Software Guidelines?

The survey included four possible answers to this question; they included three answers that represented points of view that I have seen on the debian-legal mailing list as the GNU FDL has been discussed over the past two years, and a fourth option was included so that people whose opinions were not represented could indicate their dissatisfaction with the alternatives.

The four possible answers were:

  1. The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is not a license compatible with the Debian Free Software Guidelines. Works under this license would require significant additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS.
  2. The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is a license compatible with the Debian Free Software Guidelines. In general, works under this license would require no additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS.
  3. The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, can be a license compatible with the Debian Free Software Guidelines, but only if certain restrictions stated in the license are not exercised by the copyright holder with respect to a given work. Works under this license will have to be scrutinized on a case-by-case basis for us to determine whether the work can be be considered Free Software and thus eligible for inclusion in the Debian OS.
  4. None of the above statements approximates my opinion.

The above answers can be crudely summarized as "no", "yes", "sometimes", and "none of the above".

Each respondent was also asked to indicate whether he was a Debian Developer as described in the Debian Constitution as of the date of the survey, and asked that people who so indicated GPG-sign their replies so that this claim could be verified.

Here are the results of the survey.

DFSG and the GFDL Survey Results
  developers possible developers non-developers
option 1 ("no") 18 3 22
option 2 ("yes") 1 0 1
option 3 ("sometimes") 8 4 4
option 4 ("none of the above") 1 0 1

Possible developers are people who claimed to be Debian Developers but did not have a well-formed GPG signature on their responses, so I was unable to verify their claims.

Possibly the most satisfying result for me personally is that so few people selected option 4; I can have at least some hope that my survey was not defective.

It would appear at present, though, that the GNU FDL is not regarded as a license that can easily satisfy the Debian Free Software Guidelines, if at all. The consensus among developers is approximately 2:1 (slightly more if the unvalidated votes don't count, slightly less if they do) that the GNU FDL cannot be rendered DFSG-compliant with respect to a given work unless the copyright holder is willing to extend significant additional permissions. Even the "sometimes" votes among our Developers do not indicate that we should stamp all GNU FDL-licensed works as DFSG-free without a second glance. Instead, their responses indicate that we must give GNU FDL-licensed works heightened scrutiny -- with even more care and diligence than we normally give the works we include in our distribution. It may be the case that none of the GNU FDL-licensed works currently distributed in Debian main satisfy even the more (presumably) generous criteria that the Debian developer minority would apply. More consideration is needed in this area.

Interestingly, it may be the case that our users, whom we claim to prioritize co-equally with Free Software in clause four of Social Contract, are asking us by an even larger super-majority than we can muster, not to overlook the defects in the GNU Free Documentation License on their behalf. The non-Debian Developers who replied to the survey expressed strong opposition (greater than 3:1) to the notion that the GNU FDL is a DFSG-compliant license. I personally find this data significant. We may be doing our users and the Free Software community a disservice by continuing to distribute GNU FDL-licensed works in Debian main.

Software, as opposed to hardware, encapsulates documentation

This commentary is from Branden Robinson.

A recurring theme (the other of the "related questions" I mentioned above) throughout recent discussions of the GNU FDL on the -legal mailing list have been vigorous challenges to the notion that we, the Debian Project, should bother to apply the Debian Free Software Guidelines to "documentation" at all. Advocates of this position frequently note that clause one of the Debian Social Contract refers to "software", not "documentation". These advocates also just as frequently fail to indicate what alternative guidelines, if any, should be used for evaluating licenses on works in the Debian GNU/Linux Distribution that are not "software". Bruce Perens, the primary author of the Debian Social Contract and Debian Free Software Guidelines, indicated in a recent message that he "intended for the entire contents of that CD to be under the rights stated in the DFSG - be they software, documentation, or data."

In my opinion, and in the opinion of several other people on the debian-legal mailing list, if we are to deviate from the understanding that "everything" in Debian main (apart from legal notices that we are required to include where applicable) must satisfy the DFSG, then we, as a Project, must draft a General Resolution to alter the Social Contract and say what we mean. If the best thing for the Debian Project to do is not to apply the Debian Free Software Guidelines to all works in our distribution, so that our distribution is not "100% Free Software", but rather "a collection of Free Software and other works", then we should draft and vote upon a General Resolution amending the Social Contract to that effect.


I, too, feel that the distinction between data, documentation, and program code is far from clear, with large amounts of grey areas. I have a program (for my day job), where we have pluggable probes deployed by a sensor program, as and when the sensor deems fit. Initially, the sensor does not know how many probes have been installed on the local machine, it goes out and discovers the number and nature of the probes in an initial resource discovery phase.

Each probe, when installed, installs an XML document that can be converted into HTML or PDF by applying a simple xsl transform; this is where all the documentation about the probe lives. Sounds like this is documentation, no?

The sensor reads the same file, applies another xsl transform, and gets to know the capabilities of the probe, and how to classify it, and publishes the data to a central trading service. Sounds like configuration data, no?

Now, when a request for data comes in, a generic probe handler is deployed, which reads the same file, applies a transform, and is handed a series of instructions on how to deploy the probe and communicate with it. Sure sounds like program code.

The documentation of the probe lists the access methods and protocols that one can talk to the probe; this is the documentation part. The sensor parses the same bits to determine the capabilities of the probe, and publishes that as data to a central trading service. The very same bits are read by the generic probe handler, and with an xsl transform, is handed a series of instructions to deploy the probe. In all these use cases, exactly the same set of bits is used.

Then comes the matter of literate programming; I have a project QMS where all the printed documentation, HTML pages, manual pages, etc are extracted from program code using doxygen. There are several other literate programming mechanisms, where the code and documentation are inextricably entwined.

If we cannot disambiguate data, documentation, and program code, we can't defend the premise that there are rigid classifications of software which are feasible. If we cant distinguish between code and documentation, how can we aver that different freedoms are attached to libre documentation?

Related Links: (provided by Branden Robinson)

Names of people who agree with this statement

  1. Manoj Srivastava <srivasta@debian.org>
  2. Daniel Stone <daniels@debian.org>
  3. Denis Barbier <barbier@linuxfr.org>
  4. Joerg Jaspert <joerg@debian.org>
  5. Lukas Geyer <lukas@debian.org>
  6. Gergely Nagy <algernon@debian.org>
  7. Mario Lang <mlang@debian.org>
  8. Kalle Kivimaa <killer@debian.org>
  9. John H. Robinson, IV <jaqque@debian.org>
  10. Frank K├╝ster <frank@debian.org>
  11. Thomas Bushnell, BSG <tb@becket.net>
  12. Sam Couter <eddie@debian.org>
  13. Andrew McMillan <awm@debian.org>
  14. martin f. krafft <madduck@debian.org>

Manoj Srivastava <srivasta@debian.org>

Valid XHTML 1.0! Valid CSS!