The International Digital Publishing Forum (IDPF) has just published a request for feedback. They want to hear the opinion of technical and user experience experts on a new draft revision to the Epub specification.
Update: I just finished reading my way through the use cases. They don't actually fit the goals mentioned in the first 2 thirds. They don't specify a light weight DRM but instead discuss restrictions that would require DRM as heavy as used by Adobe. Silly me, I thought the different sections would agree. (The rest of this post assumed that the proposed DRM actually would be lightweight.)
While past revisions have covered various technical details for the Epub spec, this one covers DRM, and more importantly it's a first look at ways to add DRM to an Epub that:
- one, doesn't bother the user,
- two, isn't quite so expensive to use (here's why, and here's why),
- three, has less onerous hardware requirements, and
- four, still acts to minimize or discourage piracy.
If you're thinking that the first and fourth points sound familiar, they should. Pottermore, home of the Harry Potter ebooks, launched their ebookstore with a type of DRM that
comes fairly close to meeting the goals of the proposed draft, while it doesn't meet the use cases mentioned in the draft, it does offer some useful features that I wish would be adopted. They use something called digital watermarks to add identifying info to the Epubs they sell.
These watermarks effectively are little bits of data buried inside the ebook. Unlike other forms of DRM, a unique digital watermark is created when each copy of an ebook is generated. This lets the ebookstore add something to the ebook which can still be to track down who originally bought (and then pirated) a particular copy of an ebook.
Pottermore's DRM was provided by a Dutch company called Booxtream, and it's the first well known example of digital watermarks (in ebook files).
Consider for a moment what the watermarks allow Pottermore to do. They are selling DRMed ebooks which can be read on any ereader or app that supports Epub, and with a little effort can be read on the Kindle as well. This gives Pottermore a potential customer base that extends far beyond the reach of any of the major ebookstores and in fact encompasses all the major platforms (Amazon, B&N, Adobe, Apple).
If a major ebookstore were able to follow suit, they would be able to sell ebooks which could be read anywhere (with no work to strip the DRM). This would enable that ebookstore to start poaching customers from everyone else - especially the ebookstores who have not yet adopted the lightweight DRM.
Let's get back to the topic. So what's the value of this draft?
This idea obviously can be implemented without the draft, so about all this draft will accomplish is to generate attention for the idea of a lightweight DRM. Okay, anyone who cared to know about DRM already did, but the fact remains that having a formal spec would be a lot more impressive than simply arguing for the idea.
Consider for example the media conglomerates who own the Big 6 publishers. These major publishers have been stalwart users of DRM, but in some cases the DRM was foisted on the publisher from above. That's certainly the case with Tor-Forge books, who had reportedly wanted to go DRM free a decade ago.
If and when this spec is completed, it will open up an opportunity for publishers to go wave it under the nose of their myopic bosses. And that is what I'm really looking forward to.
But it's also going to give developers a set of requirements to work towards. Right now Booxtream is the only company I am aware of that offers this kind of DRM, so I would really like to see them get some competition. This will drive down the cost of using it, so we'd all benefit.
And, with luck, someone in the open source community might decide to release their own set of code which meets the new standard. That code would cost almost nothing to integrate into an ebookstore, thus reducing the cost of building and running it.
This is a win-win-win-win scenario here.
image by wilhelmja