Posts tagged "licensing"

Single Issue vs Multi Issue Viewers for Enterprise customers

DPS customers have access to tools for creating and managing custom versions of the Adobe Content Viewer that can be distributed through iTunes (like the Wired or National Geographic apps). Additionally, Enterprise DPS customers can build apps for private distribution using an MDM service like MobileIron or Air-Watch. Only Enterprise DPS customers can build apps for Enterprise distribution models, and I have provided an earlier post about that process.

One of the options for the custom viewer is a Single Issue Viewer, in which one folio is embedded directly into the viewer. Single Issue Viewers have no library mode, so they are used by many of our customers who want to use MDM solutions to manage the distribution of specific folios to specific people. However, we have other customers who use MDM to distribute Multi-Issue Viewers to their managed devices, and then use our Restricted Distribution infrastructure to leverage LDAP or other authentication to control access to specific folios in that one viewer app. There are IT advantages to either approach, and I’d like to explore the differences.

In order to use an MDM system to manage apps on an iOS device, each app needs to be created using a specific unique identifier known as a mobileprovision file. Customers make these in the iOS Provisioning Portal, which is part of Apple’s iOS Developer Portal. In the Single Issue approach, each Single Issue Viewer needs a new, unique mobileprovision file from the iOS Provisioning portal. MDM solutions leverage a property of iOS whereby each app must have its corresponding mobileprovision file on the device in order for the app to run. MDM solutions can remove a mobileprovision file on a managed device, rendering the app unusable. When a customer makes a new Single Issue viewer, it must repackage this app to include the new, unique mobileprovision file in a process called resigning. There are several ways to do this, but a popular method is to use iresign from Google. This workflow is very effective because it gives IT fingertip control over each and every app on a managed device, and it allows IT to move DPS Folios in and out of circulation by wrapping them in Single Issue Viewers.

Let’s face it, though. Managing all those apps and mobileprovision files is annoying IT overhead. In the Multi-Issue approach, there is only one mobileprovision file because there is only one Viewer. Content delivery to the Viewer’s Library is based on credentials and is managed by a business user, not IT. The business user can associate content to users or groups in a portal without having to call IT to issue a new mobileprovision file. This portal can be built and managed by corporate IT using sample code from our Developer Center. Derek Lu, for instance, provides detailed instructions and sample code for integrating LDAP with Restricted Distribution. There are also commercially available servers such as Portico from MEI to enable Restricted Distribution workflows in an Enterprise without IT having to develop a backend solution from scratch.

Which method is right for your company? That depends on how you want to manage content. If you want IT to manage everything, then the Single Issue approach might be just what you need for DPS. If you want to reduce the burden on IT and shift content management over to the business users who file the IT tickets in the first place, then Multi-Issue with Restricted Distribution fills the bill. DPS is flexible: your designers create their engaging tablet content in InDesign, IT puts the apps on the devices, and either IT or business users manage the flow of those folios to users. Either way, you can use your MDM system to manage DPS viewers on your company’s tablets.

Share on Facebook

Fonts and Where Can I Use Them?

I came across a question recently in a developer forum, and I felt it warranted broader exposure.

“What is the legality of embedding fonts in an app for distribution?”

This is a thorny issue. Not all fonts are licensed for use in all places. Arial specifically has a checkered past, as outlined in its Wikipedia page. Nevertheless, it is instructive to look at paragraph 12 of Monotype’s current End User License Agreement (EULA):

12.  You may electronically distribute Font Software embedded in a “Personal or Internal Business Use” document (that is, a document other than a “Commercial Product” as defined herein) only when the Font Software embedded in such document (i) is in a static graphic image (for example, a “gif”) or an embedded electronic document, and (ii) is distributed in a secure format that permits only the viewing and printing (and not the editing, altering, enhancing, or modifying) of such static graphic image or embedded document. You may not embed Font Software in a Commercial Product without a separate written license from MI, and you may not embed Font Software in an electronic document or data file for any reason other than your own Personal or Internal Business Use.

The emphasis in the above paragraph is mine. With that kind of license, how should a developer proceed?

It turns out that Adobe sells a package called the Font Folio, which includes fonts both wholly owned by Adobe and also licensed from other foundries, including Monotype, who owns Arial. The licensing for those non-Adobe fonts in the Font Folio varies from typeface to typeface, and often includes different terms for print vs web vs video vs app inclusion. Those terms may also forbid alteration of the font in any way. These EULAs are written by the foundry and not by Adobe, and Adobe has no control over what the terms of a specific EULA will be for a licensed font. Arial has one of those licenses, by the way. You can read Adobe’s font EULAs here.

Adobe has a subset of the Font Folio called the Font Folio Select (FFS). It consists of the fonts that are wholly owned by Adobe and have the broadest license terms of any fonts in terms of how they can be used. Any font in the FFS can be used in print, in an app, in a SWF online, in video and more. They can also be modified, but there are some specific licensing considerations around modifications that you’ll want to investigate. The short of it is that if you modify a glyph in a font and then deploy that modified font in your company, you are no longer permitted to use the ORIGINAL font. If you want the original version AND the modified version at the same time, then you need to purchase another license for the original.

FFS is available to customers who purchase through licensing programs. It is not available as a boxed product through traditional retail outlets. Customers should contact their preferred reseller to learn more.

So, can you use Arial in your app? That depends on how you acquired Arial and the license that was in force when you got it. It is best in this case to NOT embed Arial in your app, but to allow the operating system to supply the resource. Every modern computer on the planet started life with Arial installed, so it’s a pretty safe bet that it resides on your customer’s computer. For other fonts, look closely at the EULA that came with that font. You may find that there is no limitation and you may find that there are explicit limitations. If you have some old fonts lying around, those EULAs tended to be pretty lenient until recently, because there was no idea of Rich Internet App or mobile app when they were struck. Those EULAs remain in force, so you might have some hidden gold in those old floppies out in your barn.

Share on Facebook