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
[EMAIL PROTECTED]
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
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
[EMAIL PROTECTED] / [EMAIL PROTECTED]
