Re: Non-english license and documents
On Mon, May 22, 2006 at 10:32:18PM +0800, Ying-Chun Liu wrote:
> Second, the javadoc documents coming with the source files are Japanese.
> Should I prune the documents or include them? How do I include them?
Please, keep them. Removing documentation is a disservice to the
users, even if only a part of them can read it. Only if an adequate
English version was available , pruning the Japanese docs would be
an option IMO (and only because ~99.9% of Japanese people have good
command of English).
> Should I seperate to another binary package like libjlha-java-doc(-jp)?
Do they take half a megabyte or more? Is the package a dependence of
something very popular? If no, increasing the size of "Packages" by
over 1KB per binary package would more than kill all potential
benefits of the split.
> But in every *.java (source code) the license is written in
> Japanese (same as the license shown on the Japanese page). Because
> I'm not good at Japanese, so I can't make sure the license in
> Japanese is free or not. Is there any way to deal with the problem
> without asking the upstream author to change the source files?
FTPmasters and our debian-legal mavens tend to REALLY look down upon
removing license notices from source files. If we have a license in
English that came from the author (and thus is legally binding), the
Japanese copy is harmless, and it will get compressed away by tar|gz
so disk space is not a concern as well. Of course, let's have a
Japanese-speaking person take a look at the text, but IMHO you don't
need to bother about any accuracy higher than "this looks to be the
same as the English version".
Cheers and schtuff,
 I hope that only few of you seen Polish perl manpages once
shipped with PLD. Unless somehow Mommy lied to me about my native
language, there must be something really wrong with those docs, as I
couldn't comprehend them at all. Gods be praised for ssh and the
English version of the mans.
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.