Re: A new practical problem with invariant sections?
On Sun, Feb 12, 2006 at 07:31:20PM -0500, Anthony DeRobertis wrote:
> I don't recall the following example being brought up.
Thank you for this example. It was new and I liked it because it is
not as abstract as most of the other examples.
> Let's assume a manual, written by in Japanese, with Japanese invariant
> sections. Someone translates this manual to English. The translator, of
> course, leaves the Japanese invariant section intact.
> Now, I'd like to download this (translated) manual and place it on a
> portable device I own, so I can easily read it without killing a bunch
> of trees. I think this is clearly a useful modification, and I think
> that I should be able to do this for a DFSG-free work.
> But, there is a problem: My portable device understands only ASCII, or
> maybe ISO-8859-1 if I'm lucky (at least in the US, this is pretty
> common). It doesn't understand UTF-8, Shift-JIS, etc. It is not
> technically possible to keep the Japanese invariant section.
Actually I can see here two different problems.
The first problem is that you are unable to install the document on
your device together with the invariant sections. This however is not
a real problem because you don't have to do this. I am not sure, but
I suppose Craig meant this in part of the discussion. GFDL does not
require from you to install the invariant sections on your device.
The other problem, on the other hand, is more interesting. How can we
distribute the document, respecting the requirements of GFDL, in a way
that is convenient for use on your device. I can see two ways for
The first way is to distribute the text in some encoding that supports
Japanese such as UTF-8. That way on your device you will be able to
read the English part of the document (which contains only ASCII
characters), but the non-English part will be visible to you in that
Ofcourse the users whose devices can read UTF-8 will be able to view
the text properly.
The second way to distribute the text exploits the fact that GFDL
doesn't place requirements about the format of the document. There is
no requirement acording to which the document must be included in only
one file. There is also no requirement to use same format for the
different files belonging to the document. This makes possible to
distribute the document in a bundle of two parts -- the part to be
installed on your device and the part that can not be read by your
Infact the described problem is very similar to the situation when
some invariant sections contains pictures. Ofcourse the plain text
files can not contain inline pictures, but this doesn't mean we are
unable to distribute such a document in plain text files. It is
enough to distribute the text and the graphical images in separate
files provided that the text includes references to the graphical file
names when appropriate.
Consider the HTML format -- it is text-only but can contain references
to graphical images. The graphical browsers include these images
inline but the text-browsers show the users only the names of the
images. The user decides whether to look at the image or not. The
plain-text files are similar case -- the text contains references to
the images and the user decides whether to look at them or not.
> I believe this gives a notable, practicle reason why invariant sections
> are not free.
I hope I managed to explain why in this interesting example the
invariant sections do not deprive our rights to read, to adapt, to
distribute and to improve.