RE: Agenda, action items and suggested WOFF changes

Chris Lilley Wednesday, May 12, 2010 1:56 PM <chris@w3.org>:

>Neither the woff-creating software, nor the Web server, nor the browser or
other Web client, should be involved in
>policing, or rather attempting to police on the basis of inadequate
information, whether the font is being used
>within the terms of the license.

As a developer who faced a very similar issue during the creation of the
TTF-to-EOT conversion tool EOTFAST, I agree completely.
With EOTFAST 1.0, the question was what to do with a TTF that had the
embedding bit set to "Restricted". Should the tool create a useless EOT that
IE won't load? Should the tool simply decline to make the EOT? Should it
issue a warning identifying the issue?
The decision was made - and I believe it was the correct one - to be
entirely agnostic and just create the file, useless though it may be. And in
EOTFAST 2.0 it will be the same way - the embedding bits will continue to be
the only condition pertinent to making a working EOT file that *won't* be
identified to the user via an error message or advisory of some kind.
Thus, the tool remains completely agnostic as to licensing issues - leaving
the issue clearly where it belongs - in the hands of the font's creator or a
licensee. Whatever the embedding bits are, they are.

>If the WOFF specification has to say anything about the embedding bits, it
should solely be to clarify that
>these do not apply to Web usage.

As of late, web standards have been cited as a kind of common law used to
bolster arguments in the legal sphere. I would certainly be concerned about
the exact phrasing of anything about the embedding bits. Particularly if it
could be taken to imply that the embedding bits apply in other contexts
outside of "web usage". And how does one define "web usage", anyway? Does
that include what users normally expect to see happen when they click
"Print"?

At the moment, I don't see what any language about the bits would help
clarify. I don't see a compelling need to run the risk of varying
interpretations which, as we've seen with the language in the OT spec, can
all too easily be a consequence when a technical spec tries to step outside
technical boundaries.

Regards,

Rich

-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of
Chris Lilley
Sent: Wednesday, May 12, 2010 1:56 PM
To: Sergey Malkin
Cc: public-webfonts-wg@w3.org; www-font@w3.org
Subject: Re: Agenda, action items and suggested WOFF changes

On Tuesday, May 11, 2010, 8:09:22 PM, Sergey wrote:

SM> For me, new definition is as confusing as definition of
SM> "document" we had problems with before. I would leave all this to
SM> EULA language and not try to formalize it. 

I agree with that. The final arbiter has to be the actual license agreement
between the organisation  or individual creating the font and the
organisation or individual using it on the Web.

Neither the woff-creating software, nor the Web server, nor the browser or
other Web client, should be involved in policing, or rather attempting to
police on the basis of inadequate information, whether the font is being
used within the terms of the license.

That is a legal matter, not a technical one, and is entirely between the two
organisations involved (or, if they disagree, their respective lawyers).

If PDF embedding applications have settled on a machine-readable
interpretation of that license for PDF embedding then fine, but

a) that is a whole different case from Web use
b) we shouldn't muddy the waters there by redefining or adding bits

If the WOFF specification has to say anything about the embedding bits, it
should solely be to clarify that these do not apply to Web usage.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 13 May 2010 17:11:14 UTC