In my developerWorks article, "Optimized and Predictable Ajax applications," I talked about browsers' inherent limitations on running Ajax applications and what pitfalls to avoid, including some helpful solutions for optimizing browser differences.

In this article, I go one or two steps ahead. I'll explain how you can protect your piece of digital content—whether it be documents, audio tracks, video clips, or cropped images that end users can download with their favorite browser. I'll show you what you need to know about the DRM technology to achieve DRM interoperability from device to device. I'll explain the different user impacts based on whether your company is using the DRM technology or standard for commerce, privacy, or non-commercial use. And finally, I'll show you how to put the criteria in your browser to help a user choose one or more usage rights.

User goal

One user goal is to download digital content and be able to transfer or share the content from one device to another, each one from a different vendor. This is not possible with the proprietary DRM technology.

DRM technology limits what you can do with the content after you download it and how many times you can access it if you are not allowed to save it. The content owners and providers can specify how their work can be consumed, reused, managed, and transferred. They use this technology as one of the ways to prevent copyright violations.

You may be allowed only to display it publicly, make digital public performances of the work, and consume it in other ways, but you may not reuse, manage, or transfer it. You may be allowed only to consume, reuse, and transfer it, but not to manage it. If they allow you to transfer to another device from your device, you may not be able to make the transfer. They can use DRM technology to restrict you to use certain devices to run the same content. This makes it difficult for you to sell, lend, give, or lease the content.

For example, if you are allowed to give the content you downloaded and paid for as a gift, the recipient may not be able to run it on his or her device because it is different from yours. If the gift is not returnable, you've wasted your money. The goal of being able to transfer the content is not achieved.

The problem: no interoperability

DRM technology is usually dependent on the hardware and operating system, making it more difficult for the DRM for one system to interoperate with another system. DRM technology becomes an obstacle to users' goals to use the content on the devices they choose, or to try out the content before they buy.

Digital content downloaded from one provider is often associated with and supported on only one type of device. The movie and recording industry, online music stores, and electronic book publishers all use their own specific DRM technology to control access to their data. They do not allow the users without a permission to copy DVDs, store the content on a personal computer or a server, or play it back on MP3 players, for instance. This is because DRM technologies do not have a protocol that allows for the exchange of permission information.

In addition, it is questionable whether the DRM technology helps content service providers make more money. Publishers and authors who give away free ebooks still make money, and so do the musicians who give away free music. However, content providers who give away their works can be limited due to the interoperability issues between some devices. They must either pick a device to support or have multiple versions of their content for different devices.

The answer: interoperability

To get around the problem of switching incompatible devices, we need to increase interoperability through DRM standards.

Interoperability allows vendors to sell their content and content service providers to provide services to a wider audience, making their products and services more desirable and useful. Interoperability can also be accomplished by adding open standards to DRM methods based on Creative Commons (CC) ideals for commerce—not just for home office use—without completely relying on those ideals. It is the responsibility of the content vendors and service providers to fully disclose what devices are not compatible or interoperable, if any.

Mobile DRM standard

The Open Mobile Alliance (OMA) has established OMA DRM as the most widely available mobile DRM standard. This standard is designed to support DRM throughout the entire mobile value chain including content providers, mobile network operators, network infrastructure providers, and playback manufacturers. Furthermore, it provides consumer identity protection that the DRM technology does not have.

The OMA DRM standard comes with a license that a user must agree to, defining what permission the content owner, content provider, or other member of the value chain can grant the user. To represent the license, the group adopted Open Digital Rights Language (ODRL), creating the OMA Rights Expression Language (REL) specification.

ODRL can be used within trusted and untrusted systems for both digital and physical assets. To provide cryptographic rights protection, RSA Security supports OMA DRM and ODRL. RSA Security also provides support for legal peer-to-peer distribution and subscription service for all playback devices. They include mobile phones, laptops, portable digital music players, car audio systems, and PDAs.

Beyond sharing rights

One drawback is that the OMA DRM focuses on the content owner and other members of the mobile chain. The content consumers are excluded from this chain on their "sharing" rights. To fill in this gap, the CC licenses allow authors to express permissions for others to share, remix, and reuse content. The Creative Commons Rights Expression Language (ccREL) builds upon the Create Commons licenses, which are embeddable machine-readable legal instruments.

In reality, "sharing" rights are not enough. You should go beyond these rights by supplementing the Creative Common licenses with open standards, such as ODRL rights as specified in its Foundation Model. Before you begin the process of supplementing the CC, you will need to map directly between CC and ODRL rights to search for any possible conflicting rights that you must resolve. Before we discuss DRM implementation based on CC ideals, supplemented with open standards, let's take a look at the components of the CC licenses and then the ODRL Foundation.

Inside Creative Commons

The CC licenses fall into three categories: Permissions, Requirements, and Prohibitions. The CC Permissions and Requirements map directly to ODRL's Permissions and Requirements rights.

CC Permissions

All licenses must include two Permissions: Reproduction and Distribution. Reproduction includes the right to copy the work and the right to reformat the work. This allows the private end-use rights which ODRL makes more explicit in its Usage entity of Play, Display, Execute, and Print permissions. In addition to the right to distribute work, Distribution includes the right to display the work publicly and to make digital public performances of the work (webcasting).

Since the CC Reproduction right is broader than the ODRL Print right, any expression, including Reproduction and ODRL Print, repeats some of the same rights. There may be an issue if the Print right includes a Constraint—then the Reproduction right will be in conflict with the ODRL Print right.

CC Requirements

The CC Requirements entity includes ShareAlike, requiring that derivative works must be licensed under the same terms as the original work. It is not possible to map the ShareAlike permission to ODRL. "Sharing" rights are not available as ODRL rights.

CC Prohibitions

The CC Prohibitions entity does not map to any ODRL right. That's because Prohibitions prohibits commercial use, while ODRL rights implicitly permit both commercial and non-commercial use.

ODRL Foundation Model

ODRL Foundation Model consists of three core entities: Assets, Rights, and Parties. The Rights entity includes Permissions, which can contain Constraints, Requirements, and Conditions. The Permissions entity is the actual usages or activities allowed over the assets (for example, play a video with audio on). Constraints are limits to these permissions (for example, play the video for a maximum of three times). Requirements are the obligations needed to exercise the permission (for example, pay $5 each time you play the video). Conditions specify exceptions that, if true, expire the permissions, and renegotiation may be required (for example, if the credit card expires, then all permissions are withdrawn to play the video).

Permissions entity

The Permissions entity consists of four usage entities: Usage, Reuse, Transfer, and Manage. Permissions show how assets can be consumed and the rights over how the assets may be transferred and reused. Digital assets are managed in the section on DRM implementation. None of the permissions entities allow the consumers to have "sharing" rights. I will show you how each entity is applied to the assets in the section on permission examples.

Constraints entity

The Constraint entity imposes restrictions on the permissions over the asset, such as specifying that the user be an individual or group, what device the user must use, how many times the user can use or reuse the content, and when the user can use the content. Other restrictions include whether the user needs permission to transfer the content, in what format the content must be, and who the target audience is.

Requirements entity

The Requirements entity consists of three preconditions. They must be met in order to obtain the related permissions, such as what the fee should be (pre-pay or per use), whether interactions should be done by accepting or registering, and how usage should be, by attribution or tracked.

ODRL permission examples

Below are some examples of how assets can be consumed, how the rights over the assets can be transferred and reused, and how digital assets are managed.

Usage permission

The content owners and providers can specify on what methods you can consume their works. They can specify what browser you can use to display the content, whether you can print the content publicly or make digital public performances of the work, how many times you can print it, how many times you can play it, and whether you can execute a utility program to play or display the content.

Reuse permission

The content owners and providers can specify on what methods you can reuse their works. They can specify whether you can modify it, how you can annotate it, whether you can combine it with other content that you developed, and how many times you can aggregate it.

Transfer permission

The content owners and providers can specify whether you can transfer it from one device to another. They can specify how many times you can sell, lend, give, or lease the same content and what conditions they will use to terminate the agreement to transfer the content.

Manage permission

The content owners and providers can specify whether you can move, duplicate, delete, or verify the content you downloaded from one device to another. They can limit whether you can backup and restore the content. Some may not want you to save the content while you are accessing it. Some allow you to install and uninstall only one time; they want you to pay an additional price for a new installation. A few may require you to connect with their Web sites to activate the software you need to download the content.

Examples at a glance

Table 1 gives you a capsule of permission entity examples that I have already talked about.

Implement DRM

The ability of content owners to restrict reuse of their works leads to a wider range of consumer choices of usage rights through specialized or personalized options on the browser. Consumers can choose one or more usage rights through DRM standards that encourage some CC ideals supplemented with an open standard such as ODRL.

To accomplish this, Web designers can design cross-browser menu options of diverse DRM services the consumer can choose. The content owner or provider can set constraints and price requirements on some usage rights. The browser can show a history of consumer purchases from a database and then disable certain usage, transfer, or sharing rights after the content has been accessed a certain number of times.

Personalize options

The ability to design different services enables producers to discriminate price with regard to buyer tastes, potentially enabling greater revenue recovery. For example, the ability to download, burn, and lend a legally accessed movie could be priced differently than the ability simply to view the work without making further transmissions or reproductions. The ability to play one time with audio turned on could be priced differently from the ability to play one time with caption on.

Subscribing to play for a maximum of three times with audio, caption, and translation features on could be priced more than copying multimedia onto CDs with the license agreement. Sharing rights with the ability to play and print could have a different price than the ability to play and print without sharing rights. If consumers cannot find the usage or transfer rights they are looking for, they could contact the content owner or provider for special prices.

Choose usage rights

Table 2 shows sample consumer choices of usage rights on the browser.

Conclusion

This article helps you plan ahead to supplement CC licenses with open standards. Potential users' demands for choices of services on one device or shared among several devices presents a challenge for the content owner and provider in generating revenue. Being aware of potential issues and creating solutions such as designing menu options and storing consumer choices in a database can make your development team's and your users' experiences trouble-free.

discuss this topic to forum