Jos Buivenga allows for @font-face embedding with the free weights of his fonts. (And others as listed above by Joe.)

Exljbris Fonts: http://www.josbuivenga.demon.nl/

http://typophile.com/node/56316

What's with Type Together? I don't see support for something like @fontface/sIFR/cufon in their EULA
http://www.type-together.com/resources/eula/TT-EULA.pdf
Only "secure" subset embedding for non-commercial use.

I think the comments on Twitter might have been a misunderstanding. I've asked them to come and comment.

insigne allows web and .pdf embedding.

www.insignedesign.com

Thanks for starting this thread Joe. I only hope that it doesn't turn into a battle of opinions, but rather a genuine resource for a very simple question: Who allows what and where can I buy it?

I think the different web embedding needs to be outlined. There are foundries that allow sIFR with their basic license. There are also foundries that allow sIFR but only with extended licensing. There are very few foundries who allow @font-face and/or the use of Cufón.

I agree with you Zara. I just think when people foundry-x allows for web embedding that is too vague an answer. They need to state in which forms it is allowed.

The future is now!

http://www.fonts.info and http://www.theleagueofmoveabletype.com/ appear to allow @font-face embedding.

http://www.cape-arcona.com appears to allow "secure" web embedding, but likely does not support @font-face.

...

Terminal Design http://www.terminaldesign.com

For my commercial fonts I allow PDF embedding for workflow and internal uses also and secure web embedding, unless it's used for customization tools (online graphics editor for instance), in that case a special license is needed.

My freeware has been updated to allow "editing of the document". I will allow all web embedding for the freeware. Should I go further with "installable mode"? Would that be necessary?

-Jess
bvfonts.com
http://twitter.com/bvfonts

We need to create another chart. Or at least a wiki entry for Cufón, @Font-face and sIFR.

Not sure how helpful this list will be as most foundries allow PDF embedding. Need to be more specific about technologies to make the list more useful.

Yes, Tif - I agree. The specifics should be outlined.

Well, as Tiffany says, if we are looking specifically at foundries that allow web embedding rather than just considering PDF embedding, it should still be useful. Especially at the differentiation between sIFR, Cufón and @font-face given the differentiation in technologies between them. We may also want to add fLIR (or facelift) to the list as well to cover the full range of different embedding methods that exist at the moment.

Looks like we need to update our EULA :)

We have always allowed PDF embedding for workflow and internal uses and do also allow secure web embedding in PDF and flash, which covers sIFR and i think Cufon too.

We do NOT allow font-linking, in sense that the font files reside on a server. If i understand Font-face correctly, then this is not covered.

We're collaborating with a web company on a font-license scheme which will allow fonts to be linked to a website easily and painlessly. It should be launched very soon.

>secure web embedding

sorry but that's an oxymoron :-(

There's a PDF embedding topic I'd like to see addressed, although there aren't a lot of people in my situation. We submit new business proposals to various government agencies in response to RFPs, BAAs, etc., and the agency always wants a PDF in addition to the hard copies and Word files. The PDF isn't public in the sense that it's included in a product we sell to the general public, or posted on a web site, but it's hard to see it as workflow or internal distribution. What kind of a license do I need? Is the regular license OK, or do I have to buy an embedding license?

sIRF is a secure font embedding tool. Technically almost all fonts should be allowed to be used with it (I've personally not come across any EULA's that forbid flash embedding).

Font-face and cufon are not 100% secure. I'm interested in a list that allows for these in their EULA's because cufon is like 100000000000x easier to set up than sIRF.

Cufon is not flash, just to clarify.

Cross-posted:
http://typophile.com/node/57934
http://typophile.com/node/56316

Do these threads intend to produce something different than Ralf's wiki page?
http://www.webfonts.info/wiki/index.php?title=Fonts_available_for_%40fon...

... if not, and for the sake of community participation, perhaps that could be used as a starting point for a Typophile wiki page.

If the only difference between the list we're trying to assemble here and the list Ralf has begun is that we're attempting to cross-index licensing nuances with web technologies like sIFR, Cufón, and FLIR, I don't think it's worth the time. @font-face is ready to go. Focus on that list.

...

… if not, and for the sake of community participation, perhaps that could be used as a starting point for a Typophile wiki page.

I think this is exactly what we would like to see happen, that list is exactly the kind of resource I had in mind.

Ralf: Would you have any objections to using your current list as a starting point for a Typophile Wiki page? If so, it would be ideal if you authored it (not to create more work for you) :)

_ Time to change the licensing model: sell fonts to designers and web hosts and not to every single reader/device owner.

Joe, I couldn't agree more. I think graphic designers and type designers need to become best friends. Together both groups can go much further as allies than as adversaries.

Gus, we also allow for general pdf embedding, even if it's not strictly workflow related. We only ask the client for a special license in case the pdf (or similar) is sold as a commercial product.

James, thanks for saying so. Designers need a licensing model that puts the font control (and the font licensing) in the hands of the brands and the designers/agencies who are creating and managing the brands. I'll say more when I can come up for air... Back to pitch land.

Sii is correct...using the term 'secure' in the EULA is only going to add confusion.

If it's on a web page viewable on my machine then I already have the files on my machine in some digital form already.

As much as I'd like to see a license that merely stated 'you can use this in digital file' or 'you can't use this in digital files', unfortunately, it seems like we need to create a matrix to fully compare all these options:

- PDF
- Cufon
- @font-face
- Flash
- others? (Silverlight? SVG? Etc...)

And then those that refer to 'secure' of any of the above would need a superscripted reference with small print defining what they actually mean by the term.

Another layer of potential complexity for web use: documents or applications? At Ascender Corp. we consider this an important distinction. We have licensed our fonts to a wide variety of websites for use with web-based applications. In these apps the fonts reside on the server but are not downloaded to the client. In the case of @font-face (web fonts), Cufon, Flash, Silverlight, etc. the font files are downloaded to the client as part of the document (albeit temporarily in most cases). So my point here is that web-based applications should also be added to Tiffany's new chart :)

"In these apps the fonts reside on the server but are not downloaded to the client"

So they are images? Just outlines?

"So my point here is that web-based applications should also be added"

True, but that's another vague term like 'secure'. I can make a web application that uses sIFR, for instance.

If we're still having a go at this thread, I'll mention Process Type Foundry. I licensed Bryant from them and asked if I could embed it with sIFR. Their answer:

"If you are to follow the advice that Andy linked to about protecting the files/font, then you should be within the bounds of our EULA and we would have no issue with that usage." Link

The advice they were referring to is this.

Tiffany, we'll discuss this today at the Typophile meeting. It may be possible to write a table into a Wiki page for the community to edit.

Any embedding permissions chart will be pretty massive... a few of the potential options just for PDF...

PDF Embedding
- Basics
-- No PDF embedding allowed
-- Print & preview only
-- Editable okay (forms)
-- Must subset
-- Must encrypt
-- Must password protect
- Distribution of PDF including the fonts
-- Workflow only distribtion (to service providers like printers, proofreaders)
-- Limited organizational distribution (within organizations)
-- Limited geographical distribution (within a specific worksite)
-- Extended distribution (eg. distribution via email)
-- Unlimited distribution (ie posted to Web)
-- Commercial distribution (ebooks)

For each of these the answer for any given vendor will be yes/no/requires extended license

As far as I understand, this is the base differences between the different methods of using fonts on the web (besides PDF)

Providing some protection against download is the big advantage of flash (and probably silverlight) implementations of fonts for web usage. Cufon re-encodes the file and *can* secure it to a domain, but enterprising folk could reverse engineer it to get the font back much easier than they could with flash. fLIR or facelift, uses PHP to create an image with the font in it, but that font has to exist somewhere on the server and could also be reverse-engineered. @font-face, in its current form, provides little to no protection.

Another layer of potential complexity for web use: documents or applications? At Ascender Corp. we consider this an important distinction. We have licensed our fonts to a wide variety of websites for use with web-based applications. In these apps the fonts reside on the server but are not downloaded to the client. In the case of @font-face (web fonts), Cufon, Flash, Silverlight, etc. the font files are downloaded to the client as part of the document (albeit temporarily in most cases). So my point here is that web-based applications should also be added to Tiffany’s new chart :)

@billdavis > I don't really understand what you mean here. When you access anything on the web, it is temporarily downloaded to your computer and the browser renders it (resulting in the happy IE issues). Can you provide an example of where font files are on the server and not downloaded?

>When you access anything on the web, it is temporarily downloaded to your computer and the browser renders it (resulting in the happy IE issues). Can you provide an example of where font files are on the server and not downloaded?

Font foundry "type tester" applications would be one area most of us are familiar with, another might be Google maps - text is rendered on the server and the resulting bitmap is sent to the browser.

Ralf: Would you have any objections to using your current list as a starting point for a Typophile Wiki page? If so, it would be ideal if you authored it (not to create more work for you) :)

It's probably not a good idea to maintain two separate lists, though if you want to use the content of the webfonts.info page, it is all licensed under Creative Commons. So a proper attribution of the source would suffice.

I would be happy to help with that, but as far I understand this thread people here are more asking about an EULA matrix of possible web uses. But as Simon already pointed out with his PDF example, every of those technologies has plenty of options and a simple list or matrix would probably not work.

We’re collaborating with a web company on a font-license scheme which will allow fonts to be linked to a website easily and painlessly.

Veronika, can you talk more about that or is it confidential at the moment? Sounds like the first foundry with a "webfonts hosting service" to me.

> Font foundry “type tester” applications would be one area most of us are familiar with, another might be Google maps - text is rendered on the server and the resulting bitmap is sent to the browser.

Ah, that makes sense. I guess that is similar to how the faceList software works — creating an image based on a font file.

Cindy Li:
I wanted to use the lovely font created by House Industries but I looked into their llicensing and the font I found cost: $140 from House Industries, unfortunately to use it on my site its going to cost me an additional $1500 because their licensing doesn’t allow embeding.

http://cindyli.com/site/comments/font_embedding_and_licensing/

Adobe's license allows Flash/sIFR embedding, as I understand it.

sIRF is a secure font embedding tool.

Assuming you mean sIFR, I would not say it is "secure." It uses Flash, which has a public spec, and the files are accessible, so... the fonts could be pulled out of the SWF files. I would however say that sIFR and Flash are "about as secure as PDF." Which may be good enough for most font vendors.

T

House Industries does allow web embedding, but only with an extended license. The published price is $1500 for one font and $7500 for a collection. However, they stress that you call and let them know what you're doing to get specific pricing.

This could be a trend until foundries are comfortable with a flat fee for all. Most foundries appreciate phone calls and you'd be surprised at the benefits of having a good relationship with any of them.

>Most foundries to appreciate phone calls and you’d be surprised at the benefits of having a good relationship with any of them.

Almost anything short of posting the font to the web in raw form can be negotiated, if the price is right.

If money is no object, or you're willing to take ethically dubious short-cuts, then "custom" will be the alternative if you want to raw link.

Joe: for the lazy people like me coming to this late, can you update your initial post with the list, you know, so there actually is a list in here somewhere? Thx.

I have updated the license for Downturn to allow embedding via dynamic Flash text, sIFR, Cufón, Typeface.js, and direct linking to EOT or OT files. Now I just need to design something someone might actually want to use on the web and release it under the same license…

Can we see the EULA? How do you deal with the issue of the font being linked to, but prohibit other forms of loose redistribution eg dafont etc.,

Si: Almost anything short of posting the font to the web in raw form can be negotiated, if the price is right.

Heck, if the price is right, posting the font to the web in raw form would be fine too. Hence my position on all this: I care less about the format and the security model per se than about the viability of the associated business model. Which is why most discussion on web fonts seems to me to come from the wrong end: it's looking for a magical technical solution that will satisfy current business models, rather than asking what kind of business models will be possible with the technical developments before us.

And 'the ugliness of the Web' is pretty insignificant aspect of what we're looking at, which is font linking and embedding in live electronic documents, online applications, cloud computing, etc. I suspect that foundries, taking an ad hoc approach to online technologies -- PDF? Okay. Flash? Okay. sIFR? Okay. -- are going to find it harder and harder to establish grounds on which to say 'Not okay!' to future developments.

@sii: Here’s a link to the EULA.

I have updated the license for Downturn to allow embedding via dynamic Flash text, sIFR, Cufón, Typeface.js, and direct linking to EOT or OT files.

Nice! But what do you charge for the additional license?

Nice! But what do you charge for the additional license?

The same price as any other license. My plan to offer single-server embedding licenses at a low price ran into a wall: MyFonts system just isn’t designed for those licensing options. I was going to set up my own web store to handle the sales, but than I ran into a wall of incorporation and sales tax laws. I’m not making enough money to justify hiring a lawyer and an accountant and setting up a new online store, so I decided to rewrite the workstation license to allow web embedding.

Might want to define "user" in a way that doesn't count Web site visitors.

Good point.

Randy, to my chagrin, the list is yet to emerge. What has emerged is lots of discussion of why that list is a pain to create. Lots of whine, no cheese.

Stuff like @font-face won't work unless foundries let go of some fears.

Permit me to give you guys a gentle ribbing. Right now font licensing so complex that licensors can't just focus on the right typographic solution, they have to navigate cumbersome EULAs and nuanced embedding permissions. (Foundry A has these flavors, Foundry B has these other flavors.)

Consider how the iTunes music store made it easier to buy license music than to download it illicitly. Seriously. Win, win. Yes, music is still downloaded and shared illicitly, but the default is that it's just easier to buy it. This is an analogy, and not a perfect one, but I think it has merit. Companies that make it easy (and have quality type) will win -- that's why I was motivated to start the list.

The complexity is the foundries' problem to solve, not your customers'.