W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: Font license vs. conversion between font formats

From: Mikko Rantalainen <mikko.rantalainen@peda.net>
Date: Thu, 09 Jul 2009 12:00:45 +0300
Message-ID: <4A55B1BD.3080008@peda.net>
To: www-font <www-font@w3.org>
Tal Leming wrote:
> On Jul 8, 2009, at 6:50 AM, Mikko Rantalainen wrote:
> 
>> The fact that this "font filesharing host" distributes font data in
>> other format or in TTF/OTF format does not make any real difference.
>> Pretty much all pirated content is already wrapped inside ZIP archives
>> as far as I know. The fact that pirated content is usable only after
>> running a simple tool (unzip) does not seem to prevent people from using
>> that pirated content. Why do you think that replacing that tool (unzip)
>> with other tool (unwrap-the-other-font-format) would make it any harder
>> to pirate fonts?
> 
> I don't think it is a good idea to outright reject the idea of a
> different format because a party with malicious intent might do
> something to break it. If we did that with everything, there would be no
> rules or laws for anything.

If the *whole point* of different format is to protect the data it
contains and that different format does not protect the data, then there
is no reason, at all, to use that different format.

Am I correct that plain TTF/OTF files are not acceptable because "a
party with malicious intent might copy it"?

I'm trying to argue that if plain TTF/OTF is not acceptable format
because it does not offer protection, then any other freely usable
format is not acceptable either. As a result, if font foundries are not
willing to license for TTF/OTF usage, they will not be willing to
license to any system except a full-blown DRM (which does not exists).

If font foundries do not want protection (as has been claimed by many on
this list), then I would want a detailed list of features that are
*required* for font foundries to be happy. Then we can ask browser
vendors if they can implement those features (using TTF/OTF or some
other format). If font foundries cannot list the features that they
require, then I really don't see any point trying to implement features
that we guess they might want. Notice that creators and users of Free
fonts are happy with any format that they can implement. For example,
plain TTF/OTF works just fine.

Also notice that rules and laws have *always* a punishment for not
following those rules or laws. Copyright infringement (distributing
TTF/OTF files without a proper license) is already punishable by law.
Creating an another font format cannot provide additional punishments
for copyright infringement (unless that format is designed to also hook
to DMCA, which Mozilla has already declined to implement). An another
format cannot provide punishment outside the law, either. I would also
like to point out that creators of Free fonts are *not* usually giving
the fonts to public domain - instead they are licensing those fonts
under some specific terms. They can/will sue for copyright infringement,
too, if those license terms are broken.

However, if the new format has some other merit than "security" or
"protection", then it may be better than plain TTF/OTF. Using plain
TTF/OTF files would be the easiest method for the content authors
(because the author can use the same files locally and on the server).
On the other hand, plain TTF/OTF files are not compatible with any
existing MSIE version. As I see it, the only format that has *any*
change over plain TTF/OTF files is some variant of EOT that every vendor
can implement *and* that is backwards compatible with existing MSIE
versions.

Current merits of different choices as I see it:

- Plain TTF/OTF: easy for authors, already implemented by everyone else
but Microsoft

- Some variant of EOT: already implemented by Microsoft

- Other format: "protection" (anything else?)

-- 
Mikko


Received on Thursday, 9 July 2009 09:01:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:02 GMT