RE: The unmentionable

>From: Thomas Lord [mailto:lord@emf.net]
>Sent: Wednesday, July 29, 2009 11:46 AM
>
>What I said was simply that the Rationale for
>CORS for linked fonts in a Recommendation must
>almost certainly NOT mention "IP protection".

Yeah, I got that. But I don't know what that recommendation
will be, I don't know whether it will address hot-linking, CORS
or same-origin policy, and I don't know how e.g. whether those
things will be optional or mandatory so I'm not in a solid position
to worry about it intelligently today. I'm limited that way. Sorry.

So far, we know that font license language may recommend the mitigation of a certain use-case
(hot-linking), and that this specific solution is one of the options a particular font
vendor suggests as a way to address said use-case. That's it. I have not yet seen an
explicit or implicit statement demanding that this be specifically standardized
in a web font file format spec or else no fonts will be licensed. Or that this must
be the solution at the exclusion of any others. (I may have missed it though).

>I also said that if no other Rationale were offered,
>there would be objections to CORS (that would
>likely prevail, in my opinion).
>Finally, I offered two such Rationale and commented
>on their relative strengths.
>
>I see no reason for you to denigrate that contribution
>as a mere "debate [about] the philosophical suitability
>of CORS".

You're the one calling it denigration and adding 'mere' in front
of it. I am pointing out this exact solution has already shipped.
I think that's significant. If you don't, that's fine.

My priority is to address the issues raised by authors, font creators and
browser implementers based on the use-cases that need addressing. Possible objections
to requirements that may or may not exist in a recommendation that does not yet exist
on the assumption of one specific rationale come distant second. For *me*. You may want
to know what issues do matter to implementers and other stakeholders; or you may not.
If an implementer needs a standard document A to tell them whether they can
use standard B to solve a requirement, they shall speak up. If font vendors require
'IP protection' to be standardized, or will not offer their product in a new format
unless a certain use-case is prevented using a specific standard B, they will also
speak up, in time. Until then, we're speculating.

I do note that this would not be the first time a solution
implemented for reason X happens to fit unrelated requirement Y or
ends up used to solve problem Z without anyone waiting for a standard saying
it was OK to do so. And that I am perfectly satisfied with any solution that
a) helps all authors out there comply with what is likely going to be a common
requirement across web font licenses b) interoperates with existing implementations
and c) does so according to a standard that is already defined.

You may choose to take my priorities in some personal way. That's entirely your call.

Received on Wednesday, 29 July 2009 20:05:04 UTC