Forward: Re: On the possibility of changing the license of Adobe CMap files
-----BEGIN PGP SIGNED MESSAGE-----
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
blocking?).
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
people.
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.
Regards,
MH
- --
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)
Hatta-san,
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
lunde@adobe.com
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iEYEARECAAYFAkAYvuIACgkQQKW+7XLQPLGAMwCgyiX+GwWY1LxN6tk4fixNhBYL
AC0AoODQBURkpUIJ98MVpBR+suoGlitq
=Rzo9
-----END PGP SIGNATURE-----
Reply to: