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

Re: [DISCUSSION] SURVEY: Is the GNU FDL a DFSG-free license?

Scripsit John Goerzen <jgoerzen@complete.org>
> On Fri, Aug 22, 2003 at 12:06:26PM -0400, Jeremy Hankins wrote:

> > Unless I've missed something, so far there hasn't been anyone arguing
> > that the DFSG should not apply to documentation.

> 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.

> 1. Lack of a clear differentiation between source code and compiled form.

>    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.

>    As an example, I worked on a book in LyX, writing most of the code there,
>    and generating LaTeX code from it to print.  Many would say the LyX
>    document is the source and LaTeX is "compiled", and that I must then
>    distribute the LyX.

Such a scenario might cause problems with the GPL or even the LGPL -
but I fail to see how the current DFSG creates specific problems in
this case.

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.
We're not obliged to always use the specific (and in some cases
problematic) definition of the GPL - unless the license of the work in
question happens to be GPL, of course.

> 2. Automated or nearly-automated conversion from one format to another. 
>    Converting, say, a Python program into a C version is not really possible
>    save by rewriting the entire program.  But it's trivial to convert
>    documentation between all sorts of formats -- and formats that some may
>    think are hideous (ie, the HTML output from sgml2html or PostScript)
>    others may see as preferred.

>    One thing that I see as a requirement for free documentation is that it
>    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?

Certainly, if by a concentrated research effort I discover a way to
turn Python programs into maintainable C code, I would fully expect
any software license that calls itself "free" to allow be to run free
Python programs through the process and modify&distribute the result.

>    DFSG doesn't have any real rule to apply here.  Some might cite
>    "derived works", but if you just reformat it, it's not really derived.
>    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.

> 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

>    Is a document free if non-free software reads it best, but
>    free software is available to do a "reasonable" job?

Is this different from a program that can run without a certain
non-free library, but provides a more or less enhanced functionality
when the non-free library is present?

> Having said all that, I think that DFSG clauses 1, 3, 5, 6, 7, 8, 9 will
> apply, though should possibly be strengthened as I mentioned above.

I see no reason to exempt from #2. Availability of source, or
something that serves the role of source (in which case, I'll argue,
it *is* source for the purposes of DFSG#2) is important for
documentation as well as programs. Remember that the actual contents
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.

Henning Makholm        "*Dansk Folkeparti*, nazistisk orienteret dansk parti
                1941-1945, grundlagt af Svend E. Johansen og Th.M. Andersen"

Reply to: