EULA questions on FlashPaper branding and customization

Macromedia FlashPaper is a very exciting tool for "printing" SWFs from any application (it ships as part of Contribute 2 and is not available by itself.)

FlashPaper is initially aimed at the consumer market for creating standalone FlashPaper SWFs -- which will, Macromedia must hope (and I believe), eventually replace PDFs. That's not, however, the use case that concerns me currently. What is infinately more exciting to a Flash developer is the ability to include external FlashPaper SWFs in your own applications, thereby transforming FlashPaper from a standalone PDF alternative to a truly embeddable PDF alternative -- a document display component for Flash, if you will.

The advantages offered by having a simple and accurate document display component for Flash are clear. What doesn't appear clear currently (since the release of the FlashPaper API) is whether or not developers are allowed to brand (or remove branding from) embedded FlashPaper SWFs and the extent to which they are allowed to alter the UI of an embedded FlashPaper SWF.

It would seem logical that developers looking to integrate Flashpaper into their Flash applications as a seamless element will want to brand and/or remove branding from the FlashPaper SWF and/or alter its UI to fit the appearance, flow, etc. of the UI of the greater application. The current MM EULA states that the interface cannot be altered. This is a prohibition that the Flashpaper API itself, it would seem, contravenes as it *does* allow parts of the UI to be turned altered (for example, the page navigation, print and zoom controls and be shown/hidden using provided public methods.)

The EULA states:
3. License Restrictions

n. Notwithstanding anything herein to the contrary, you may not (A) install FlashPaper Printer on a server for multiple user access or use, or (B) modify or replace the FlashPaper Printer viewer user interface that displays FlashPaper documents.

In many cases, having a Macromedia FlashPaper branding clip hotlinked to macromedia.com in a FlashPaper SWF that is embedded within a greater application is not desirable (if only because it adds to the noise of the greater UI, allowing one more point of confusion for your user.)

Ideally, developers should be able to alter an embedded FlashPaper SWF's UI without restriction to allow them to skin the component and integrate it fully with their application UI. A fitting requirement here would be that the developer is mandated to include the Macromedia Flashpaper copyright (or a "Includes Macromedia FlashPaper technology" message of some sort) -- hotlinked to macromedia.com, if necessary -- in her application's About box or in the credits or wherever the application's copyright message resides. Anything more than this would probably be a hindrance to the adoption of FlashPaper as an embedded element and I believe that it is as an embedded element that FlashPaper could most benefit Rich Internet Applications. It is also my hope that Macromedia will allow developers to license FlashPaper for server-side use. After all, why restrict this through the EULA when you can make money from it by licensing it?

Everything in an externally-loaded FlashPaper SWF can be manipulated through ActionScript, of course (so there isn't a technological barrier to not being able to modify a FlashPaper SWF's UI.)

e.g. (Where the "inner" movie clip contains the FlashPaper SWF)

// hide the toolbar:

_level0.outer.inner.toolbar_mc._visible = false;

// hide the branding clip:

_level0.outer.inner.toolbar_mc.brandClip_mc._visible = false;

// change the branding URL:

_level0.outer.inner.brandURL = "http://www.google.com";

It would be great to know what Macromedia's view towards this issue is. Is there a specific license developers can buy in order to legally brand FlashPaper SWFs (or hide their branding) and/or alter FlashPaper SWF UIs beyond what is currently possible with the public API?

The current trend appears to be towards opening up FlashPaper to developers -- a move I wholeheartedly applaud. I hope that this issue with the EULA will be cleared up as well so we can proceed with integrating FlashPaper into our applications without EULA worries (let's not relive the Flash component EULA issues -- once was more than enough!)

Comments