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

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


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

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

Reply to: