Embedding Adobe Fonts into a Kindle title

[Monaghan]

Just so that you do not misunderstand, I posted this thread because I want to be careful about not breaking any licence terms by embedding a font incorrectly. That was the entire point of my post.

Originally Posted by Monaghan

It only appears correctly in Kindle Previewer 3 when font obfuscation is turned off from within Sigil, which would presumably break the licence agreement for the font.

I received the reply:

Originally Posted by Quoth

Font obfuscation doesn't work on some epub ereaders and may not work at all with Amazon. Sub-setting a font is the desired solution.

So this is incorrect? Subsetting, along with Amazon's encryption, is not enough to keep within the licence terms?

[Quoth]

I'm not sure that Amazon encrypts other than the text?

[Monaghan]

The reason I ask is that you seem to be totally correct Quoth.

I came across this, from here.

[...]

We allow usage of Adobe purchased fonts per the following:

1. PDF: Covered as long as you subset the font.
2. ePUB: You may embed fonts in documents delivered in the ePUB format provided you subset and obfuscate the font. The IDPF has a prescribed a methodology for the obfuscation as part of the ePUB 3 specification.
3. KF8: We have determined that the KF8 format provides enough protection to serve as a sufficient obfuscation method. Provided you subset the font, you are covered.

[...]

Caleb Belohlavek

Principal Product Manager, Adobe Type

[Hitch]

Originally Posted by Monaghan

Just so that you do not misunderstand, I posted this thread because I want to be careful about not breaking any licence terms by embedding a font incorrectly. That was the entire point of my post.

I'd have to review their font licensing terms. I suspect that removing the encryption or obfuscation MIGHT, repeat, MIGHT violate their TOU, but again, I haven't looked in dog's years, because my attitude has been, if they wanted us to embed the entire font file in a bloody eBook, they wouldn't be encrypting it in the first place. I could absolutely be wrong about that.

So this is incorrect? Subsetting, along with Amazon's encryption, is not enough to keep within the licence terms?

There's a difference between what's legit, what's legal and what violates TOU. At this precise moment, I have to look for the TOU and see what it actually SAYS.

Please note that that answer you're citing says "Adobe PURCHASED fonts." Not Cloud fonts.

EDITED TO ADD:

(This is the stuff I read, a few years back, when I first dug into this, vis: INDD and packages; I downloaded and reviewed the latest versions and they haven't changed really):

I reviewed the Adobe site, about font licensing for CC, Typekit-included fonts (all cloud fonts rather than licensed/bought fonts), and it says:

"Yes. The fonts are licensed for embedding in any ebook format which protects the font data such as EPUB, iBooks, Kindle (mobi), Adobe’s Digital Publishing Suite (DPS), and PDF."

Which is great. But THEN, it goes on to say:

"Any ebook authoring workflow which requires the user to move the font files themselves is not allowed under the Terms of Use, however."

Now, color me stoopid, but I'm 99% sure that removing the encryption or obfuscation, and then embedding the entire font file, etc. probably violates that provision.

I reviewed their "Adobe Additional Terms" document (incorporated by reference into their TOU; the link for the PDF is: https://www.adobe.com/go/adobe-fonts-terms [downloads automagically, so don't be surprised]). I want to disclaim here: I am NOT AN ATTORNEY and I don't play one on TV. In what I read, you are skating dangerously close, by removing the Adobe-provided Obfuscation or encryption and then subsetting it. (n.b.: yes, yes, I concur that subsetting a font should protect it adequately. I'm talking hair-splitting the way that lawyers hair-split here.)

I mean, forgetting all the tech twisty, there are two provisions that give me the Heebie-Jeebies:

Under section "3.4(E) Prohibited Uses of the Licensed Content" it has various provisions that are not clear. Sections (2), (5), (7), (8), and honestly, maybe (4), too.

I mean, for crying out loud, you're not allowed to package or share the fonts, with service bureau designers or printers. But you can manipulate them to include them in an eBook that's being redistributed around the globe?

My advice is, ask a real lawyer to whom you pay real money, who has a speciality in Internet IP. I ran the Litigation Strategy Division of a large Real Estate Development firm, for a few decades, running the legal teams and reviewing and approving all the documents for both friendly acquisitions and not-so-friendly cases and it's my opinion that removing the obfuscation MIGHT be treading a path that Adobe would not look kindly upon. All the stuff we've seen so far seems to indicate that purchased fonts are viewed by them very, very differently than Cloud fonts.

The reason for that is liability--once you purchase a font, your agreement is effectively with the foundry, and Adobe can wash their hands of it. But, if you use a Cloud font, that Adobe licensed to you, from Foundry X, and then Foundry X learns that it's being used inside an eBook, when the font was licensed for (say) Desktop Publishing alone and not licensed for eBook or redistribution...the foundry would likely sue Adobe, not you. Now, again, I can't say this loudly enough: I am not an attorney and you should not pay attention to me.

That's my $.02 and worth less than that by far.


Hitch

[Monaghan]

Latest TOU here: https://wwwimages2.adobe.com/content...S_20200416.pdf

From the FAQ to this (https://helpx.adobe.com/fonts/using/...censing.html):

Can the fonts be embedded in PDFs and ebooks? Can they be used in printed books?

Yes. The fonts are licensed for embedding in any ebook format which protects the font data such as EPUB, iBooks, Kindle (mobi), Adobe’s Digital Publishing Suite (DPS), and PDF.

Can you think of any way a Kindle (mobi) file (to use their terminology) can protect the font data aside from subsetting?

[Quoth]

Talk to a lawyer (costs money) or use a similar free font. ^^^^ What Hitch says.

Bear in mind that: many apps don't show embedded fonts at all, old Kindles using KF7 don't use embedded fonts, modern Kindles always by default use the system font, the user has to explicitly select Publisher fonts and even epub based ereaders don't always use embedded fonts. Only subsetted rather than obfuscated fonts always work, if a publisher font works at all and is selected.

So:
1) Use a free font (especially for main body text), or a less restrictive one.
2) Always subset.
3) Always test on kF7 mobi and newer kindle (in system selected font) to ensure it's readable and headings etc not crazy.
4) Especially avoid annoying Apple, Amazon, Adobe, Alphabet.

Reliable legal advice from an expert in the field costs money. A random Lawyer that deals with car accidents or wills or house sales is no use.

I just checked three kinds of Amazon Kindle file. They don't open with an Archive manager after renaming to .zip, but there are free tools to unpack them. Removing DRM from the actual HTML is a separate task. Only KFX has more serious DRM, and you never get offered it if you select Download to PC to USB transfer to eink Kindle. A Fire is really an Android tablet with a version of the Kindle App.
Renaming a copied epub to zip simply allows an Archive Manager to unpack all the files. HTML, CSS, images, fonts, and the epub control and index files.

Our County Library app is Belinda Borrowbox, which seems to use epub & Adobe DRM. But the app just uses Times Roman, Arial, Courier and one other. No embedded fonts.

[Hitch]

Originally Posted by Monaghan

Latest TOU here: https://wwwimages2.adobe.com/content...S_20200416.pdf

From the FAQ to this (https://helpx.adobe.com/fonts/using/...censing.html):



Can you think of any way a Kindle (mobi) file (to use their terminology) can protect the font data aside from subsetting?

I realize that you very much want your method to work. I think I outlined, above, why Adobe may not agree that your method meets that less-restrictive fAQ article, rather than their MORE-restrictive, actual, governing, Terms of use document, which I not only read, but quoted from, right?

I even quoted the same part you are referencing and I then said "BUT, it goes on to say..."

And I cited Section 3.(4), in numerous places. I think it's highly questionable whether Adobe would consider removing the obfuscation part of what they'd agreed to, for the Cloud fonts. Regardless of the fact that you subsequently subset them or relied on Amazon's encryption.

Section E(5) includes, as prohibited "...or defeating, bypassing, or otherwise circumventing any software protection mechanisms..." Right there. How do you get around that? Given that that's exactly what you're doing?

But hey, that's just me.

Hitch

[Monaghan]

Originally Posted by Hitch

I realize that you very much want your method to work.

I have zero vested interest in any particular workflow. I'm just trying to get a clearer sense of the options for producing good design. If the best option is to not use fonts from the Adobe Fonts platform, then I won't. The reason I linked the TOU is that you mentioned you hadn't read it in a while, I was not fishing for a particular outcome.

As it seems there is no known answer to this question, I'll leave it there. I appreciate your contributions, everyone.

[Turtle91]

Originally Posted by Hitch

"Any ebook authoring workflow which requires the user to move the font files themselves is not allowed under the Terms of Use, however."

I, also, am not a lawyer...but my job requires the dissection of words/sentences. If there is ambiguity bad things could happen.

When I read that statement above, that Hitch quoted, I can see it meaning something different. Let me re-phrase the quote:
"Any ebook authoring workflow which would require your user to move the font files themselves is not allowed under the Terms of Use, however." ie "The font file must be embedded in the eBook which is produced with your workflow. You can not require the user (reader, customer) to get the font file from a separate location and side-load it, or somesuch."

FWIW

[Quoth]

I think it's the Adobe User, not the ebook user, but I'm not a lawyer either. Because when did you ever open an ebook and have to agree to T&C from Adobe? It's the Adobe customer/user Terms of use. Occam principle.

[Jellby]

It's very easy to turn a workflow that "requires" a user to "move the font files" into a workflow that does not "require" that. Just create a script/shortcut/whatever, so the user can simply "run something" instead of "move the font files". And the user does not even need to use it: as long as it's available, they are not "required" to "move the font files", although they may choose to do so.

[Hitch]

Originally Posted by Jellby

It's very easy to turn a workflow that "requires" a user to "move the font files" into a workflow that does not "require" that. Just create a script/shortcut/whatever, so the user can simply "run something" instead of "move the font files". And the user does not even need to use it: as long as it's available, they are not "required" to "move the font files", although they may choose to do so.

Yabbut, Jellby, my sweet:

You're thinking MR readers. Not people getting the file from Amazon or B&N or Apple or Bob's Big Bookstore, after it's been processed in those places, too.

Isn't that correct, or are you thinking something self-extracting...nah, we'd never get it past KDP. NEVAH.

Turtle, when you said:

When I read that statement above, that Hitch quoted, I can see it meaning something different. Let me re-phrase the quote:
"Any ebook authoring workflow which would require your user to move the font files themselves is not allowed under the Terms of Use, however." ie "The font file must be embedded in the eBook which is produced with your workflow. You can not require the user (reader, customer) to get the font file from a separate location and side-load it, or somesuch."

I am not a lawyer. However, I ran the Litigation Strategy Division of a significant Real Estate Development corporation for decades, creating, reading and annotating, approving, legal documents of all kinds. I even wrote 300-page long CC&Rs and I've been reading this sh*t for a long-ass time. I can absolutely, positively tell you that when they say USER, they mean the licensee of the ACF (Adobe Cloud Fonts), not the end buyer.

I mean, let's take a similar example--you can use ACF for a website that you're making for John Doe, customer, right--except, John has to ALSO license the ACF to use on his site. You can't just make the site, plop the fonts in there and Bob's yer uncle. 3.3: "Publishers on whose behalf you create Websites must subscribe to the Service directly for access to the Licensed Content. You may NOT host the Web Fonts or Web Projects for the Publisher or resell the service to them."

Howzzat so different than an eBook? What's an eBook, other than a standalone website that works when not connected to the web? If anything, the eBook use case is worse, because the fonts have to be packaged with the eBook, not "grabbed" from a server on the fly (like so many web fonts and yup, I'm looking at YOU Google Fonts!).

Hitch

[Turtle91]

I understand the dangers of assuming people have common sense...lol

However, if it specifically allows you to use the font in the creation of an ebook:

"Yes. The fonts are licensed for embedding in any ebook format which protects the font data such as EPUB, iBooks, Kindle (mobi), Adobe’s Digital Publishing Suite (DPS), and PDF."

Then it follows that such embedding, along with obfuscation and/or subsetting, etc., is an acknowledged process which is allowed. An end user would not be required to "move the font files themselves", they would be moving the ebook file and would not have access to the original, unprotected in some way, font file. I'm interpreting the word "themselves" here to mean "the font files", not an individual. When an individual is moving an ebook file it is a package, not an individual font file.

From what I gather - although I didn't see the actual question from the FAQ - someone asked the specific question about using those fonts in an ebook and were answered (I also assume it was from an Adobe employee) specifically that it was OK as long as they were embedded. This is supported by the section:

"Any ebook authoring workflow which requires the user to move the font files themselves is not allowed under the Terms of Use, however."

which would require the ebook creator to actually embed the font into the ebook file as part of their workflow (thus ensuring the protections afforded by the format) - not requiring the user/reader to access the font file separately. (no side loading)

Again, just my .02. I don't have a dog in this fight as I only use free fonts when I do decide to embed them.

[Hitch]

Originally Posted by Turtle91

I understand the dangers of assuming people have common sense...lol

However, if it specifically allows you to use the font in the creation of an ebook:

Then it follows that such embedding, along with obfuscation and/or subsetting, etc., is an acknowledged process which is allowed. An end user would not be required to "move the font files themselves", they would be moving the ebook file and would not have access to the original, unprotected in some way, font file. I'm interpreting the word "themselves" here to mean "the font files", not an individual. When an individual is moving an ebook file it is a package, not an individual font file.

From what I gather - although I didn't see the actual question from the FAQ - someone asked the specific question about using those fonts in an ebook and were answered (I also assume it was from an Adobe employee) specifically that it was OK as long as they were embedded. This is supported by the section:

which would require the ebook creator to actually embed the font into the ebook file as part of their workflow (thus ensuring the protections afforded by the format) - not requiring the user/reader to access the font file separately. (no side loading)

Again, just my .02. I don't have a dog in this fight as I only use free fonts when I do decide to embed them.

Turtle, I admire your attempted dexterity with this, but the bottom line is that User is a defined Term. It's the customer that has the Adobe Subscription, NOT the end user. https://www.adobe.com/legal/terms.html

And use of the word "embedded"--that's too ambiguous by far.

Legal documents don't stand alone, on a single paragraph or sentence. Sure, something can and often does, turn on a word--but each word, sentence and paragraph has to be read in the context of the rest of the document, by itself and with any and all incorporated other documents. An answer on an FAQ, by (presumably) an Employee of Adobe, may mean something--or it may not. The doctrine of Respondent Superior may not apply--or maybe it does. Without diving into it further, I can't say.

For that matter, the Additional Terms also says you can only use the Licensed Fonts as long as you have a subscription. I'd love to see the hair-splitting if Adobe decided that ALSO meant, inside an eBook! As in, you embed font X in February and cancel your subscription in April....after all, they flatly state (and mechanically, it's understandable) that you can't use their fonts on your website, once you cancel your subscription. Obviously, the server can't serve them then. But as I said, what's an eBook if not a portable website meant to continue to be usable without an internet connection?

You're hanging everything on this "move" concept. Because the workflow here is de-encrypt the fonts (I mean, anybody think about THAT one? Removing the encryption that Adobe provided, to prevent exactly this????), in order to then reuse the font, redistribute the font, with the Media, in an embedded way. I mean, where's the common sense thinking around this? If they meant you to embed them and that was the only requirement, why encrypt the goddamn fonts in the first blanking place?

Look folks can do their own research. But User <> end user. It's the person who licensed the font in the first place and Adobe's TOU and T&C make that very clear.

Hitch