Re: [DISCUSSION] SURVEY: Is the GNU FDL a DFSG-free license?
On Fri, Aug 22, 2003 at 11:48:57PM +0200, Henning Makholm wrote:
> Scripsit John Goerzen <firstname.lastname@example.org>
> > I would hold that position. But I caution people reading this to not assume
> > that this means I believe documentation deserves lower standards.
> I think that if we find ways to fix the DFSG so it expresses freedom
> better, those fixes should not be restricted to documentation; they
> should be available for all applicable kinds of software.
Agreed on that.
> > This is, in my opinion, the largest problem with applying DFSG to
> > software.
> Yet we do routinely apply the DFSG to interpreted scripts where there
> is *no* differentiation between source code and compiled form.
Not really; it's just that the compiled form is often transient.
Though increasingly not: Python and Emacs, for instance, can both write out
a compiled form.
But anyway, documentation is not source code. That is my main quibble. We
cannot just magically say, "well gee, our DFSG only covers things with
source code, and this Emacs manual is a thing that we want to apply the DFSG
to, therefore it must be source code." That is incorrect reasoning. You
must first establish that there is source or compiled work, and *then* apply
the guidelines for source or compiled works to it.
I realize that people *can* go through intellectual contortions to make
documentation more-or-less fit into the DFSG, but as we have seen here, that
is neither a self-evident step nor a process that can reliably be applied
> DFSG #2 requires "source" but does not define it. Debian-legal will
> probably accept any format that the package maintainer can argue is a
> reasonable and non-obfuscated baseline for creating modified versions.
Which leaves us in the situation of basically accepting everything, or
handling everything on a case-by-case basis, neither of which is really a
The former is obviously over-broad, and the latter points to a lack of
clarity in guidelines.
> > must not place a restriction on formats (save for restricting those
> > formats that prevent free copying or modification).
> Then, if we are in the business of amending the Social Contract, why
> not make this requirement apply to all software?
Could be done too, I suppose.
> > A license could exploit this loophole.
> DFSG is just a set of guidelines, and as such cannot have "loopholes".
> We've always reserved the right to reject software as non-free even if
> it sticks to the letter of the DFSG (terse and fuzzy as that letter
> is), whenever we think it runs against the spirit.
True, but I would think it would be in everybody's best interest to make
sure this doesn't have to happen often.
> > 3. Tool depencies.
> > Is a document free if it requires non-free software to read?
> Is this different from programs that depend on non-free software to
To me, no, but the DFSG does not address the point.
> of DFSG #2 is to reject software which we have to distribute only in a
> non-modifyable (or not-easily-modifyable) form. This goes for
> documentation as well.
If we said it that way, it would seem a lot more honest to me than going
through the charade of calling any collection of bits "software".