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

Forward: Re: On the possibility of changing the license of Adobe CMap files

Hash: SHA1

Hi all,

Masayuki Hatta and some of Japanese are considering how to treat Adobe
CMap files. CMap is very important for CJK Ghostscript/PDF, but is
non-free on Debian because this license says 'not altered'.

Hatta has asked to Adobe has responsibility of this kind, and received
negative answer. He has already sent mail about this processes to
debian-legal/devel by Cc:, but something prevented his mail (SMTP

I post again the mail he wants to send.
Please add Cc: mhatta when you reply this thread.

- ---------- From here ------------------------
Hi all,

I was trying to negotiate with Adobe to make their CMap files (those
have been debianized as gs-cjk-resource, cmap-adobe-* and
xpdf-{chinese-*,japanese,korean}, all in non-free[*1]) DFSG-free.
Dr. Ken Lunde and other Adobe people deliberately inspected the issue
and rejected my request.  As I noted in the mail, those CMaps are
crucial for CJKV font handling and I couldn't find any easy
alternatives, so in consideration of recent "kick non-free out"
movement, this is more urgent and bigger problem than ever for us CJKV

Do you have any idea to cope with this situation?  Or does anyone come
up with possible proposal so that Adobe can be persuaded?  I
appreciate your help.


- --
Masayuki Hatta
mhatta@gnu.org / mhatta@debian.org / mhatta@opensource.jp

[*1] Basically, "no modification allowed" is the problem.  Similar to
those of GFDL with invariant cl. or RFC documents.

- -----------------------------------------------------------
Date: Mon, 26 Jan 2004 16:22:03 -0800
From: Ken Lunde <lunde@adobe.com>
Subject: Re: On the possibility of changing the license of Adobe CMap files
In-reply-to: <20040114144214.00CF017C79@arcadia.airs.net>
To: Masayuki Hatta <mhatta@po.airs.net>
Cc: APTechnician@adobesupport.com, tagoh@debian.org,
	board@debian.or.jp, debian-legal@lists.debian.org,
	David Lemon <lemon@adobe.com>, Harold Grey <hgrey@adobe.com>
Message-id: <D51CAD60-505E-11D8-8E31-00039375FDD0@adobe.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.553)


I apologize for taking so long to reply to this request, but we needed 
sufficient time to carefully consider the request, and to think about 
the consequences, both good and bad. The short reply is that we shall 
decline this request, for reasons explained below.

1) We have been meticulously managing the CMap files that we created, 
giving particular focus and attention to the Unicode CMap files over 
the past several years, and are also very carefully version-controlling 
them. We now support UTF-8, UTF-16, and UTF-32, including mappings 
beyond the BMP, for all of public character collection. The only CMap 
files that we are actively developing are the UTF (Unicode) ones. In 
fact, all of the CMap files are managed through UTF-32 encoding, and my 
CMap compiler automatically generates the UTF-8 and UTF-16 ones in 
order to ensure that all three types are 100% compatible, and differ 
only by encoding.

2) I can trace virtually all of the changes made over the years. We 
have spent significant effort developing these files. In short, the 
name space of CMap files is important, as well as their overall 
integrity. This is due to the fact that a large number of clients use 
these CMap files, and very much depend on their integrity.

3) I do understand the request that you have made, specifically to make 
these files freely modifiable, even in memory, in the form of patches 
that are applied on-the-fly. I also understand that this request does 
not necessarily mean that everyone will suddenly start modifying CMap 
files. They simply want the "freedom" to do so.

4) We are concerned about someone making a modification to a CMap file 
and failing at it, meaning that the CMap file either no longer 
functions due to a simple syntax error, or does not work as expected. 
It would become extremely difficult to track such problems, if they 
were to be reported. Such problems could also cause users to think that 
the fault lies with Adobe. Basically, as long as the name space of CMap 
files is preserved, and the CMap files are not modified, I can reliably 
trace issues through various versions. Making these files Open Source 
defeats this. If developers have specific requests for CMap files, I 
will consider them if they are reasonable. I consider my email box open 
in this regard. In fact, I very much like to hear from developers who 
are using our CMap files.

5) I consider the ability to freely modify CMap files comparable to 
redefining ASCII. There are incalculable ripple effects that can result 
from unwarranted modifications. While I am aware of many of the clients 
who are using our CMap files, there are undoubtedly numerous other 
clients of which I am not aware. These are the consequences that are 
not easily measured.

I don't consider it a bad thing to have our CMap files in a "non-free" 
area of Debian Linux. In fact, I consider it an honor that you have 
chose to include our CMap files in your distribution, even if it's in a 
"non-free" area. I am sure that there will always be some software in 
that category, so we will not be alone.

If you have further questions regarding what I wrote above, feel free 
to contact me at any time.

With best regards...

- -- Dr. Ken Lunde
    Senior Computer Scientist, CJKV Type Development
    Adobe Systems Incorporated

On 2004.1.14, at 06:45 US/Pacific, Masayuki Hatta wrote:

> To whom it may concern:
> First, we would like to express our gratitude for your continuous
> commitment to the excellence in computer publishing.
> Several important opensource software (most notably Ghostscript) have
> been using Adobe CMap files for handling CJKV fonts.  Therefore, CMap
> files are very crucial for us Japanese (and possibly other CKV)
> GNU/Linux users.
> By courtesy of your company, CMap files are currently allowed to be
> freely distributed under the license below:
> ------------------------------------------------------------------
>         All Rights Reserved.
>         Patents Pending
> NOTICE: All information contained herein is the property
>         of Adobe Systems Incorporated.
>         Permission is granted for redistribution of this file
>         provided this copyright notice is maintained intact and
>         that the contents of this file are not altered in any
>         way from its original form.
>         PostScript and Display PostScript are trademarks of
>         Adobe Systems Incorporated which may be registered in
>         certain jurisdictions.
> ---------------------------------------------------------------
> This is very liberal one and we really appreciate it.  However, the
> passage "the contents of this file are not altered in any way from its
> original form" somehow contradicts with "The Open Source Definition"
> (http://www.opensource.org/docs/definition.php) cl.3 or "Debian Free
> Software Guideline" (http://www.debian.org/social_contract#guidelines)
> cl.3, thus we classified it into "non-free" category.
> We should admit this is not really your problem.  However, please
> understand that assuring the possibility to modify files by licensing
> is very important for the opensource development model in general.
> We assume the phrasing here is not of extreme importance for you.  The
> emphasis might be put on avoiding reckless modifications and
> subsequent chaos of incompatibility. With taking it into account, we
> really appreciate if you could possibly consider to change the license
> in the following way:
> 1) To allow distribution of pristine, non-altered CMaps and "patches"
> for them.  Patches will be applied when CMaps are used.  In this way,
> modifications someone made are clearly distinguishable from the
> original one.
> 2) Allowing modifications on condition that it requires to change the
> file name.
> Again, thank you for your cooperation, and appreciate if you consider
> request.
> Best regards,
> Masayuki Hatta
> On behalf of Debian JP Project
> --
> Masayuki Hatta
> A Debian GNU/Linux official developer
> Translation coordinator, Free Software Foundation
> Graduate School of Economics, University of Tokyo
> mhatta@gnu.org / mhatta@debian.org / mhatta@opensource.jp
> ee36037@mail.ecc.u-tokyo.ac.jp / mhatta@cy.e.u-tokyo.ac.jp
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>


Reply to: