Re: Bug#451799: new evince cannot display Japanese characters correctly

[Kobayashi Noritada <nori1@dolphin.c.u-tokyo.ac.jp>]

Hi,

On Wed, 28 Nov 2007 13:33:07 -0800, Steve Langasek wrote:
> On Wed, Nov 28, 2007 at 02:43:34PM +0000, John Halton wrote:
> > On 28/11/2007, Michael Poole <mdpoole@troilus.org> wrote:
> > > Based on a quick look, these files establish a correspondence between
> > > different character set encodings.  Copyright protects creative
> > > expression.  What is the creative part of this mapping?  I can see two
> > > possible bases: character selection and ambiguity resolution.
> 
> > Can't speak for the US, but in the UK the standard for copyright
> > protection is somewhat lower than "creative expression". Generally, a
> > work merely has to be "original" (i.e. not copied from elsewhere).
> 
> > However, a file consisting of mappings of this nature probably
> > constitutes a "database" under UK law (and in other EU jurisdictions).
> > In that case it only attracts protection "if, and only if, by reason
> > of the selection or arrangement of the contents of the database the
> > database constitutes the author's own intellectual creation". I really
> > doubt that this file would meet that test, or that it would reach the
> > "substantial investment" test for the separate "database right".
> 
> > > That being said, I am not sure enough to risk it in court on my dime.
> > > I would hope that Adobe would be willing to provide the data with a
> > > DFSG-compatible license and/or a notice that makes it clear whether
> > > they think the mappings are protected by copyright.
> 
> > Well, quite. What I said above only goes to show how complex copyright
> > questions can become, and that's only looking at one jurisdiction. I
> > find it hard to believe Adobe could or would assert copyright here,
> > but I'm no more willing than you to be the one who tests that
> > hypothesis!
> 
> FWIW, I believe a search of debian-legal archives will show that we've come
> to the same conclusion before about copyrightability of non-creative
> databases, and are already shipping a number of these in Debian.

I have a question: can we regard CMaps as database?  Well, several
years ago, some Japanese developers paid attention to the fact that
CMaps are PostScript programs, not data tables like unicode tables[1].
Also, Adobe prohibits modification of that format as well as the
mapping.

BTW I have a news: Kenshi Muto (kmuto) asked GNU pdf developers about
how they intend to get a handle on the CMap issue.  The answer was
they could try to ask Adobe to relicense the maps (a formal petition
from the FSF)[2] and they proposed that they could do that along with
Debian in order to achieve a better effect[3].

IMHO (actually, Taketoshi Sano's opinion[4]), Adobe would like to
promote PDF (and PostScript), but would not like to increase
incompatible unique CMaps that will impair the credibility of the
format.  So, it would be better for Adobe to loosen up the license of
its CMap than to force FLOSS communities to create unique CMaps.  So,
formal petition would be a good measure.

(IANAL, IANADD, and TINLA, but I am one of Japanese guys who suffers
inconvenience from the CMap issue of PS/PDF. ;-) )

[1] http://lists.debian.or.jp/debian-devel/200104/msg00092.html (in Japanese)
[2] http://lists.gnu.org/archive/html/pdf-devel/2007-12/msg00001.html
[3] http://lists.gnu.org/archive/html/pdf-devel/2007-12/msg00003.html
[4] http://lists.debian.or.jp/debian-devel/200104/msg00160.html (in Japanese)

Many thanks,

-nori