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
opinions
(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
users.
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: