RE: FW: EOT-Lite File Format

Tab has got it absolutely right!

I am not a lawyer, but I had once been involved in a case related to alleged DMCA violation. Here is what I learned from it:
- let's assume there is a specification that calls something a "technological protection measure" and mandates implementations to enforce it by strictly following the process specified in the document. If implementer decides to violate the specified procedure, another party *may* be able to claim that technological measure is circumvented;
- let's assume the opposite - there is a specification that does not define any technological measures, and specifically calls for an opaque data chunk to be ignored even when one is present. In this case, there is *nothing* to circumvent - there are no technological measures, nada, period, end of story. Any compliant implementation is mandated to ignore a chunk of data it knows nothing about - how this case could possibly raise any DMCA concerns?

This is exactly what EOT-Lite specification is about. Classic EOT standard does not exist - it was merely a proposal that was rejected for various reasons. We used it as FYI document to create the EOT-Lite solution that is backward compatible with existing EOT implementations. Again, there will be _no_ technological measures defined in the spec, and all implementers are specifically mandated to ignore the chunk of data they cannot process. There is nothing to circumvent, and any attempt to bring DMCA into the picture is a scare tactics that, IMHO, only hampers the constructive discussion.

Regards,
Vladimir


> -----Original Message-----
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of Tab Atkins Jr.
> Sent: Monday, August 03, 2009 3:12 PM
> To: Dave Crossland
> Cc: www-font
> Subject: Re: FW: EOT-Lite File Format
> 
> On Mon, Aug 3, 2009 at 1:50 PM, Dave Crossland<dave@lab6.com> wrote:
> > 2009/8/3 Tab Atkins Jr. <jackalmage@gmail.com>:
> >> On Mon, Aug 3, 2009 at 11:41 AM, Dave Crossland<dave@lab6.com>
> wrote:
> >>>
> >>> I see no difference between a browser that implements EOT as
> submitted
> >>> to W3C 18 months ago and ignores root strings, and a browser that
> >>> implements EOTL as submitted to W3C in 6 months time and ignores
> root
> >>> strings when it sees them.
> >>
> >> any rootstrings embedded in the 'padding' area of an EOTL file
> >> *are not rootstrings*
> >> ...
> >> In the hypothetical EOTLwrip (with-rootstrings-in-padding)
> >> format we're talking about, there are no rootstrings.
> >
> > Any rootstrings are not rootstrings.
> >
> > In the with-rootstrings-in-padding format there are no rootstrings.
> >
> > 2 + 2 = 5.
> 
> Dude, put scarequotes around the appropriate parts if you want.  You
> know what I meant.  Rootstrings-intended-to-be-enforced and
> padding-data-that-looks-like-rootstrings-from-the-corresponding-EOT-
> format
> are different things.
> 
> I mean, honestly, did you really think I was contradicting myself
> within-sentence *twice*?
> 
> >> There is only
> >> padding data which may be interpreted differently by certain legacy,
> >> nonconforming browsers.
> >
> > Your proposed W3C Recommendation says that these rootstrings are mere
> > padding. A font vendor has distributed a million EOTLs with such mere
> > padding containing rootstrings for stale MSIE. They are nearing
> > bankruptcy and have only enough equity left to hire some lawyers and
> > sue a wealthy browser developer before any more activity risks
> > becoming fraudulent trading. Welcome to the collapse of the American
> > empire!
> 
> It's not like we can stop idiots from suing whomever they wish and
> wasting everyone's time and money.  If that's your definition of
> collapse, then America's been long gone.  ^_^
> 
> However, the EOTLwrip spec will say there are no rootstrings (there's
> just padding data that must be ignored).  EOTL1.1 has no *possibility*
> of containing 'rootstrings', in padding or not.  All modern browsers
> will correctly ignore such 'rootstrings' lying in the ignored padding
> area of EOTLwrip.  There's no case there.
> 
> ~TJ

Received on Monday, 3 August 2009 20:03:37 UTC