[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

First Draft proposal for modification of Debian Free Software Guidelines:

A few things first:

1. I am not a Debian Developer, so I can not formally propose a GR or a foundational document amendment. I have, however, had a long-time involvement in the project, and have assisted in project-related activities, such as developing the current standard resolution process. So while I'm not able to formally do anything, I'm not coming completely out of left field.

2. This is a very first draft. There will likely be suggested changes; there will likely be complete overhauls. I'm not committed to the form, just the principles. Given good arguments, it's probable that my stand on the principles can be modified. I'd rather see a version we all can like go forward than stubbornly stand behind a flawed proposal.

3. I've been reading too much GrokLaw lately. It seems like it's had an effect on my writing style. If you don't like numbered paragraphs, I apologise....

(Draft) Proposal for Modification of the DSFG to allow certain forms of documentation, fonts, and other matters that don't conform to the existing DSFG into Debian.

I propose that the DSFG be amended by the addition of the following numbered sections. Comments in brackets [like this] are not part of the amendment, but rather clarify references in the proposal:

---- Additions to the DSFG ----
11. Documentation and other written materials.

  Documentation and other written materials that are not programs are
  not required to meet guideline 3 [Derived works] fully.

  a.  Certain other types of written materials may restrict derivative
      works, but must allow repackaging or reformatting in ways that do
      not change their written content:

     (i)   Standards documents, such as IETF RFC documents, published
           star catalogs, and certification test suites.
     (ii)  Legal documents, such as licenses, contracts, judicial
     (iii) Opinion documents, such as the GNU Manifesto or position
           papers that have no technical content

  If a document contains multiple sections that only some of fall under
  the exception above, only those sections may be exempt from allowing
  Derived works.

  In particular, documents (or sections of documents) which describe
  the operation or function of other software must allow creation and
  distribution of derivative works as per guideline 3 to the extent
  that the describes software does.

12.  Images, fonts, and sounds.

  Images, fonts, and sounds do not have to comply with guideline 2
  [source code] fully.  (This is a compromise.  The Debian Group
  encourages all authors to provide source code for all software,
  including images, fonts, and sounds).

Special Exception for Non-Free Firmware provided with the Linux Kernel.

  As a specific exception to the above guidelines, The Debian Project
  recognises that some Linux Kernel hardware drivers contain firmware
  and other software that is not Free Software by these guidelines.
  Many of these drivers are included with the standard Linux Source
  distribution.  Strict adherence to these guidelines would prevent us
  from including the unmodified upstream source code for the Linux
  Kernel, and would require us to remove support critical to many of our

  Therefore, we allow into the Debian Project any non-free software
  included in the standard Linux Kernel distribution solely for use
  within Debian as part of the Linux Kernel.

------- End Additions to the DFSG -------

Because this resolution changes a foundation document, it requires 3:1 majority approval

------- End Draft Proposed GR ---------
------- Memorandum in Support of Proposed GR Amending the DSFG -------

Memorandum In Support of the Proposed GR Amending the DSFG to allow certain non-modifiable documents into the Debian Distribution.

I. Overall purpose and justification for amending the DSFG

1. The Debian Project's Social Contract commits Debian to distributing Free Software, but rightly defers the definition of what is "Free Software" to the Debian Free Software Guidelines. As such, when controversy arises over Debian's ability to keep that commitment, attention should not be directed at the Social Contract, but rather to the Debian Free Software Guidelines.

2. In the past, the issue of documentation, fonts, images, sound files, and other non-program type files was "dealt with" by treating them as if they weren't "software". Recent changes in the Debian Social Contract clarified the issue by making it clear that everything in the main Debian Distribution was "software", forcing all documentation, fonts, images, sound files, and other non-program type files that did not conform with the DSFG to be removed before release (at least, in the opinion of the release manager.

3. Since the issue of the "freeness" of documentation, fonts, images, sound files, and other non-program type files is now clearly a "software" issue, it makes sense to clear up the situation by adapting the DSFG to the needs of these types of software, if it is of benefit to the cause of Free Software.

4. It is my opinion that the DFSG is a tool towards an end, not the end in itself. To the degree that the DSFG does not support the cause of Free Software, it should be subject to modification. I take as a starting point that the cause of Free Software is best expressed by the Four Freedoms written by Richard Stallman and the Free Software Foundation.

5. The "Four Freedoms" of Free Software are: (0) The freedom to run the program for any purpose; (1) the freedom to study how the program works, and adapt it to your needs; (2) the freedom to redistribute copies so you can help your neighbor; and (3) the freedom to improve the program and release your improvements to the public so the whole community benefits. (see http://www.gnu.org/philosophy/free-sw.html)

II.  The Benefit of Non-Modifiable Documentation.

6. This software was tolerated in the past in part because by their nature the "four freedoms" of software are not necessary, and are sometimes antithetical, for their support of free software (in the form of programs).

7. For instance, it is well known that open and public standards have historically played a strong role in the development, adaptation, and strength of Free Software. Closed or proprietary standards can rightly be considered antithetical to Free Software. To be able to distribute open and public standards to our users can only have a positive benefit in the cause of Free Software -- for much the same reason as collecting and distributing Free Software does.

8. At the same time, requiring the ability to create and distribute modified versions of open and public standard threatens the utility of the standard in the first place. It is of more use for a mail application to say that it is fuly compliant with RFC 822 when the user reading that doesn't have to worry about if the developer was using the unmodified IETF version, or the Microsoft version, or the Debian version.

9. The unchanging nature of standards documents is critical to their utility and a major reason why the IETF makes it a policy to never issue more than one version of any RFC -- future versions of the standard get a new RFC number. Likewise, standards documents issued by the W3C, by IEEE, ANSI, ISO, etc, all are designed to be superceded but not modified.

10. As written, the Four Freedoms apply to programs, and their utility towards other documentation is limited. I have already described how Freedom (3) is problematic for standards documents. It is similarly problematic for the other classes of documents I have outlines above. In general, it is problematic for any sort of document where the utility of the document comes from everyone having access to the same document.

11. For accurate communication of opinions, it is important that everyone have the same text of the opinion so that the opinion does not get mistranslated or changed (intentionally or unintentionally).

12. A perfect example of this came up while I was writing this very memorandom. When looking for the "Four Freedoms", the first site on a Google Search on "Gnu Four Freedoms" was http://encyclopedia.thefreedictionary.com/Four%20Freedoms%20(software) which lists the Four Freedoms as "0. the freedom to run the program for any purpose; 1. the freedom to study and modify the program; 3. the freedom to copy the program; 3. the freedom to redistribute modified or unmodified versions of the program." This statement of the Four Freedoms strips out the social benefits of the Four Freedom inherent in Richard Stallman's original statement of the Freedoms, and eliminates the distinction between Freedom 2 and Freedom 3. Obviously the author of the Free Dictionary page thought they were correctly summarizing the Freedoms, but in doing so they detracted from their meaning.

13. Likewise, it is important that documents with legal significance, like licenses, it is important that the original text be maintained so that any subtleties of significance is not lost in the modification.

14. On the otherhand, it is important that documentation that goes hand in hand with programs be able to be modified as the programs are modified. If a developer chose to exercise Freedom 3 and release improvements of a program to the public, it is important to be able to modify and redistribute the program documentation to reflect that improvement. It is also important that a developer be able to modify the program documentation alone if that creates the necessary improvement, such as if the documentation did not reflect the actual behavior of the software.

15. For this reason, it is also clear that a blanket acceptance of documentation as non-modifiable is not desirable to support the Four Freedoms. But allowing an exception to the rule that documentation must be modifiable for classes of documentation that benefit Free Software while, or because of, being non-modifiable seems reasonable.

16. I believe that eliminating non-modifiable documentation entirely from Debian hurts, not helps, the cause of Free Software, and the DFSG should be modified to allow its inclusion.

III.  The Lack of Source Code for Images, Fonts, and Sounds

17. Another problematic area in the current distribution are images, fonts, and sound files. Many exist in the Debian Distribution that have no source code, but otherwise meet the guidelines of the DFSG.

18. It is less clear-cut that their inclusion benefits Free Software, but it is also less clear-cut that the lack of source code violates the Four Freedoms, either.

19. Source Code is is not directly mentioned in the statement of the Four Freedoms above. The FSF page listing the Four Freedoms states that "Access to the source code is a precondition for" Freedoms 1 (modify for your needs) and 3 (improve and release improvements for community benefit). Source code is therefore important for the purposes of being able to modify the software.

20. But while for programs the source code is typically distinct from the executable version of the program, with sound, images, and fonts there is often no such distinction. A JPEG or PNG file is directly modifiable in ways that a binary executable isn't.

21. Since sound, image, and font files are directly editable and don't typically have a source form separate from the binary representation, requiring source for them doesn't help further the Four Freedoms, as long as the ability to modify and redistribute is preserved.

IV.  Special Exemption for Linux Kernel Drivers.

22. This should easily be the most controvertial part of this proposal. Unlike documentation, images, fonts and sounds, the software allowed in this exemption cannot be justified in connection to the Four Freedoms.

23. That is why I chose to label it as a "Special Exemption" and to not number it like the other guidelines. I also chose to include the rationale for the exemption directly in the proposed DFSG, so that it is clear that this is not a guideline or a principle, but rather a known violation of our own principles.

24. I feel this violation is justified on pragmatic grounds -- it is important to Debian that we be useful to our users, that we provide unmodified source packages whereever possible, and that we support free software.

25. It is unfortunate that -- as distributed upstream -- the Linux Kernel isn't 100% Free Software. This is recognised as a problem not just by Debian, but also by the Kernel Developers themselves. Their approach is pragmatic -- support for non-free (and non-freeable) hardware is more important than strict adherence to free software.

26. Strictly adhering on this point to the DSFG would require us to split the upstream Kernel source into free and non-free portions. This would prevent users who wish to do so to verify that our sources are clean and unmodified from upstream. It would require us to pick and choose which drivers were and were not free and non-free. As the recent example with the Linuxant soft winmodem driver demonstrates, some drivers lie about their licenses, making the task of separating out free and non-free drivers non-trivial.

27. Legitimate concerns have been raised about the difficulty users will have if hardware drivers for their machines aren't available in the stock Debian Linux kernel, and the difficulties that this will raise with the installers.

28. I feel it is very likely that, if we do not waiver on this issue, Debian will ultimately fail as a GNU/Linux distribution. This would likely cause a fork in Debian that will support the Linux kernel more pragmatically, but without the same commitment to Free Software that Debian currently has. While the main, official Debian Project could, and would, continue to support GNU/BSD and GNU/Hurd systems, the majority of users and probably developers would likely switch to the Linux branch.

29. If, for the sake of the project, it is necessary to compromise our principles when dealing with the Linux Kernel, it is best that we are up front about it, and explain what we are doing, why, and the limitations we wil do. The added "Special Exemption" above does just that.

-------End Memorandum in Support of (Draft) Proposed Resolution.-------

OK, rip it to shreds.....

Reply to: