Re: First Draft proposal for modification of Debian Free Software Guidelines:
Buddha Buck's proposal fails several important goals.
It seems like a big sell-out, first of all. The list of things it
makes exceptions for is, well, exactly the list of things that are
problematic. It tries to simply carve out exceptions for any case
where people might want one, without taking seriously the task of
correlating it against our goals of free software.
For example, he accepts non-free firmware, on the grounds that "strict
adherence to [the DFSG] would prevent us from including the unmodified
upstream [kernel source]". That's hardly a compelling reason; we are
quite familiar with the need to do this kind of thing all the time.
And anyway, the Debian kernel-source packages have not be unmodified
upstream kernel source for as long as I can remember; they include
such patches as the maintainer thinks should be included. So any goal
of "purity" as measured against upstream is obviated on both scores.
For images, fonts, and sounds, he makes an exception for the source
code requirement. For many of these, there is no sensible source code
anyway, and so DFSG 2 doesn't require it. That is, the image is
itself the source code.
> 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".
This is not really true. We mostly ignored the issue, but they were
always software. We never said "oh, these aren't software". Instead,
they were under our radar screen, and we didn't kvetch about them.
> 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.
Yes, but we must do so with an end to the cause of Free Software.
> 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)
But notice that *we* think that "software" includes images, fonts, and
sounds too. And kernel firmware. So the requirement to study the
construction and be able to constructively modify them must apply here
as well. The fact that the FSF doesn't wish to apply these freedoms
to documentation should not deter us from doing so.
> 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.
This is not true.
> 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.
This is not true. We do not object to licenses that require
truth-in-labeling. So RFC 822 could say "If you change the document,
you may not call the resulting document an RFC, and you must make
clear that you have altered it from the original". End of problem.
> 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.
This is a reasonable thing, and a DFSG license could certainly require
it. But the current licensing terms are said to prohibit taking text
out of an RFC and using it in some other document, whether you call
that an RFC or not.
> 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.
But incorrectly.
> 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.
This is incorrect. It is solved entirely by truth-in-labelling
requirements.
> 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).
Again, easily solved by truth in labelling requirements.
Moreover, you ignore that the GFDL's invariant sections are also
unremovable.
> 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.
This argument could be made about *any* non-free program. Yet our
rule is that we do not put non-free programs in main, no matter how
useful they might make the resulting system.
> 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.
"Wherever possible" has always heretofore meant "when consistent with
the DFSG". Why should the kernel have a special rule?
Thomas
Reply to: