On Monday, Adobe debuted Adobe AIR® 2.5 at MAX. With this latest version, AIR (Adobe Integrated Runtime) supports web fonts with the CSS @font-face rule. This occasion seems like a good time to talk a bit about Adobe’s current font licensing policies for web fonts. Let me try to address a few of the big licensing issues that affect web fonts, in plain English, and without creating anxiety for our legal department. It’s a fine line to walk.

The End User License Agreement

Any time we start talking about what is and isn’t allowed with fonts, it all depends, for better or worse, on your End User License Agreement (EULA). Not just any EULA, but the EULA that accompanied the font you want to use. Where can you find your EULA? You received (and agreed to) the EULA when you bought or otherwise acquired your Adobe font (or fonts). If you bought the font online at Adobe.com, then your EULA was included with your download. Sometimes, when fonts are bundled with an application or other software, the font EULA is combined with the EULA for that software. Adobe’s current font EULA can be found online here — but again, your own font EULA is what’s relevant, and every font vendor ships their fonts with a EULA of their own.

Embedding versus serving

For many years, Adobe’s font EULA has allowed embedding in electronic documents — the most obvious example of which is PDF. But despite the widespread use of the term “embedding” when talking about web fonts, it’s best to not consider the use of @font-face “embedding.” With something like PDF, font data is actually copied into a document and becomes part of its content — self-contained and portable. Importantly, the font data ceases to be a separate, usable font file, which protects the font from unauthorized use.

With web fonts, the font data is not integrated into a document; if I copy an HTML document, the font is still a separate asset, and is only referenced by the document. (There is actually a way to embed font data in the style sheet of an HTML document with something called a data URI, but this is not the typical web fonts model.)

Regardless of where a web font actually exists and in what form, the general concept of a “web font” is that of a served asset. Just like with anything on the web, the model is one or more files on a server, served to a client for viewing. So when an Adobe font EULA refers to “document embedding,” it’s referring to electronic documents like PDF and SWF (Flash) files — not web font linking.

Questions, frequently asked

We’ve prepared an FAQ to answer frequently asked questions about web font usage. The FAQ explains what our font EULA allows with regard to web fonts. (Like many things on the web, it will continue to be expanded and changed as time goes by, so check back.)

As you might imagine, one of the most frequent questions recently is, “Does Adobe allow its fonts to be used on the web?” The answer is, “Yes, but only via specialized web font services.” More precisely, Adobe’s current EULA does not allow an end user to put Adobe fonts on a web server in any form. We consider this “server usage,” not “document embedding,” and the server usage we do allow is always restricted to private networks, and requires a different license on top of that. However, if you are a Typekit user, then you have access to a selection of Adobe fonts which are covered by Typekit’s Terms of Service, not Adobe’s font EULA, and obviously the Adobe fonts available through Typekit can be used on the web.

Why not just change the EULA? Until recently, web fonts were an obscure technology with scant browser support. There was virtually no customer demand for web font licensing. Although the situation is improving rapidly, today the technology is still evolving. As much as we’d like to offer web font licenses immediately, the options are still somewhat complicated, requiring multiple font formats and unpredictable quality on browsers. We want to get it right the first time. Fortunately, Typekit came along to solve these problems in the meantime, and we are very pleased to have Adobe fonts available there.

“What about WOFF?” you might ask. Adobe supports — and is participating in — the current effort to specify and standardize WOFF (Web Open Font Format), a web-specific format that offers better protection for foundries and some other features to improve users’ web font experience. For now, though, Adobe’s font EULA does not allow the use of fonts on the web in WOFF. (As I mentioned above, Adobe does not allow the use of fonts on the web in any format, WOFF or otherwise.) If you want to use Adobe fonts on the web, you are limited to what is available on Typekit. We are working to bring more of our fonts to Typekit, too, so you can expect more choices in the future.

Web fonts in Adobe AIR

When it comes to web fonts in AIR, we consider the Adobe AIR runtime to be just another web client (like a browser). It interprets markup (HTML and CSS, for example), fetches additional resources from a server as necessary, and renders and presents the result. Given this, the current Adobe font EULA does not allow web font use of Adobe fonts in AIR, just as it does not for browsers and other web clients. For fonts from a foundry other than Adobe, check your EULA or ask the foundry what is permitted.

I’m pleased to say, though, that Typekit does work in AIR. The Adobe AIR team has worked with Typekit to ensure this. For more information on using Typekit in Adobe AIR 2.5, see Using web fonts with Adobe AIR 2.5. Typekit has more about it on their blog.

If you have more questions about web font licensing, have a look at our FAQ first.