Re: EOT & DMCA concerns

On Tue, Aug 4, 2009 at 12:16 PM, Thomas Lord<lord@emf.net> wrote:
> On Mon, 2009-08-03 at 20:45 -0500, Tab Atkins Jr. wrote:
>
>> > A very simple solution is for the EOTL backers
>> > to make a positive statement that other browsers,
>> > if they are going to do EOTL because of a MUST,
>> > then SHOULD support all of EOTC (and have patent
>> > protection in doing so) because that rounds out
>> > the degree of compatibility with IE<=8.
>
>> I'm not seeing how that follows.  Can you elaborate why supporting
>> EOTC has any effect, positive or negative, on EOTL's risk of DMCA
>> action?
>
> In the MicroType v. Adobe case the court applied
> a 6 point test and concluded that the plaintiff
> had failed to prove their case.  The court dwelled
> a bit on whether two meta-data bits indicating
> licensing restrictions constituted an "effective
> technological restriction" (and decided that, no,
> they did not).  (The court found no shortage of
> defects in the plaintiff's case beyond that.)
>
> We can't conclude from the reasoning applied
> by the court in *that* case that the trival
> "breakability" of EOT protections is not an
> effective technological restriction.
>
> Indeed, if the mailing list archive of this
> list were admitted in to evidence it would show
> a discussion in which EOT protections are
> explicitly intended to be and believed to be
> an effective technological restriction - the
> "low garden wall".   So it is a far less
> clear cut case.

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.
In specific, the EOTL proposals do not suggest that.  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).

~TJ

Received on Tuesday, 4 August 2009 17:24:13 UTC