Re: Fonts WG Charter feedback

On Thu, Jul 2, 2009 at 5:17 PM, Thomas Lord<lord@emf.net> wrote:
> On Thu, 2009-07-02 at 15:48 -0500, Tab Atkins Jr. wrote:
>>  Thu, Jul 2, 2009 at 3:41 PM, Thomas Lord<lord@emf.net> wrote:
>> > A "problem" in the minds of some may be
>> > that if TTF and OTF are required then new
>> > commercial and non-commercial markets would
>> > likely follow for web fonts that work with
>> > all popular applications, yet which are not
>> > restrictively licensed.
>
>> > In other words, demand would rise for fonts
>> > with fewer restrictions and supply would
>> > follow, diminishing the pricing power of
>> > vendors of restricted-license fonts.
>
>> That will happen or not regardless of the webfont format chosen.
>
> Not quite.
>
> If, tomorrow, IE suddenly supported TTF/OTF the market
> I described would exist and have a lot of potency since
> there would be room for trade in font files that work
> in all major browsers and with all major desktops,
> printers, etc.
>
> In contrast, if tomorrow EOT became the standard,
> the appeal - the attraction of that market - would be
> significantly less and for a long time to come.
>
> There is a lot of talk to the effect that concerns
> TTF/OTF support will lead to "accidental piracy"
> are the main motivation for resistance to TTF/OTF.
> I am beginning to believe that that is not really
> the motivation but, rather, exclusion by incumbents
> against potential competitors is the driver.

TTF becoming the prevalent webfont format does nothing to licensing
terms, though.  It would probably simply be expedient to release fonts
with freeer licenses, just because it's more difficult to *enforce*
restrictive licensing under such an unrestricted format, but there's
not a single technical issue surrounding TTF that would suddenly
require foundries to switch to loose licensing.

>>   *No*
>> proposal floated in this group pays the slightest bit of attention to
>> distribution rights on the author's side.  They generally differ only
>> on the degree of effort a website *viewer* has to expend to download a
>> font they see on a website and use it on their computer.
>
> I'm sure I don't follow what you are trying
> to say there but it sounds interesting.  Will
> you please unpack that a bit (i.e., elaborate)?

Wow, maybe I've been reading everyone wrong, if two different people
aren't sure what I'm talking about.  ^_^

>From everything that I've read, from all the discussions about 'garden
fences' and such, it appears that the overriding concern in every
'restrictive' proposal is to limit what the website viewer can do with
a font used on a website.  It seems to be understood that the website
*author* can do whatever they want, and there's really no way to stop
them from using whatever font they want regardless of licensing.  The
foundries's concern seems to mostly be that website viewers will see a
cool font used on a website (licensed to the website owner for public
website use but not distribution beyond what is necessary for
display), then download it and use it on their own computer.  (A
subset of concerns resolve around authors hotlinking fonts used by
*other* authors, which is very similar in intent - it's a *consumer*
of the font, without any contractual relationship to the foundry,
using the font in their own works without a proper license by
exploiting the properly-licensed use of the font by the first author.)

Short of a truly strong DRM system, even the *appearance* of enforcing
licensing terms on a site author is impossible (and as most/all of us
recognize, you can't ever go beyond appearance - any DRM system can
and will be broken by a sufficiently motivated person, and can then be
relatively trivially bypassed by everyone else).  Few people even want
to *attempt* to do this, however, and in general there is a
significant sentiment that using fonts should be as simple as possible
for the author.

Basically, every restrictive format involves (and generally, is
dominated by) one or more of the following three approaches:

1. Purposely breaking interop with desktop OSes (EOT, any obfuscation
proposal, most compression proposals).

2. Making it clear that the font isn't intended for 'normal' desktop
use (renaming proposals, subsetting proposals).

3. Restricting what domains the font can be used on (rootstring
proposals, same-origin proposals).

None of these three are intended to limit the site author who buys a
font in any way; they're intended to prevent/discourage viewers and
authors of other sites from downloading and reusing a linked font
themselves.

(Even the raw TTF/OTF approach uses option 3, as the Webfonts spec
does or did say that fonts used with @font-face should have
same-origin restrictions.)

~TJ

Received on Thursday, 2 July 2009 22:42:03 UTC