[GFD] Treatment of the OFL in the wild

[Vernon Adams]

Subject: [GFD] Treatment of the OFL in the wild
Date: 2 June 2013 18:47:57 PDT
This is a follow on to the recent thread "OFL-FAQ update draft and web fonts paper" that Victor Gaultney started.
I think this is all 'great', but these sites are also often not distributing the OFL along with the distributed fonts. Also of course, these sites don't make available source files, and are often making modifications to metadata but then not following the OFL on distributing modified fonts.
So i'm interested how other designers of OFL'd fonts see this, or how people in the wider FLOSS community see this situation? Does anyone not care? Anyone really unhappy about it? Some times i shrug and think 'so what?', but then i am also very aware that ignoring these breaches 'en masse' does perhaps undermine the integrity of the OFL itself. It's like we need a Libre Font Union or something ;)
-vernon
--
--
Google Font Directory Discussions
http://groups.google.com/group/googlefontdirectory-discuss
---
You received this message because you are subscribed to the Google Groups "Google Font Directory Discussions" group.
For more options, visit https://groups.google.com/groups/opt_out.

[Barry Schwartz]

This is a follow on to the recent thread "OFL-FAQ update draft and web fonts paper" that Victor Gaultney started.
I think this is all 'great', but these sites are also often not distributing the OFL along with the distributed fonts. Also of course, these sites don't make available source files, and are often making modifications to metadata but then not following the OFL on distributing modified fonts.
So i'm interested how other designers of OFL'd fonts see this, or how people in the wider FLOSS community see this situation? Does anyone not care? Anyone really unhappy about it? Some times i shrug and think 'so what?', but then i am also very aware that ignoring these breaches 'en masse' does perhaps undermine the integrity of the OFL itself. It's like we need a Libre Font Union or something ;)

IMO FontPro should be more explicit about licenses, because they offer
downloads. I haven’t downloaded a package to see what comes with it.

My opinion on webfonts is that they are being embedded in a document
and so everything is A-OK. Nothing more is required.

[Dave Crossland]

Post by Barry Schwartz
My opinion on webfonts is that they are being embedded in a document
and so everything is A-OK. Nothing more is required.

I'm curious why you think this, given the reasons Victor gave for it
not being the case in his document :)

[Khaled Hosny]

Post by Dave Crossland

Post by Barry Schwartz
My opinion on webfonts is that they are being embedded in a document
and so everything is A-OK. Nothing more is required.

I'm curious why you think this, given the reasons Victor gave for it
not being the case in his document :)

You can embed a webfont as base64 encoded string inside the HTML file.
Even the common case of just linking to the file is not much different
from bundling the font in the zip container of ODT or DOCX.

Regards,
Khaled

[Victor Gaultney]

Post by Khaled Hosny
You can embed a webfont as base64 encoded string inside the HTML file.

Good point, Khaled. That does sound like traditional embedding. The key differences from standard web fonts use are that:

- The font is delivered as part of the HTML file, not a separate resource
- The font is provided by the same server as the rest of the doc
- The font is used for only one document
- The font is always present, even if the doc is viewed offline

I'm not sure whether an embedded web font would be any more difficult to extract than normal web fonts. Anyone have thoughts on this?

These differences are significant. Nicolas has been out of the office for a couple of weeks. When he gets back in the office I'll talk with him about adjusting the FAQ and web fonts paper to address fonts delivered within the HTML file.

Post by Khaled Hosny
Even the common case of just linking to the file is not much different
from bundling the font in the zip container of ODT or DOCX.

I think it is. In a zip the fonts travel with the doc and they cannot be used by other docs unless you extract them.

V

[Dave Crossland]

Extracting the fonts is just as easy

Post by Khaled Hosny
You can embed a webfont as base64 encoded string inside the HTML file.
Good point, Khaled. That does sound like traditional embedding. The key
- The font is delivered as part of the HTML file, not a separate resource
- The font is provided by the same server as the rest of the doc
- The font is used for only one document
- The font is always present, even if the doc is viewed offline
I'm not sure whether an embedded web font would be any more difficult to
extract than normal web fonts. Anyone have thoughts on this?
These differences are significant. Nicolas has been out of the office for
a couple of weeks. When he gets back in the office I'll talk with him about
adjusting the FAQ and web fonts paper to address fonts delivered within the
HTML file.
Even the common case of just linking to the file is not much different
from bundling the font in the zip container of ODT or DOCX.
I think it is. In a zip the fonts travel with the doc and they cannot be
used by other docs unless you extract them.
V

[Vernon Adams]

Are we saying that embedding a font that a user can extract, is a perfectly acceptable (i.e. FLOSS-like) way of distributing a libre font?
I like the idea of that, but i'm trying to think of what weaknesses in that method, and what could be ways to enable embedding as a means of distribution whilst also protecting the freedom of the font?

-vern

Post by Dave Crossland
Extracting the fonts is just as easy

Post by Khaled Hosny
You can embed a webfont as base64 encoded string inside the HTML file.

- The font is delivered as part of the HTML file, not a separate resource
- The font is provided by the same server as the rest of the doc
- The font is used for only one document
- The font is always present, even if the doc is viewed offline
I'm not sure whether an embedded web font would be any more difficult to extract than normal web fonts. Anyone have thoughts on this?
These differences are significant. Nicolas has been out of the office for a couple of weeks. When he gets back in the office I'll talk with him about adjusting the FAQ and web fonts paper to address fonts delivered within the HTML file.

Post by Khaled Hosny
Even the common case of just linking to the file is not much different
from bundling the font in the zip container of ODT or DOCX.

I think it is. In a zip the fonts travel with the doc and they cannot be used by other docs unless you extract them.
V

[Dave Crossland]

Embedding fonts you can't extract easily is ok too. The point here is that
Web fonts are never embedding, they are always separate resources that are
linked to documents.

Post by Vernon Adams
Are we saying that embedding a font that a user can extract, is a
perfectly acceptable (i.e. FLOSS-like) way of distributing a libre font?
I like the idea of that, but i'm trying to think of what weaknesses in
that method, and what could be ways to enable embedding as a means of
distribution whilst also protecting the freedom of the font?
-vern

Post by Dave Crossland
Extracting the fonts is just as easy

Post by Khaled Hosny
You can embed a webfont as base64 encoded string inside the HTML file.

Good point, Khaled. That does sound like traditional embedding. The key
- The font is delivered as part of the HTML file, not a separate resource
- The font is provided by the same server as the rest of the doc
- The font is used for only one document
- The font is always present, even if the doc is viewed offline
I'm not sure whether an embedded web font would be any more difficult to

extract than normal web fonts. Anyone have thoughts on this?

Post by Dave Crossland
These differences are significant. Nicolas has been out of the office

for a couple of weeks. When he gets back in the office I'll talk with him
about adjusting the FAQ and web fonts paper to address fonts delivered
within the HTML file.

Post by Dave Crossland

Post by Khaled Hosny
Even the common case of just linking to the file is not much different
from bundling the font in the zip container of ODT or DOCX.

I think it is. In a zip the fonts travel with the doc and they cannot be

used by other docs unless you extract them.

Post by Dave Crossland
V

[Vernon Adams]

Sorry. I need to clarify where i was going with this :)
My point is not really to do with licensing (i know fonts can be embedded under the OFL). But, i'm aware that embedding has not really been seen as a 'best practise' way of distributing libre fonts. When i say distributing, i mean *spreading them around*, not simply *allowing them to be used*.
Now, i know some designers will say that the 'most proper' way to distribute libre fonts is as full-on source package, and then there is the Google webfont approach; binaries up front, git repos of source files at the back. etc etc.
What i'm suggesting, may be seen as "lowering the bar" :) but i'm interested in ideas turn the sort of situation some of us have with Adobe, font squirrel, etc, on it's head; instead of seeing these situations as problems (because these services are not making freely available binary files, or source files), i wonder if it's possible to see advantages instead. One advantage i see is that a font served as a single font object (and not a bundle of license texts, source files etc) is way more mobile, free (as in bird), and able to spread virally. It may be simple a case of adding licensing info with font metadata, and not relying on bundles text files.

ps - someone should build a web service, that pulls the obfuscated OFL's fonts from the Edge / Typekit etc servers, parses them, prepares them, and then builds them back into a OTF, TTF, and a @font-face kit for easy download. Would be cool ;)

-v

Embedding fonts you can't extract easily is ok too. The point here is that Web fonts are never embedding, they are always separate resources that are linked to documents.
Are we saying that embedding a font that a user can extract, is a perfectly acceptable (i.e. FLOSS-like) way of distributing a libre font?
I like the idea of that, but i'm trying to think of what weaknesses in that method, and what could be ways to enable embedding as a means of distribution whilst also protecting the freedom of the font?
-vern

Post by Dave Crossland
Extracting the fonts is just as easy

Post by Khaled Hosny
You can embed a webfont as base64 encoded string inside the HTML file.

- The font is delivered as part of the HTML file, not a separate resource
- The font is provided by the same server as the rest of the doc
- The font is used for only one document
- The font is always present, even if the doc is viewed offline
I'm not sure whether an embedded web font would be any more difficult to extract than normal web fonts. Anyone have thoughts on this?
These differences are significant. Nicolas has been out of the office for a couple of weeks. When he gets back in the office I'll talk with him about adjusting the FAQ and web fonts paper to address fonts delivered within the HTML file.

Post by Khaled Hosny
Even the common case of just linking to the file is not much different
from bundling the font in the zip container of ODT or DOCX.

I think it is. In a zip the fonts travel with the doc and they cannot be used by other docs unless you extract them.
V

[Dave Crossland]

Post by Vernon Adams
My point is not really to do with licensing (i know fonts can be embedded under the OFL). But, i'm aware that embedding has not really been seen as a 'best practise' way of distributing libre fonts. When i say distributing, i mean *spreading them around*, not simply *allowing them to be used*.

By definition embedding is the opposite of spreading them around.

Post by Vernon Adams
Now, i know some designers will say that the 'most proper' way to distribute libre
fonts is as full-on source package, and then there is the Google webfont
approach; binaries up front, git repos of source files at the back. etc etc.

I think source is about access, not mandatory provision - and access
to improvements so they can be integrated upstream.

Post by Vernon Adams
What i'm suggesting, may be seen as "lowering the bar" :) but i'm interested
in ideas turn the sort of situation some of us have with Adobe, font squirrel,
etc, on it's head; instead of seeing these situations as problems (because
these services are not making freely available binary files, or source files),

I see no problem with them - I see a problem with the RFN preventing
the wide use of RFNd fonts.

They are making freely available binary files for all fonts under the
OFL, because the OFL requires that all copies be under the OFL.

They don't provide source files, but their changes don't improve the
font, so its not important.

Post by Vernon Adams
i wonder if it's possible to see advantages instead. One advantage i see is
that a font served as a single font object (and not a bundle of license texts,
source files etc) is way more mobile, free (as in bird), and able to spread
virally. It may be simple a case of adding licensing info with font metadata,
and not relying on bundles text files.

This adds to filesize and so I want to strip it from the web fonts.

Post by Vernon Adams
ps - someone should build a web service, that pulls the obfuscated
OFL's fonts from the Edge / Typekit etc servers, parses them, prepares
kit for easy download. Would be cool ;)

How are they obfuscated?

I see no value in this; the changes Typekit makes that are meaningful
(as we've seen with Rosario) are done in collaboration with the
designers, and the changes FontSquirrel make are available to anyone
in their kit builder.

[Vernon Adams]

Post by Dave Crossland

Post by Vernon Adams
My point is not really to do with licensing (i know fonts can be embedded under the OFL). But, i'm aware that embedding has not really been seen as a 'best practise' way of distributing libre fonts. When i say distributing, i mean *spreading them around*, not simply *allowing them to be used*.

By definition embedding is the opposite of spreading them around.

Yes. So how best could embedding also become a better way of spreading them around?

You are probably mostly right in the replies below. However, the Edge etc services are 'distributing' fonts as (a) webfonts, used by css linkage etc and (b) base64 encoded Woff files placed in the users browser cache.
(a) works well. (b) really sucks. takes extra effort and know-how to pull a full, non-subsetted font, get at that pulled base64'd font, and eventually, be able to use it for e.g. a print project.

So my point is with (b). I would want my fonts to come out the other end of (b) still fully marked it as a Free font, and not as a font that is some sort of orphan. If OFL fonts are going to be increasingly distributed in this way, i think we have to rely more on standalone font files and much less on license text files, font log text files, etc.

-v

Post by Dave Crossland

Post by Vernon Adams
Now, i know some designers will say that the 'most proper' way to distribute libre
fonts is as full-on source package, and then there is the Google webfont
approach; binaries up front, git repos of source files at the back. etc etc.

I think source is about access, not mandatory provision - and access
to improvements so they can be integrated upstream.

Post by Vernon Adams
What i'm suggesting, may be seen as "lowering the bar" :) but i'm interested
in ideas turn the sort of situation some of us have with Adobe, font squirrel,
etc, on it's head; instead of seeing these situations as problems (because
these services are not making freely available binary files, or source files),

I see no problem with them - I see a problem with the RFN preventing
the wide use of RFNd fonts.
They are making freely available binary files for all fonts under the
OFL, because the OFL requires that all copies be under the OFL.
They don't provide source files, but their changes don't improve the
font, so its not important.

Post by Vernon Adams
i wonder if it's possible to see advantages instead. One advantage i see is
that a font served as a single font object (and not a bundle of license texts,
source files etc) is way more mobile, free (as in bird), and able to spread
virally. It may be simple a case of adding licensing info with font metadata,
and not relying on bundles text files.

This adds to filesize and so I want to strip it from the web fonts.

Post by Vernon Adams
ps - someone should build a web service, that pulls the obfuscated
OFL's fonts from the Edge / Typekit etc servers, parses them, prepares
kit for easy download. Would be cool ;)

How are they obfuscated?
I see no value in this; the changes Typekit makes that are meaningful
(as we've seen with Rosario) are done in collaboration with the
designers, and the changes FontSquirrel make are available to anyone
in their kit builder.

[Liam R E Quin]

Post by Vernon Adams
Yes. So how best could embedding also become a better way of spreading them around?

One way would be if Web browser extensions that identified fonts used in
a Web page also included a link, "get this font for myself".

Liam

[Dave Crossland]

Post by Vernon Adams
(a) webfonts, used by css linkage etc and (b) base64 encoded Woff files placed in the users browser cache.
(a) works well. (b) really sucks. takes extra effort and know-how to pull

Err no, not really?

You can find the data by clicking in a WebKit browser: Develop, Show
Web Inspector, Resources, click a font, see the base64 data, copy it,
paste it into http://www.motobit.com/util/base64-decoder-encoder.asp
and the browser downloads a file.

Its also trivial to do it from the command line.
http://askubuntu.com/questions/178521/how-can-i-decode-a-base64-string-from-the-command-line

Post by Vernon Adams
a full, non-subsetted font,

I'm not sure you can, the subsetting is done on the server...

Post by Vernon Adams
get at that pulled base64'd font, and eventually, be able to use it for e.g. a print project.
So my point is with (b). I would want my fonts to come out the other end of (b) still fully marked it as a Free font,

They do

Post by Vernon Adams
and not as a font that is some sort of orphan. If OFL fonts are going to be increasingly
distributed in this way, i think we have to rely more on standalone font files and much
less on license text files, font log text files, etc.

The requirements are the same if the font is distributed as a
standalone file or as a collection of font files and text files.

[Vernon Adams]

Post by Dave Crossland

Post by Vernon Adams
(a) webfonts, used by css linkage etc and (b) base64 encoded Woff files placed in the users browser cache.
(a) works well. (b) really sucks. takes extra effort and know-how to pull

Err no, not really?
You can find the data by clicking in a WebKit browser: Develop, Show
Web Inspector, Resources, click a font, see the base64 data, copy it,
paste it into http://www.motobit.com/util/base64-decoder-encoder.asp
and the browser downloads a file.
Its also trivial to do it from the command line.
http://askubuntu.com/questions/178521/how-can-i-decode-a-base64-string-from-the-command-line

Post by Vernon Adams
a full, non-subsetted font,

I'm not sure you can, the subsetting is done on the server…

erm.. so… i was right then :) it sucks as a way of enabling fonts as "free and easy to obtain and use" ;p

But anyway, the important thing is that this IS how libre fonts are being distributed more and more.

Post by Dave Crossland

Post by Vernon Adams
get at that pulled base64'd font, and eventually, be able to use it for e.g. a print project.
So my point is with (b). I would want my fonts to come out the other end of (b) still fully marked it as a Free font,

They do

Post by Vernon Adams
and not as a font that is some sort of orphan. If OFL fonts are going to be increasingly
distributed in this way, i think we have to rely more on standalone font files and much
less on license text files, font log text files, etc.

The requirements are the same if the font is distributed as a
standalone file or as a collection of font files and text files.

I think i'm being understood a little :) My point is only this;
if we are moving more into libre fonts being distributed via web browser caches and / or embedding (either real or 'faux'), then i think it's worth looking at how to make the standalone font binary object do all the carrying of licensing info & permissions that is needed. And, what could that look like? Obviously we don't want long texts added to metadata, so what would be some 'good ideas'?

-v

[Dave Crossland]

Post by Vernon Adams

Post by Dave Crossland
I'm not sure you can, the subsetting is done on the server…

erm.. so… i was right then :) it sucks as a way of enabling fonts as "free and easy to obtain and use" ;p

Because it isn't the primary distribution point. The files are subsets
of the fonts from the primary distribution point, and have no
improvements. I don't see a problem here.

Post by Vernon Adams
But anyway, the important thing is that this IS how libre fonts are being distributed more and more.

I don't see this as important.

Post by Vernon Adams
if we are moving more into libre fonts being distributed via web
browser caches and / or embedding (either real or 'faux'), then
i think it's worth looking at how to make the standalone font binary
object do all the carrying of licensing info & permissions that is
needed.

Web distribution means its trivial to meet the requirements through
aggregate distribution rather than single file distribution, and
single file distribution is bad on the web as it hurts users by
increasing latency.

Post by Vernon Adams
And, what could that look like? Obviously we don't
want long texts added to metadata, so what would be
some 'good ideas'?

I think what GF does today could be improved by including FONTLOG.txt
files in the ZIP bundles. That's it.

[Vernon Adams]

Post by Dave Crossland

Post by Vernon Adams

Post by Dave Crossland
I'm not sure you can, the subsetting is done on the server…

erm.. so… i was right then :) it sucks as a way of enabling fonts as "free and easy to obtain and use" ;p

Because it isn't the primary distribution point. The files are subsets
of the fonts from the primary distribution point, and have no
improvements. I don't see a problem here.

I don't see a problem either. I see an opportunity to create more distribution points, and have as many distributions as possible acting as primary distribution points :)

Relying on some central, canonical, distro point to be the gatekeeper of licensing info strikes me as a weakness. Far better imo that as many of the distribution points as possible are a primary source of the licensing info.

Post by Dave Crossland

Post by Vernon Adams
But anyway, the important thing is that this IS how libre fonts are being distributed more and more.

I don't see this as important.

The OFL-connected issues we have been discussing, are a result of a gap between technology (how fonts are being used) and the licensing model (how fonts are protected). That gap will get bigger; i suspect we will see fonts needing to become even more mobile and 'free-er' and that will stretch the limits of the current libre licensing model even more. IMO making the licensing more integral to the font object, and more simple, and more permissive, is the way forward. A font object that has a trail of docs left 'back at base', a trademark filed here, with the whiff of a law suit in the wings, and limits on 'embedding types a, b , x and z' is not going to be particularly 'free'.


ps; i'm thinking, not arguing :)


-vern

[Dave Crossland]

Post by Vernon Adams
I see an opportunity to create more distribution points, and have as many
distributions as possible acting as primary distribution points :)

I do not.

Post by Vernon Adams
Relying on some central, canonical, distro point to be the gatekeeper of
licensing info strikes me as a weakness. Far better imo that as
many of the distribution points as possible are a primary source of the licensing info.

The OFL requires licensing information to be available in all distribution.

Post by Vernon Adams

Post by Dave Crossland

Post by Vernon Adams
But anyway, the important thing is that this IS how libre fonts are being distributed more and more.

I don't see this as important.

The OFL-connected issues we have been discussing, are a result of a gap
between technology (how fonts are being used) and the licensing model
(how fonts are protected). That gap will get bigger; i suspect we will see
fonts needing to become even more mobile and 'free-er'

This is incredibly vague. What specifically do you mean by 'more mobile'?

Post by Vernon Adams
and that will
stretch the limits of the current libre licensing model even more. IMO
making the licensing more integral to the font object, and more simple,
and more permissive, is the way forward. A font object that has a trail
of docs left 'back at base', a trademark filed here, with the whiff of a law
suit in the wings, and limits on 'embedding types a, b , x and z' is not
going to be particularly 'free'.
ps; i'm thinking, not arguing :)

I'd like concrete suggestions about what to do :)

[vernon adams]

Post by Dave Crossland

Post by Vernon Adams
I see an opportunity to create more distribution points, and have as many
distributions as possible acting as primary distribution points :)

I do not.

You do. You just don't realise it yet ;)

Post by Dave Crossland
This is incredibly vague. What specifically do you mean by 'more mobile'?

By 'more mobile' i mean more able to move around freely, subject to fewer licensing terms than they are now, able to be used freely and easily without breakage (license-wise or type-wise).

-v

[Dave Crossland]

Hi!

Post by vernon adams

Post by Dave Crossland

Post by Vernon Adams
I see an opportunity to create more distribution points, and have as many
distributions as possible acting as primary distribution points :)

I do not.

You do. You just don't realise it yet ;)

There's a reason I let http://code.google.com/p/web-font-downloader/ languish.

Post by vernon adams
By 'more mobile' i mean more able to move around freely, subject
to fewer licensing terms than they are now, able to be used freely
and easily without breakage (license-wise or type-wise).

Do you want to switch from OFL to Apache?

[Khaled Hosny]

Post by Dave Crossland
Embedding fonts you can't extract easily is ok too. The point here is that
Web fonts are never embedding, they are always separate resources that are
linked to documents.

And so are fonts embedded in PDF files; you can embed the whole font
totally unchanged, neither subsetting or any other change is mandatory
and the fonts are separate resources inside the PDF file. There is
technically zero difference between embedding a font in a HTML or PDF
file.

Regards,
Khaled

Post by Dave Crossland

Post by Vernon Adams
Are we saying that embedding a font that a user can extract, is a
perfectly acceptable (i.e. FLOSS-like) way of distributing a libre font?
I like the idea of that, but i'm trying to think of what weaknesses in
that method, and what could be ways to enable embedding as a means of
distribution whilst also protecting the freedom of the font?
-vern

Post by Dave Crossland
Extracting the fonts is just as easy

Post by Khaled Hosny
You can embed a webfont as base64 encoded string inside the HTML file.

Good point, Khaled. That does sound like traditional embedding. The key
- The font is delivered as part of the HTML file, not a separate resource
- The font is provided by the same server as the rest of the doc
- The font is used for only one document
- The font is always present, even if the doc is viewed offline
I'm not sure whether an embedded web font would be any more difficult to

extract than normal web fonts. Anyone have thoughts on this?

Post by Dave Crossland
These differences are significant. Nicolas has been out of the office

for a couple of weeks. When he gets back in the office I'll talk with him
about adjusting the FAQ and web fonts paper to address fonts delivered
within the HTML file.

Post by Dave Crossland

Post by Khaled Hosny
Even the common case of just linking to the file is not much different
from bundling the font in the zip container of ODT or DOCX.

I think it is. In a zip the fonts travel with the doc and they cannot be

used by other docs unless you extract them.

Post by Dave Crossland
V

[Dave Crossland]

Post by Khaled Hosny

Post by Dave Crossland
Web fonts are never embedding, they are always separate resources that are
linked to documents.

And so are fonts embedded in PDF files

Is it changing the data representation from binary to base64 ascii
encoding that makes for you distribution of the font data then
'embedding'?

Or is it the distribution of the font data inline in a single file
that also contains document data what makes it 'embedding'?

Typekit uses base64 encoding of its fonts as part of its normal
distribution mechanism. The data isn't inline in a single file, it is
linked to in a separate style file that is served from a different
server to the document. Do you see Typekit as linking or embedding the
fonts?

[Khaled Hosny]

Post by Dave Crossland

Post by Khaled Hosny

Post by Dave Crossland
Web fonts are never embedding, they are always separate resources that are
linked to documents.

And so are fonts embedded in PDF files

Is it changing the data representation from binary to base64 ascii
encoding that makes for you distribution of the font data then
'embedding'?

What else would qualify as embedding?

Post by Dave Crossland
Or is it the distribution of the font data inline in a single file
that also contains document data what makes it 'embedding'?
Typekit uses base64 encoding of its fonts as part of its normal
distribution mechanism. The data isn't inline in a single file, it is
linked to in a separate style file that is served from a different
server to the document. Do you see Typekit as linking or embedding the
fonts?

I personally see the mere use of @font-face as a form of embedding not
distribution, how the fonts are embedded are mere technicalities, but
base64 encoded strings are a more clear form of embedding than other
(more clear in the sense that it resembles peoples expectation of
embedding from the pre-web eras).

Regards,
Khaled

[Dave Crossland]

Post by Khaled Hosny

Post by Dave Crossland
Is it changing the data representation from binary to base64 ascii
encoding that makes for you distribution of the font data then
'embedding'?

What else would qualify as embedding?

To me, changing the data representation from binary to ascii doesn't
matter at all.

Embedding is when the font is contained within the document, not
linked from the document.

A HTML document with a <style> tag that includes the font inline is
meaningfully different to a HTML document with a <style> tag that
includes the font by linking to it.

[Vernon Adams]

Post by Vernon Adams
distribution

I think it's worth understanding that any use of a Libre font file in the 'public space' is a 'distribution'. That seems to me to be at the heart of the Libre paradigm and the rationale of the OFL.

Using Libre fonts within css @font-face rules is a good example. When a font is used like this, it becomes 'open' to be fairly easily and directly downloaded, and used. This is exactly why the type industry got so alarmed by @font-face 3-4 years ago. Bad for proprietary font distribution. Good for Libre font distribution.
I would say that embedding is also a 'distribution' too, as more and more, embedded objects are becoming routinely more open to extraction.

-v

[Dave Crossland]

Post by Vernon Adams
I would say that embedding is also a 'distribution' too, as more
and more, embedded objects are becoming routinely more open to extraction.

The OFL treats embedding VERY differently to distribution.

[Vernon Adams]

And the OFL definition of 'embedding' is … ?

and does that definition tally with the situation of how fonts are being distributed via 'embedding' in the real world? and will it likely tally with the situation in say 2 years?

-vern

Post by Dave Crossland
The OFL treats embedding VERY differently to distribution.

[Dave Crossland]

Post by Vernon Adams
And the OFL definition of 'embedding' is … ?

Actually the OFL doesn't define embedding. It says:

5) The Font Software, modified or unmodified, in part or in whole,
must be distributed entirely under this license, and must not be
distributed under any other license. The requirement for fonts to
remain under this license does not apply to any document created
using the Font Software.

Post by Vernon Adams
and does that definition tally with the situation of how fonts
are being distributed via 'embedding' in the real world?
and will it likely tally with the situation in say 2 years?

What changes do you see in 2 years? I don't see any.

[Victor Gaultney]

And the OFL definition of 'embedding' is … ?

From the FAQ:

Question: 1.11 What do you mean by 'embedding'? How does that differ from other means of distribution?

Answer: By 'embedding' we mean inclusion of the font in a document or file in a way that makes extraction (and redistribution) difficult or clearly discouraged. In many cases the names of embedded fonts might also not be obvious to those reading the document, the font data format might be altered, and only a subset of the font - only the glyphs required for the text - might be included. Any other means of delivering a font to another person is considered 'distribution', and needs to be accompanied by any copyright notices and licensing information available in OFL.txt.

V

[vernon adams]

Post by Victor Gaultney

Post by Vernon Adams
And the OFL definition of 'embedding' is … ?

Question: 1.11 What do you mean by 'embedding'? How does that differ from other means of distribution?
Answer: By 'embedding' we mean inclusion of the font in a document or file in a way that makes extraction (and redistribution) difficult or clearly discouraged. In many cases the names of embedded fonts might also not be obvious to those reading the document, the font data format might be altered, and only a subset of the font - only the glyphs required for the text - might be included. Any other means of delivering a font to another person is considered 'distribution', and needs to be accompanied by any copyright notices and licensing information available in OFL.txt.

Thank Victor,
Yes, i knew the definition :) and my point is how does that OFL definition of 'embedding' tally with the situation of how fonts are being distributed via 'embedding' in the real world? and will it likely tally with the situation in say 2 years? because;

from the OFL definition, the uses of OFL fonts by Adobe, Monotype, etc IS 'embedding', and therefore (according to the FAQ) not 'distribution'. The fact that the OFL clearly attempts to separate 'distribution' from 'embedding' is a major note imo too. From the OFL FAQ embedding an OFL font from Typekit in a web page is a 'non-distribution'. 3-4 years ago i think we may have all simply shrugged at that. Now though it strikes me as very noteworthy; it means that the huge bulk of OFL fonts in use right now is 'non-distribution' use. So OFL fonts are being used en masse, as highly popular web objects 'embedded' in hundreds of millions of web pages a week, but their licensing 'kind of' considers all that usage as 'non-distribution'.

And then, all those fonts lying in web browser caches? are they distributions? No? Yes? but only when someone takes the font and tweaks it back into a fully functioning .woff file?

As a designer (who wants their fonts to be as free as possible) i see that the present situation needs some positive patching. I ideally want the freedom of my fonts protected under a license, where the license is as clear, simple and effective as possible, whichever way that font has been used. I see the definition of 'embedding' versus 'distribution' as not helpful. To me technology has clearly made embedding a distribution. I would like to think of the best way that my fonts can come out of any embedding process with it's licensing info and permissions clear, simple and intact, with no need to track down text files 'back at base' etc. What might be the best way to do that?

again; i'm thinking, not arguing :)

vernon

[Dave Crossland]

Post by vernon adams
from the OFL definition, the uses of OFL fonts by Adobe, Monotype, etc IS 'embedding',

No its not! :)

Its LINKING not embedding. The obfuscation that the FAQ mentions is a
distraction. Web fonts are LINKED unless they are including inside a
HTML file in a data url.

[Nicolas Mailhot]

Post by Dave Crossland

Post by vernon adams
from the OFL definition, the uses of OFL fonts by Adobe, Monotype, etc IS 'embedding',

No its not! :)
Its LINKING not embedding. The obfuscation that the FAQ mentions is a
distraction. Web fonts are LINKED unless they are including inside a
HTML file in a data url.

The embedding clause applies to the document, not to the embedded font
bits. The OFL clauses do not apply *to the rest of the document*. They
still apply to the embedded font bits.

If the OFL FAQ now hints it is not the case, there is a serious
misunderstanding and lots of organisations are going to re-evaluate their
OFL by-in. Because that makes the free aspects of the license trivially
bypassable.

If you embed a font in a document, the embedded bits must still have all
the properties needed to satisfy the OFL (that means the embedding process
should never strip the legal metadata when embeding the font)

[Victor Gaultney]

Post by Nicolas Mailhot
The embedding clause applies to the document, not to the embedded font
bits. The OFL clauses do not apply *to the rest of the document*. They
still apply to the embedded font bits.
If the OFL FAQ now hints it is not the case, there is a serious
misunderstanding and lots of organisations are going to re-evaluate their
OFL by-in. Because that makes the free aspects of the license trivially
bypassable.

I don't think the FAQ hints at this at all. If that is unclear please suggest how we can make that clear. See sections 1.11 through 1.15. Here is section 1.15. Note particularly the last sentence.

---

Question: 1.15 What about distributing fonts with a document? Within a compressed folder structure? Is it distribution, bundling or embedding?

Answer: Certain document formats may allow the inclusion of an unmodified font within their file structure which consists of a compressed folder containing the various resources forming the document (such as pictures and thumbnails). Including fonts within such a structure is understood as being different from embedding but rather similar to bundling (or mere aggregation) which the license explicitly allows. In this case the font is conveyed unchanged whereas embedding a font usually transforms it from the original format. The OFL does not allow anyone to extract the font from such a structure to then redistribute it under another license. The explicit permission to redistribute and embed does not cancel the requirement for the Font Software to remain under the license chosen by its author(s).

---

According to the OFL-FAQ, the definition of embedding is wrapped up in whether the font is ever intended to be used outside the document. At no point does the OFL apply to the rest of the document, nor does the OFL's control over the embedded font bits ever get nullified. The OFL always applies anytime the font bits are separated out of the document to be used as a standalone font again.

So if the person who is doing the embedding intends for others to be able to trivially separate out the font, or uses an embedding process that makes that simple, then they should be sure that the basic license metadata is also included.

However the system works, if the font is somehow expected to be used outside the document it is originally distributed with, then that is really distribution, not embedding.

An example: Someone includes a reasonably complete font encoded as a base64 resource within a single HTML file. The resource is stored in the web browser cache. The server tracks that, and then does not include that resource in other pages within that session. That may sound like embedding, but since the font is intended to be split out and used by other docs, then that's really distribution.

V

[Nicolas Mailhot]

Post by Victor Gaultney
So if the person who is doing the embedding intends for others to be able to trivially separate out the font, or uses an
embedding process that makes that simple, then they should be sure that the basic license metadata is also included.

There can be no question of intent here.
The embedded bits are covered by the OFL. Therefore, whether the embedder intends for them to be extracted or not, the legal information must be conveyed to the recipients (either as part of the embedded font metadata, or as a separate document).

If you allow intent here, the OFL clauses have no force anymore. At least that's how I understand the legalities.

IMHO the FAQ should make it crystal-clear that all OFL provisions apply to any part of the font even if it's embedded somewhere else. What they don't apply to is the document the font part is embedded in.

--
Nicolas Mailhot

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

[Victor Gaultney]

Post by Nicolas Mailhot
If you allow intent here, the OFL clauses have no force anymore. At least that's how I understand the legalities.

Intent is a factor, but not the only one. If the fonts can reasonably and practically be extracted for use and redistribution outside the document then copyright and license metadata should be included, whatever the intent may have been. OFL-FAQ 1.11 is very clear about that.

If I felt that the OFL-FAQ interpretation of embedding would have the effect of diluting or nullifying the OFL's force, I would have been the first person to scream loudly. Such would have been clearly outside the spirit and purpose of the license itself, and an inappropriate interpretation. However, it seemed clear in 2010 (and still in 2013) that the interpretation did align with the intention and understanding of OFL authors and copyright holders.

Thanks for your concerns about this. I am not arguing against you. We are on the same side, protecting both designer rights and user freedom.

V

[Dave Crossland]

Post by Nicolas Mailhot
the legal information must be conveyed to the recipients (either as part
of the embedded font metadata, or as a separate document).

Do you know if fonts embedded in PDFs do retain the copyright and license
url information?

[Nicolas Mailhot]

Post by Dave Crossland

Post by Nicolas Mailhot
the legal information must be conveyed to the recipients (either as part
of the embedded font metadata, or as a separate document).

Do you know if fonts embedded in PDFs do retain the copyright and license
url information?

I have absolutely no idea about it, and I suspect it depends on the
software used to generate the pdf. I doubt the format prevents keeping
this metadata in the fonts while embedding (and in the pedf case, there
are many ways to embed metadata in a document anyway)

[Victor Gaultney]

from the OFL definition, the uses of OFL fonts by Adobe, Monotype, etc IS 'embedding'...

Uh - not at all. "…we mean inclusion of the font in a document or file…" The web fonts paper, again, talks all about this. :-)

And then, all those fonts lying in web browser caches? are they distributions? No? Yes?…

It is possible to come up with many on-the-edge cases, which seem to strain the OFL and OFL-FAQ. In many cases these are not practically relevant but make for interesting discussions :-) Other times the on-the-edge cases are really important, and deserve lots of thought. Web fonts are one of those, and that's my we created a whole separate doc to document the issues there and express how we thought the OFL fit into that world. Web browser caches as a distribution model seems a bit out there.

As a designer (who wants their fonts to be as free as possible) i see that the present situation needs some positive patching. I ideally want the freedom of my fonts protected under a license, where the license is as clear, simple and effective as possible, whichever way that font has been used.

That's great - however the way you're defining 'as free as possible' makes for a really problematic situation. IOW - you want anyone who has any copy of your font to be able to do anything with your font, including changing every glyph, potentially causing it to be unrecognisable as the original, yet still have the font name?

That's a noble thing, but doesn't help the user community.Users need to know that whatever method they get font 'XXX' - they will get something that reasonably resembles 'XXX'. If a web fonts service offers me Lobster, I don't want to get Crayfish.

BTW - you can already release fonts that provide this freedom - just don't declare RFNs.

As far as I know, the OFL is still the best model for free font licensing, and does not hinder freedom.

I see the definition of 'embedding' versus 'distribution' as not helpful. To me technology has clearly made embedding a distribution. I would like to think of the best way that my fonts can come out of any embedding process with it's licensing info and permissions clear, simple and intact, with no need to track down text files 'back at base' etc. What might be the best way to do that?

Decide that your font will never be used in a PDF file. If you really want to define font distribution as any time font data is sent from point A to point B, and require that full license info be sent with it, then you'll have to talk to Adobe about a new version os PDF. There has to be a line drawn somewhere between distribution and embedding.

I'm not trying to be argumentative. I would *love* to be able to open up a PDF file with any PDF reader and easily be able to click to get the canonical versions of any fonts used, and find out about improved derivatives. But this has little to do with any particular licensing model, and would be possible with the OFL if Adobe and all the PDF creators and readers out there would allow it.

So I feel that creating a better world for designers and users is a matter of including license info, making that info available, and linking to canonical sources. The OFL fully supports this.

V.

[Vernon Adams]

from the OFL definition, the uses of OFL fonts by Adobe, Monotype, etc IS 'embedding'...

Uh - not at all. "…we mean inclusion of the font in a document or file…" The web fonts paper, again, talks all about this. :-)

Yes. I'm not really interested if it is or isn't embedding. Some people claim it is, some point out that it isn't. It clearly isn't in my view. But, I think that's the wrong question anyway :-) I'm just trying to get at the point that (as the FAQ says) - "Any other means of delivering a font to another person is considered 'distribution" Correct?
So... that single file that is pulled into your browser cache from typekit etc is a distribution of an OFL font. It can't be not-embedded and not-a-distribution; under the terms of the OFL it has to be one or the other. So it's a distribution.

My point is that billions of OFL fonts are being distributed like this every week, and i am not sure that they are as well marked as Free fonts as they could be. They often lack clear info of what they are. If i look at the info in the 'font files' that Typekit etc sends to my browser, compared to the info in the files in my master git repo, i feel that the file coming to users from Typekit etc could be a bit more 'informational'. I would prefer a Libre font model where the font itself (in whatever form) integrates just enough info that it can be clearly deemed a "Free Font", not reliant on checking master repos, or bundled text files etc etc.

Does this sound totally crazy? :) It seems very clear to me, but apparently not to anyone else! :)

And then, all those fonts lying in web browser caches? are they distributions? No? Yes?…

Web browser caches as a distribution model seems a bit out there.

Yes in terms of adoption and usage numbers, they are the distribution model way out there, leading the pack :)

thanks for all your time and effort on this too.

-vernon

[Dave Crossland]

Post by Vernon Adams
i feel that the file coming to users from Typekit etc could be a bit more 'informational'.

Can you be more concrete and specific?

[Vernon Adams]

Yep.

I'll use Coda served from Adobe's Edge webfonts service as my example, from
https://edgewebfonts.adobe.com/fonts#/?nameFilter=coda&collection=coda

So from e.g. that page, i can obtain the Coda fonts by using the Developer tools of my web broswer. Not sure if this works for all browsers, but i'm using Chrome so it does…

The page's Resources are exposed in the Developer tools and i can see the url of the Coda Regular font, it is;
data:font/opentype;base64,<i've cut the sqillions of lines of base64 encodingt>

That link kicks Chrome into downloading a single file called 'download' to my local machine.
I then add the file extension '.woff' to that file, to create 'download.woff'. It's a base64 encoded woff font file.

I can then use this font file, or… i guess i can use it?… can i share it? What should i call it? can i use it on my own server within a css @font-face rule?
I would like to print with it too… but it's a WOFF file, so more practical if i convert it… can i convert it into an opentype (OTF) file format? and print with it? Can i share that OTF? What can i call it?

I can understand why the situation is like this; Adobe only really want users of their service to use Coda as a 'webfont', they don't want to distribute it as e.g. an OTF font that can be used for printing, or as a TTF that can be used to build a @font-face kit. There is clearly NO WAY they are going to inform users to grab the font in the way i have, because then users will likely grab all the proprietary font in the same way. Remember the Adobe Typekit distribution system is designed to hinder and kerb the free distribution of proprietary font files. Libre fonts have just been slotted into the same system.

So… assuming as a user i have the resources and knowledge … i can use software to look at the metadata of the woff file. I'll use FontForge. Copyright is me :) RFN's are stated etc etc. But no mention of OFL, instead the license string is http://typekit.com/eulas/******** This takes me to the 'EULA' for Coda, and there is the OFL for Coda.

How could this situation be improved? Adobe could also allow the fonts to be downloaded as OTFs or TTFs. I doubt that will happen, and it's not my place to think it should.

As i've said in earlier posts, i think the solution lies more in the hands of font designers, to distribute font files that can carry enough standalone info to make them independent from other sources of usage & licensing info as possible. I should not rely on re-distributors to get all the font info in order, it should be in the font object itself. This would do 2 things; (1) Give enough information to make it clear that it's Free Software, (2) If that info is removed, then the remover has removed the most crucial flag to denoting the Free-ness of the font, which would be clearly naughty.

-vernon

Post by Dave Crossland

Post by Vernon Adams
i feel that the file coming to users from Typekit etc could be a bit more 'informational'.

Can you be more concrete and specific?

[Nathan Willis]

Post by Vernon Adams
Yep.
I'll use Coda served from Adobe's Edge webfonts service as my example, from
https://edgewebfonts.adobe.com/fonts#/?nameFilter=coda&collection=coda
So from e.g. that page, i can obtain the Coda fonts by using the Developer
tools of my web broswer. Not sure if this works for all browsers, but i'm
using Chrome so it does…
The page's Resources are exposed in the Developer tools and i can see the
url of the Coda Regular font, it is;
data:font/opentype;base64,<i've cut the sqillions of lines of base64 encodingt>
That link kicks Chrome into downloading a single file called 'download' to
my local machine.
I then add the file extension '.woff' to that file, to create
'download.woff'. It's a base64 encoded woff font file.
I can then use this font file, or… i guess i can use it?… can i share it?
What should i call it? can i use it on my own server within a css
@font-face rule?
I would like to print with it too… but it's a WOFF file, so more practical
if i convert it… can i convert it into an opentype (OTF) file format? and
print with it? Can i share that OTF? What can i call it?

It sounds like what you're fundamentally interested in here is a browser
feature; akin to the manner in which (most?) browsers offer a "View Image"
/ "Copy Image Location" / "Save Image As" option in the right-click menu.
Obviously they don't *have* to do that; that's their choice. And I can see
how it would be extremely helpful if you visit a page and notice something
interesting about the fonts -- particularly if you like one but think you
might want to modify it. That's a lot more steps than is required to save
and edit an image file, and image files are subject to just as much creator
copyright protection as fonts.

I'm not sure how much could be done in the font *file* itself to simplify
that situation if the browser exposes no convenient options to the user,
though. You can already provide URLs to the user in metadata; it's just
not accessible, right?

So I guess I'm asking whether the answer isn't to open feature requests in
Firefox & Chromium?

Nate

[Vernon Adams]

Well, apart from feeling i might be a bit crazy for seeing this situation in the way i see it :) i do think it's worth thinking about aspects of it that are 'out there' (Victor's words), because chances are they may be the mundane of tomorrow.

IMO at the moment we are still seeing the 'distribution' of Libre fonts in similar modes to modes we are used to seeing proprietary fonts distributed by; canonical, centralised, and ultimately controlled from a 'top down' approach. The 'top' being the designer, or publisher, or foundry. Proprietary fonts have to go these routes for obvious reasons. Libre fonts do not have to at all, their free-ness makes them inherently viral objects, if you want them to be. I suspect that more viral approaches to distribution may emerge, because they are becoming possible and practical. For example, the situation of 'pulling' fonts out of the browser cache; that action is a legacy from the slightly fudgy situation where the type industry wanted the web market, but didn't want to give fonts away. As a designer of free fonts, i'm stuck with that fudge, despite the fact that the technology actually presents a much more direct way to distribute fonts to users. E.g. instead of users having to jump hurdles to get a fairly useless WOFF file of my fonts, i would want that a user could a Free font used on any webpage and be able to 1-click to download that font (intact) and so be able to then use it for web, print, whatever. IMO that's how free fonts could be utilised and distributed. It's pretty much exactly what Nathan describes. Select text, right click… "save font as…" :) Perhaps some browser developers would be interested in this?

The idea that was floated a few years back of a 'permissions table' for (proprietary) webfonts, has allways interested me. It's maybe a shame it was never adopted, as it's a neat idea for how a font can carry all the information it needs to denote it's 'freedom' (or lack of it). Another aspect that may effect webfonts is the 'web DRM' standards that are on the table with the W3C. It would be interesting if font file formats developed to carry 'freedom' information in a DRM protected web.

-vernon

Post by Vernon Adams
Yep.
I'll use Coda served from Adobe's Edge webfonts service as my example, from
https://edgewebfonts.adobe.com/fonts#/?nameFilter=coda&collection=coda
So from e.g. that page, i can obtain the Coda fonts by using the Developer tools of my web broswer. Not sure if this works for all browsers, but i'm using Chrome so it does…
The page's Resources are exposed in the Developer tools and i can see the url of the Coda Regular font, it is;
data:font/opentype;base64,<i've cut the sqillions of lines of base64 encodingt>
That link kicks Chrome into downloading a single file called 'download' to my local machine.
I then add the file extension '.woff' to that file, to create 'download.woff'. It's a base64 encoded woff font file.
I would like to print with it too… but it's a WOFF file, so more practical if i convert it… can i convert it into an opentype (OTF) file format? and print with it? Can i share that OTF? What can i call it?
It sounds like what you're fundamentally interested in here is a browser feature; akin to the manner in which (most?) browsers offer a "View Image" / "Copy Image Location" / "Save Image As" option in the right-click menu. Obviously they don't *have* to do that; that's their choice. And I can see how it would be extremely helpful if you visit a page and notice something interesting about the fonts -- particularly if you like one but think you might want to modify it. That's a lot more steps than is required to save and edit an image file, and image files are subject to just as much creator copyright protection as fonts.
I'm not sure how much could be done in the font *file* itself to simplify that situation if the browser exposes no convenient options to the user, though. You can already provide URLs to the user in metadata; it's just not accessible, right?
So I guess I'm asking whether the answer isn't to open feature requests in Firefox & Chromium?
Nate
--
nathan.p.willis
identi.ca/n8

[Dave Crossland]

Post by Vernon Adams
Perhaps some browser developers would be interested in this?

Make an extension.

[Vernon Adams]

Post by Dave Crossland

Post by Vernon Adams
Perhaps some browser developers would be interested in this?

Make an extension.

= ask others to make an extension

[Dave Crossland]

Post by Vernon Adams

Post by Dave Crossland

Post by Vernon Adams
Perhaps some browser developers would be interested in this?

Make an extension.

= ask others to make an extension

http://code.google.com/p/web-font-downloader/ awaits

[Nathan Willis]

Post by Dave Crossland

Post by Vernon Adams

Post by Dave Crossland

Post by Vernon Adams
Perhaps some browser developers would be interested in this?

Make an extension.

= ask others to make an extension

http://code.google.com/p/web-font-downloader/ awaits

There's also this:
https://addons.mozilla.org/en-us/firefox/addon/context-font/

...apparently. Which I hadn't heard of before JUST NOW. Which is, also,
in the right direction, although it explicitly prevents downloading fonts
through data URLs....

And this: https://addons.mozilla.org/en-us/firefox/addon/fontinfo/

...by Johnathan Kew, which adds a fonts tab to the Page Info box. In the
longer run, I think that's something Firefox ought to do by default. Kind
of wonder why it doesn't....

Nate

[Dave Crossland]

Kind of wonder why it doesn't....

Feature creep is bad, users want less features, options and
preferences by default; that's what extension are for.

[Nathan Willis]

Post by Dave Crossland

Kind of wonder why it doesn't....

Feature creep is bad, users want less features, options and
preferences by default; that's what extension are for.

Sorry I was going to reply earlier but Firefox Sync and WebRTC kept
interrupting me.

In all seriousness, support for webfonts itself is feature-creep; at least
defensibly so. I would put this squarely in the category of building the
right UI for the feature you've already decided to support (@font-face).
It wouldn't hurt things to group webfonts with the image, sound, and video
elements in the "Media" tab either; my real concern is just that they
aren't exposed at all, not that they don't have a tab all of their own.

Nate

[Vernon Adams]

Post by Dave Crossland
http://code.google.com/p/web-font-downloader/ awaits

hurry up then

[Nicolas Mailhot]

Post by Vernon Adams
"Any other means of delivering a
font to another person is considered 'distribution" Correct?
So... that single file that is pulled into your browser cache from typekit
etc is a distribution of an OFL font.

When I pushed for Fedora to officially endorse the OFL, it was very clear
in my mind that embedding was still a distribution of the font bits, and
that the OFL embedding clause merely stated there was a requirement
boundary between the embedded font and the rest of the document.

I'm pretty sure the public debate at that time was crystal-clear on this
point (wish for a lgpl-like barrier between the font and the document
created with the font, for the same reason the FSF had to propose a font
exception to the GPL).

I'm quite saddened the OFL FAQ has been used since to twist the license
meaning, without any public debate and just for convenience.

Regards,

[Victor Gaultney]

Nicolas -

Post by Nicolas Mailhot
When I pushed for Fedora to officially endorse the OFL, it was very clear
in my mind that embedding was still a distribution of the font bits, and
that the OFL embedding clause merely stated there was a requirement
boundary between the embedded font and the rest of the document.

The terms 'embedding' and 'distribution' have very specific meanings in the OFL context, and are mutually exclusive. Here is a slightly expand form of what is said in the FAQ:

Embedding = inclusion of font data solely for purposes of viewing that one enclosing document, and in a way that makes extraction difficult or clearly discouraged.

Distribution= inclusion of font data with the intention of allowing it to be used for other docs, or in a way that makes extraction and redistribution easy.

Embedding allows for greater freedom to modify a font (subsetting in particular, but also format changes, such as TT data to PS data) without triggering things like RFN-related name changes. It is most appropriate in situations where extraction of the font is impossible, or difficult, or clearly obstructed. A good example of this a font that is subset to include only the glyphs needed for that document, so reconstructing the original font is not possible.

Distribution makes a clear distinction between the document and the font, and so must follow the same rules as any other way of distributing the font.

Years ago, because of technical constraints, almost every example of inclusion qualified as 'embedding'. Now, because of technological changes, more and more instances of inclusion resemble traditional distribution. If you include a font in a doc in a way such that the font can be trivially extracted, whole and complete, then it is your responsibility to be sure that license data remains intact.

Post by Nicolas Mailhot
I'm quite saddened the OFL FAQ has been used since to twist the license
meaning, without any public debate and just for convenience.

I'm sorry that you feel the FAQ has been used to twist the meaning of the license. The sections in the FAQ regarding embedding have been there since 2010, were discussed at the time, and have not changed in their interpretation since then. The widespread adoption of the OFL by both designers and users has mostly happened since then, so the very broad community has accepted the licence with full knowledge of this interpretation.

Thanks,

Victor

[Vernon Adams]

Post by Victor Gaultney
Embedding = inclusion of font data solely for purposes of viewing that one enclosing document, and in a way that makes extraction difficult or clearly discouraged.
Distribution= inclusion of font data with the intention of allowing it to be used for other docs, or in a way that makes extraction and redistribution easy.

This i what i pointed at earlier. The OFL defines a font's usage as either 'embedding' or 'distribution'. According to the OFL, a font can't be treated as both. But i think the biggest usage of OFL'd fonts today (base 64 encoded woff files served from a central server to users browsers) seems to fall into both :) This is what is causing any problems or confusion.
These webfonts fit the 'embedding' definition because it can be argued that they are included for sole purpose of typesetting the web page they are sent to the browser with. Also their 'extraction' could be seen as 'difficult' (compared to 'click here to download your free-to-use OTF / TTF"), and as i have pointed out their distribution system has been designed to make extraction (of proprietary fonts) 'not easy'.
But… it can also be argued that the fonts are 'distributions', because actual font files can be practically pulled from the browser cache, and used as is, or converted to another format for printing with etc etc.

-vern

[Dave Crossland]

Post by Vernon Adams
i think the biggest usage of OFL'd fonts today (base 64 encoded
woff files served from a central server to users browsers) seems
to fall into both :) This is what is causing any problems or confusion.

It might _appear_ to be embedding at first glance, but if you look at
the situation carefully, you will see that it is in fact distribution.

[Vernon Adams]

Yes. To me it is clearly distribution, because, as Victor pointed out, with the OFL 'embedding' and 'distribution' are mutually exclusive. So, any form of distribution (however 'on the edge' of embedding it may be) makes it wholly 'distribution'.
In the case of Adobe (i've not checked other services) the only thing they are distributing is WOFF files. Now, in the example of my fonts, i have never published any woff versions of my fonts, so to convert from my sources to a woff, is a clear 'modification', i would say. The main reason i would say it is a major modification, is because my OFL fonts have been designed and published to be used for web, print, whatever. A woff is a totally useless format for quite a few end user situations. Hence why i would like to see a web tool that easilly identifies a woff font in a web page, extracts the font from the browser cache, converts it to OTF or TTF and downloads it for any other use.

-vern

Post by Dave Crossland
It might _appear_ to be embedding at first glance, but if you look at
the situation carefully, you will see that it is in fact distribution.

[Dave Crossland]

Post by Vernon Adams
to convert from my sources to a woff, is a clear 'modification', i would say.

The OFL FAQ and I both disagree with this; WOFF is simply compression,
not modification, and it guarantees 100% that the data you put into
the compression process will be the data you get out. EOT and WOFF2
can rearrange the data so it won't checksum the same, but it will be
the same for all practical purposes. The tools used to make
WOFF/EOT/WOFF2 may however make it very convenient to modify the fonts
(subsetting, etc) before compression is applied.

Post by Vernon Adams
The main reason i would say it is a major modification, is because my OFL fonts
have been designed and published to be used for web, print, whatever.

Compressing them won't change that.

Post by Vernon Adams
A woff is a totally useless format for quite a few end user situations.

? :)

Its trivial to decompress WOFF, and there are a handful of independent
implementaitons.

Post by Vernon Adams
Hence why i would like to see a web tool that easilly identifies a
woff font in a web page, extracts the font from the browser cache,
converts it to OTF or TTF and downloads it for any other use.

If you want to fund it, I can find a developer.

[Vernon Adams]

Post by Dave Crossland

Post by Vernon Adams
to convert from my sources to a woff, is a clear 'modification', i would say.

The OFL FAQ and I both disagree with this; WOFF is simply compression,
not modification, and it guarantees 100% that the data you put into
the compression process will be the data you get out. EOT and WOFF2
can rearrange the data so it won't checksum the same, but it will be
the same for all practical purposes. The tools used to make
WOFF/EOT/WOFF2 may however make it very convenient to modify the fonts
(subsetting, etc) before compression is applied.

Post by Vernon Adams
The main reason i would say it is a major modification, is because my OFL fonts
have been designed and published to be used for web, print, whatever.

Compressing them won't change that.

Post by Vernon Adams
A woff is a totally useless format for quite a few end user situations.

? :)

So you're saying i should see the woff conversion as similar to distributing a font as a gzip or tar? and a user wouldnt expect to be able to use a gzipped font for all occasions (but they could for some), but it can be easilly enough decompressed for other uses?

I guess i could buy that rationale :)

Post by Dave Crossland
Its trivial to decompress WOFF, and there are a handful of independent
implementaitons.

Yes i will look for a good libre tool for that.

Post by Dave Crossland

Post by Vernon Adams
Hence why i would like to see a web tool that easilly identifies a
woff font in a web page, extracts the font from the browser cache,
converts it to OTF or TTF and downloads it for any other use.

If you want to fund it, I can find a developer.

Yes maybe, and i have asked around a little already. It seems more than worthwhile.

-v

[Vernon Adams]

This firefox add-on
https://addons.mozilla.org/en-us/firefox/files/browse/87807/file/chrome/content/fontface.js#top
pretty much does the job, except it does not support downloading fonts from data urls, because "Font providers like Typekit use data urls to obfuscate copyrighted fonts. "
It would seem to be a fairly mundane matter to add that feature to this add-on. The original author no longer maintains the add-on but the code is free under the firefox license thingy.

The result would be that a Firefox user can select text on any web page, right click to download the font used to set that text, as a woff file.

This would allow webfont service providers a much more streamlined and efficient way to distribute their free fonts as downloadable font files, for users to use in print works too. No need for 'download' links, etc etc, to be built & maintained on the server side :) Yay!! win-win :)

-vernon

Post by Vernon Adams

Post by Dave Crossland

Post by Vernon Adams
Hence why i would like to see a web tool that easilly identifies a
woff font in a web page, extracts the font from the browser cache,
converts it to OTF or TTF and downloads it for any other use.

If you want to fund it, I can find a developer.

Yes maybe, and i have asked around a little already. It seems more than worthwhile.

[Nicolas Mailhot]

Post by Vernon Adams
This i what i pointed at earlier. The OFL defines a font's usage as either
'embedding' or 'distribution'.

This is irrelevant. As noted during the GPLv3 review process, both
'derivative' and 'distribution' are specific legal terms a license can not
redefine. A license writer that does not like the boundaries of those
terms must either use different terms (like the GPL v3 did for conveyance)
or explicitely state that a use, even though it is a distribution (or
derivation) in legal terms is exempt from the conditions the licence
imposes to derivatives or distribution as a whole.

I don't see anywhere in the OFL text where embedding is exempt from
distribution clauses. And you can't argue it is not distribution because
legaly – it is.

[Nicolas Mailhot]

Post by Nicolas Mailhot

Post by Vernon Adams
This i what i pointed at earlier. The OFL defines a font's usage as either
'embedding' or 'distribution'.

This is irrelevant. As noted during the GPLv3 review process, both
'derivative' and 'distribution' are specific legal terms a license can not
redefine. A license writer that does not like the boundaries of those
terms must either use different terms (like the GPL v3 did for conveyance)
or explicitely state that a use, even though it is a distribution (or
derivation) in legal terms is exempt from the conditions the licence
imposes to derivatives or distribution as a whole.
I don't see anywhere in the OFL text where embedding is exempt from
distribution clauses. And you can't argue it is not distribution because
legaly – it is.

(or to be exact: in most countries, it will be. The GPL writers didn't
like the fact IP law was not uniform and that they were not allowed to
posit in the license that 'distribution means what it means in US law'. So
they used conveyance instead and defined it pretty much the same way as
distribution in the US context)

[Nicolas Mailhot]

Post by Victor Gaultney
Nicolas -

Post by Nicolas Mailhot
When I pushed for Fedora to officially endorse the OFL, it was very clear
in my mind that embedding was still a distribution of the font bits, and
that the OFL embedding clause merely stated there was a requirement
boundary between the embedded font and the rest of the document.

The terms 'embedding' and 'distribution' have very specific meanings in
the OFL context, and are mutually exclusive. Here is a slightly expand

Once again, this is a distinction which has been introduced in the FAQ,
and does not exist in the license itself. While the FAQ is an important
document, it is not the license itself and I feel it overstepped (and not
in a little way) when it started making this distinction.

Post by Victor Gaultney
The
fonts, including any derivative works, can be bundled, embedded,
redistributed and/or sold with any software provided that any reserved
names are not used by derivative works. The fonts and derivatives,
however, cannot be released under any other type of license. The
requirement for fonts to remain under this license does not apply
to any document created using the fonts or their derivatives.

A distinction exists between a font and "any document created using the
fonts or their derivatives". The license does not state the same
restriction between a font and an embedded font part. It explicitely lists
embedded fonts as a form of "fonts, including any derivative works".

Post by Victor Gaultney
2) Original or Modified Versions of the Font Software may be bundled,
redistributed and/or sold with any software, provided that each copy
contains the above copyright notice and this license.

The OFL explicitely states that, when bundled with a software (which in
practical terms means the font will be embedded in the software
installer), OFL provisions still apply to the fonts (including keeping
legal notices)

Somehow I missed when this entry has been added to the FAQ, but while most
other entries are merely explanations of OFL parts, this one introduces a
legal element which is not present in the license itself (and should have
raised alarms)

/note to self: find some quality time to read all the FAQ entries again

There is *no* ambiguity in the OFL that embedding is a form of copy
subject to the OFL. We should not even have this debate here. That,
through the FAQ, this requirement has been put in doubt, is quite
frightening.

Post by Victor Gaultney
The widespread adoption of the OFL by both
designers and users has mostly happened since then, so the very broad
community has accepted the licence with full knowledge of this
interpretation.

I strongly disagree with this part. SIL had no mandate to change the
meaning of the license through the FAQ and OFL adoption started before
this entry was written (at minimum, it should have been a new OFL version
with a specific embedding paragrah). FAQ changes have not been given he
same legal scrutinity than OFL text changes.

[Nicolas Mailhot]

Post by Nicolas Mailhot
The OFL explicitely states that, when bundled with a software (which in
practical terms means the font will be embedded in the software
installer), OFL provisions still apply to the fonts (including keeping
legal notices)

And now that Mozilla and others are declaring future mobile applications
will just be webapps, trying to separate embedding in a document,
referencing in a web page, and bundled with software in different cases,
is totally hopeless. Not that the OFL itself tried to. That the FAQ tried
to is unfortunate. The only sane separation is font bits (embedded,
modified, converted, bundled, rot13ed, or not) and the rest. Font is
whatever derivative part of the original work can be used to render a
single glyph, regardless of intent.

The only case where font use is not some form of redistribution is when
the font itself is already present on the target system and you are using
this system copy.

[Victor Gaultney]

Post by Nicolas Mailhot
The only sane separation is font bits (embedded,
modified, converted, bundled, rot13ed, or not) and the rest. Font is
whatever derivative part of the original work can be used to render a
single glyph, regardless of intent.

So it sounds like what you're implying is that if a designer - Frank - creates a new doc in illustrator, chooses the font 'Lobster', types an 'O', converts to outlines, then then adds points, moves others, etc. in order to turn it into a square, then adds 40 more hours of work to fill the pages with other wonderful marvelous intricate artwork, and adjusts the square even more alongside other elements, then delivers that as a PDF, then the PDF must contain the full copyright and license information?

According to your definition, this would be a font distribution. The font data remains there, although it has been embedded, modified, converted, etc. Glyph reshaping is fully allowed by the OFL of course. In your definition, at what point does a derivative part cease to be able to be used to 'render a single glyph'? Where is the line?

( BTW - you are adding here a definition of a 'font' that does not exist in the OFL. The OFL defines 'Font Software' very differently from your definition of 'font'. )

Very few people would agree that Frank's document is a 'font distribution'. There is effectively no way to extract or reconstruct the original font from the contents of the doc. So at some point there has to be some way of determining when the font data shifts from being separate font data into being a fully integrated part of the document (artwork) itself. (There is a huge amount of philosophical thought dedicated to the concepts of original creation versus tools and techniques - where is the border between the artist, the tools and the creation? - but that would not really be helpful to reiterate here.)

Were we to say (as you seem to saying) that any bit (or glyph, or modified glyph no matter how small) from the font data contained in the document requires that the document then contain the license, even if (as in Frank's extreme case) that bit is relatively undistinguishable from the rest of the doc, then that would seem to be at odds with this statement from the OFL itself:

"The requirement for fonts to remain under this license does not apply to any document created using the fonts or their derivatives."

Since that definition/interpretation would clearly go against the OFL text itself, there must be a better way to interpret what designers would want when they choose this license.

---
Some further background and reminders: The OFL-FAQ is not a legally binding document. Only the OFL itself - pure and simple - is legally binding. Neither Nicolas Spalinger or I are lawyers. We are not providing legal judgements nor professional legal advice. It is our opinion. However, it is from the point of view of people who were part of the extensive public and legal review process, regularly discuss the OFL and issues with members of the broad OFL community, who have done considerable research in the topic, and who seek to fairly and openly represent the views of the community. Whenever we can, we have expressed our opinions in a public doc (the OFL-FAQ) and have even subjected that doc to community discussion and review. The main purpose of the OFL-FAQ is to address practical issues in applying the OFL.
---

So… as we faced applying the OFL to situations like Frank's - and ones that were far less clear - we needed to come up with a way to talk about this spectrum from obvious and complete integration into a doc to complete discrete separation from it. So in the FAQ we chose to use 'embedding' to refer to the type of inclusion where a font is integrated into the doc and not easily separated - in other words, when the document is 'created using the fonts' rather than is 'bundling' the fonts for distribution. We did not invent the term but rather used it as it is best understood and has been used by the type industry for decades. Because of this understanding, we see this as a reasonable interpretation of what the OFL is referring to when it says: "...can be bundled, embedded, redistributed and/or sold…"

In other words:

- We affirm that the OFL text is what is legally binding - the rest (including the OFL-FAQ) is opinion, refined and influenced by the community.

- The OFL-FAQ does not in any way change the meaning of the license. It only seeks to help people interpret it in a common, public way.

- The OFL-FAQ does not introduce any distinction between 'embedding' and 'distribution' that is incompatible with the OFL itself. That there is a distinction between documents that are 'created using the fonts' and packages that 'bundle' fonts with a document is in the OFL text.

I know this may not satisfy your concerns. I do wish we could come to some common understanding. However, I remain convinced that both the current (update2) and draft (update3) OFL-FAQ fairly interpret the OFL in practical matters on implementation, and do not seek to add to or change the OFL itself.

Regards,

Victor

[ BTW - I will be away for a few days, so I'll be unable to respond further until mid-next-week. ]

[Khaled Hosny]

Post by Victor Gaultney
then you'll have to talk to Adobe about a new version os PDF.

PDF does, in fact, allow this. You can now even embed full OpenType fonts
since PDF 1.6.

Regards,
Khaled

[Vernon Adams]

I have now contacted font pro.com about this. They promise to remedy the situation.
The download packages, contain no OFL license.

-v

Post by Barry Schwartz
IMO FontPro should be more explicit about licenses, because they offer
downloads. I haven’t downloaded a package to see what comes with it.

[Dave Crossland]

Post by Vernon Adams
I have now contacted font pro.com about this. They promise to remedy the situation.
The download packages, contain no OFL license.

[Victor Gaultney]

Post by Vernon Adams
I have now contacted font pro.com about this. They promise to remedy the situation.

Great. This is exactly how the process should work. The community polices itself. If anyone comes across a service that seems to violate the OFL, those who have a vested interest (mainly the font designers) should contact them and suggest how they could fix the situation. We've done that a few times, since we have fonts out there too.

That's a far more sustainable and healthy model than expecting the license maintainers to become the font police. Of course, we're happy to give advice, answer questions about details and best practices, and document the answers in public docs.

V

[Dave Crossland]

I believe these lawsuits are currently the most profitable business
model for font copyright holders.

[Vernon Adams]

Dave - Haha, but not sure if you are joking or not :)

@Rich - I know what you mean, but i see things more round the another way. I'm more interested in getting more and more freely available fonts into the hands of more users, rather than creating fonts that are more legal object than typographic object. Some large foundries have started distributing Free fonts. It's a good start, but I wish it was being done in a way that made the fonts even more free. I'm more interested in how fonts can be designed that can be as free as possible, even when they are simply embedded or only distributed as chopped up woff files.

-v

Post by Dave Crossland
I believe these lawsuits are currently the most profitable business
model for font copyright holders.

[Vernon Adams]

Lastly - Vernon, I'm on your side, as far as your aims are concerned. Totally. So don't get me wrong. But as somebody else wrote somewhere on this thread or one closely associated with this topic: where in the license does it say you've got to keep a pristine copy of the font up on a server somewhere available for download?

It doesn't. But i think it's should be assumed the following basic of Free Software; if someone modifies Free Software then their modifications also are Free Software. To modify Free Software, but then to close your modifications off (even partly) is usually a breach of the Free Software community 'values', and maybe even sometimes a breach of a license. These redistributions of 'modified' Free web fonts via major foundry's font servers are maybe more 'on the edge' of value breaches, rather than license breaches, the technical details of which have some "if's and but's".
Personally, i want to stay pragmatic about it all. Also i sense that there can be some sort of 'parasite / host' relationship that may be more interesting that anything else. These big web servers are potentially simply big hosts. Ideally i would like these hosts to hold downloadable files, but, in any case the current free serving off WOFFs, that can also be grabbed, is better than nothing. Something to work with, at least. I think the idea of browsers being able to 1-click download WOFFs from web pages, with conversion back to an OTF, post download, would be an awesome thing. I'd love to see such a tool appear in the next months.

One aspect of the Adobe Edge service i still haven't worked out; and that is what files do they use as the 'source' of the OFL's files they are serving? The WOFF files that land in my browser cache, are from postscript outlines i assume. I guess they were not converted from Truetype outlines. I haven't had a good look, though i am curious. Any ideas?

And I'm saying - how many caveats are there going to be? What's the goal here? Seems to me, that after three years or so of this, web fonts are still being strangled by their own "rules". And what's going to happen when the fonts need to install as part of an ebook? It goes from bad to worse.

There are as many caveats as each designer / copyright holder want to create, i guess. I have few caveats. Others have more, and others less.
I'm not sure i agree that webfonts are being strangled at all. Why do you say that? Seems to me they keep spreading and spreading. Seems to be no antidote.

Maybe specifics would help. Would you mind answering this: Do you consider the fonts you create to be your intellectual property? If so, what rights do you want to hand over to users via the license?
And one more question: "enforcement" unfortunately has bad connotations. How would you like to see "compliance" handled?

The question you should ask is "How much do you value your intellectual property?" Depends. Some fonts i value more than others, but ultimately i am not over precious about them. They are designed to be free (as in bird, and freedom), so i guess i most value the freedom aspect of their intellectual property value. I think 'enforcement' and 'compliance' would only become an issue if free fonts software started showing up in proprietary fonts, tbh.

-vern

[Pablo Impallari]

Good News:
Pablo Cosgaya asked Typekit to correct the Rosario page, and they have made
the changes accordingly.
Now Omnibus Type is properly credited: https://typekit.com/fonts/rosario
+1 to Adobe/Typekit for fixing the meta-data.

LOL! I hope Dave is joking, but I worry that even if he is, folks might
take him seriously. It would be a mistake to think that these lawsuits are
a major profit source for font copyright holders, or a major part of Frank
Martinez's business.
I've talked to most of the people Frank has represented in these lawsuits,
about their lawsuits. I have also met with Frank on a fair number of
occasions, including the last time I was in New York.
In recent years he has probably averaged ~ one such lawsuit per year.
Pretty much all have settled out of court for undisclosed terms.
Given the amount of underlicensed and unlicensed font use out there, one
lawsuit a year in the USA is nothing. Clearly, suing is being used as a
last resort, when all else fails, and even then only in a small minority of
cases. It should be self-evident that we would see a lot more of them if
such lawsuits were a fabulous cash cow.
Many, probably most of the font copyright holders—who are generally type
designers themselves—really do not seem to care for the legal action at
all, and would much rather be designing typefaces or otherwise engaging in
what they see as the “real” business of making and selling fonts. Sure,
they don’t like seeing people/organizations with deep pockets “get away”
with using their fonts without compensation, but most of them have long
since learned that the amount of work involved in really chasing them is
disproportionate to both any sense of victory they might get in the end,
and to any financial reward.
That being said, there are limits to what people can stomach. One very
high profile case was reported as if it were a new incident, but the
foundry told me that in fact this was the culmination of ten YEARS of
dealing with the company in question and trying to get them to pay for the
fonts they were using, and generally being ignored and blown off.
Cheers,
T

Post by Dave Crossland
I believe these lawsuits are currently the most profitable business
model for font copyright holders.
--
--
Google Font Directory Discussions
http://groups.google.com/group/googlefontdirectory-discuss
---
You received this message because you are subscribed to the Google Groups
"Google Font Directory Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.

--
“‘Kindness’ covers all of my political beliefs.”
—Roger Ebert
--
--
Google Font Directory Discussions
http://groups.google.com/group/googlefontdirectory-discuss
---
You received this message because you are subscribed to the Google Groups
"Google Font Directory Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.

[Vernon Adams]

I'm sure i saw an in-house blog post about the collaboration work with Omnibus on Rosario too. Worth looking for again.

-v

Pablo Cosgaya asked Typekit to correct the Rosario page, and they have made the changes accordingly.
Now Omnibus Type is properly credited: https://typekit.com/fonts/rosario
+1 to Adobe/Typekit for fixing the meta-data.

[Manuel Schmalstieg]

I also sent them this tweet. Perhaps it helped to pressurize from
several fronts :)
https://twitter.com/greyscalepress/status/340461699654090752

Post by Pablo Impallari
Pablo Cosgaya asked Typekit to correct the Rosario page, and they have made
the changes accordingly.
Now Omnibus Type is properly credited: https://typekit.com/fonts/rosario
+1 to Adobe/Typekit for fixing the meta-data.

[Dave Crossland]

Post by Manuel Schmalstieg
I also sent them this tweet. Perhaps it helped to pressurize from
several fronts :)
https://twitter.com/greyscalepress/status/340461699654090752

They don't need the pressure - as Victor has said, they are keen to do
the right thing, although they may be a little slow sometimes as they
are a bit understaffed (as with GF - there's just me)