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

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

On Fri, 22 Aug 2003 14:36:03 -0500, John Goerzen <jgoerzen@complete.org> said: 

> 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.  What
>> there has been

> I would hold that position.  But I caution people reading this to
> not assume that this means I believe documentation deserves lower
> standards.

> There are some properties of documentation that make it a
> fundamentally different beast from the software we deal with.  Some
> are:

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

	Hmm. I do not think a definition of freedom needs depend on
 such a demarcation, but perhaps I could be educated. 

>    This is, in my opinion, the largest problem with applying DFSG to
>    software.

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

>    But after a point, LyX became not versatile enough, so I
>    generated LaTeX from it, threw out the LyX code, and hacked on
>    the LaTeX from then on.

	Could you explain to me how this is radically different from
 internationalization of computer programs? Let me work along with
 your example, just to make a point. I wrote up a a program with its
 text strings in English, and it was translated into Polish by my
 collaborator, Vlad. 

	Now, since the program is distributed under a free license,
 Vlad continued to make improvements, even though I was busy, and he
 wrote up the docs in his native tongue, Polish. Since I have little
 time, the code is hacked on by Ivan, and the primary source of the
 program strings is now polish.

>    As a second example:

>    Somebody may take a HTML document, import it into Word, and
>    modify it there.  Is the Word document the new source?  What's
>    the compiled one?

	Why is the compiled form relevant? Which is the currently
 preferred form to apply changes to? If it is the word file, then sure,
 the word file is the preferred form to distribute (and other forms
 are created by converters that take word docs and write out html,
 xml, rtf, pdf, etc).

	Why this need to figure out what the compiled form is? You
 distribute the file format which is the primary source of creating
 the content, be it code, data, or documentation -- works for all
 manner of software, be it programs or documentation.

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

	Umm, I suppose one could automate the translation f program
 strings into another language, (witness the babel fish), though
 perhaps poorly, so the parallel holds.

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

	Or on program code toput a restriction on the languages it can
 be translated to. 

	Given UML, and some higher level programming languages peopel
 are flirting with, it may be feasible to automatically generate large
 protions of code required to implement complex systems in multiple
 languages from the abstract description of the models, and contracts,
 of the program being written. Of course, one still needs to convert
 manually the guts of the code, but let us not insist that code
 translation between languages is infeasible (no computer needs more
 than 640KB memory). But this is a digression. 

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

	You are given free software, and allowed to modify it as you
 wish, under the same terms as the original license. Pray tell, how
 does it not cover format changes? The DFSG does indeed require that
 this freedom be provided to users of documentation. 

> 3. Tool depencies.  Is a document free if it requires non-free
>    software to read?

	Is a program free if it requires a non free compiler to
 compile? Or a non free vortual machine to interpret it? Why should
 documentation be treated differently? 

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

	Is a program free if a non free compiler compiles it besat,
 but a free compiler is available that does a "reasonable" job? 

>    How far does "reasonable" go?

	Quite. How far does reasonable go? This is really important
 when it comes to kaffe, gcj, and j2sdk. Why is documentation any

	Frankly, I am puzzled: so far, every example you have given
 immediately brings to mind an almost exact equivalent from the
 program code side of software; and you do not seem to have made your
 case that software is indeed different.

When the government bureau's remedies don't match your problem, you
modify the problem, not the remedy.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: