Re: EOT & DMCA concerns

On Tue, Aug 4, 2009 at 12:38 PM, Thomas Lord<lord@emf.net> wrote:
> On Tue, 2009-08-04 at 12:23 -0500, Tab Atkins Jr. wrote:
>> Indeed, that's a potential problem if anyone were suggesting that
>> browser vendors should parse EOT files and ignore the rootstrings.
>>
>> I questioned the relevance of this because no one has suggested that.
>
> Which leaves the EOTL proposal in the uncomfortable
> situation of insisting that rootstrings be enforced -
> if not by honoring them then by rejecting any and all
> files that contain one.

Again, this does not follow from any preceding facts.

> Poor Håkon would be getting angry bug reports from
> people who use set ups that generate EOTC and who have
> heard that Opera has *some* kind of EOT support - so
> why do their fonts work in IE but not Opera?  And he'll
> be legally encumbered from changing Opera so as to
> satisfy the filers of those bugs.

And?  The bugs are essentially "support EOTC", which according to
Hakon Opera wouldn't do even if .webfont was the agreed upon interop
format.  I'm also guessing that Opera's received such bugs in the
past.

> Poor Dagget might eventually find that Firefox has
> had an EOTL bug for a year or two that results in
> the accidental rendering of some EOTC fonts.  Worse,
> perhaps resulting in some number of sites "in the wild"
> that rely on this bug.

This is a possibility.  However, it will likely suffice just to ensure
that the common EOT-producing programs produce files in a format
distinguishable from EOTL.

> There is a legal minefield surrounding strict
> EOTL unless there is broad agreement that the
> intention is for people to be free to implement
> EOTC while ignoring the "protection" features.

There is no such minefield, and your suggestion to 'fix' the
non-existent legal problem *will* cause legal problems.

>> In specific, the EOTL proposals do not suggest that.
>
> No, they suggest that UAs not implementing EOTC
> MUST reject EOTC files.

Um, yes.  If you don't support a format, you shouldn't accept the
format.  *You don't support it.*

I have no idea how this is non-obvious, or relevant to what is being
discussed here.

>> The EOTL1.1
>> format is based on an EOT version without rootstrings.  Even in the
>> hypothetical EOTLwrip format, a conformant application can distinguish
>> between EOTLwrip and plain EOT with rootstrings, and can correctly
>> enforce the rootstrings in the latter (or drop the file on the floor,
>> if they don't want to support rootstrings).
>>
>> The EOTLwrip format explicitly does not have rootstrings.  It has
>> several padding areas filled with explicitly meaningless bits.  There
>> is nothing at any point in the specification that is intended or
>> implied to act as a protection measure, no matter how meager.  An EOT
>> file with rootstrings cannot be confused for an EOTLwrap file in a
>> conformant application.
>>
>> The EOTL1.1 format explicitly does not have rootstrings.  It has
>> several padding areas filled with explicitly meaningless bits.  An EOT
>> file with rootstrings is formatted incorrectly for an EOTL1.1 file,
>> and will be rejected by a conformant application (at least, rejected
>> by the EOTL-parsing codepath).
>
>
> It's interesting that if a second browser
> happened to use exactly the same algorithms
> as IE to implement EOTL compatibility, they
> would be in patent trouble.

Only insofar as the MTX compression algorithm is still not freely
licensed.  Monotype has made it clear, in such a way as to satisfy
several Moz devs, that they'll license MTX sufficiently freely to be
used by GPL software if it is made part of an official spec.

MTX compression is not relevant to the discussion, however.

> And if a patch
> were made that disabled rootstring enforcement
> in that algorithm, they'd be in DMCA territory.

Yes, they probably would be.  That's why no one is suggesting that
anyone do so.  Again, relevance?

> EOTL is surrounded by a legal minefield.

You keep stating it, but you bring up only issues that are either
tangential (and generally already resolved satisfactorily) or simple
incorrect.

> And strict EOTL won't handle a single font
> that is found in the wild or the font output
> by any but one very recently written program.
> Which is an odd place to wind up when discussion
> of EOT variants was taken up to achieve downward
> compatibility.

You are being dishonest.  You've been part of the conversation since
the beginning, and are perfectly aware of what sense EOTL is
"compatible" in.  An EOTL file is compatible with existing browsers
with a large installed base and users who are slow to upgrade (IE6 is
2 versions obsolete, 8 years old, and yet still has 25% share by most
accounts).

EOTL consumers are not meant to consume existing EOT files.  They are
relatively rare on the open web, and most include features
(rootstrings) that several browsers do not with to support.

~TJ

Received on Tuesday, 4 August 2009 17:59:20 UTC