Lulu No Longer Allowing DRM Protection, one of the leading print-on-demand services around, announced that they will no longer be accepting files that make use of Adobe’s DRM protection for EPUB and Pdf files. Further, all files that are currently on Lulu with the protection will be required to have that protection removed from them before they can be sold again. Why? Here’s the official explanation:

DRM works best when administered by those who control how content is purchased and viewed. Companies like Amazon, Apple and Barnes & Noble integrate a reader’s experience from purchasing to downloading and finally to reading. These companies do a fantastic job in this area, and eBooks published through Lulu and distributed through these retail sites will continue to have the same rights management applied as they do today.

For readers who download eBooks directly from to the device of their choice, removing DRM on EPUBs and PDFs will remove their need to create an Adobe account, authorize the purchase in Digital Editions or install a third-party application. This creates possibilities for the growing number of readers who want to shop, purchase and download books to their eReaders from sites other than large corporate providers. 

In other words, it seems that Lulu has discovered that they’re losing sales because small publishers want to have DRM protection on their files, and having that protection introduces another step.

Now, I fully understand the arguments in favor of this move, and certainly Lulu has a right to do whatever it wants to do as a company. However, if I were a publisher with them, I’d feel more than a little miffed at the condescending attitude that “the big boys know how to do this right, but you don’t, so we’re taking away the option for you.”

If the argument is, “DRM is a flawed technology that ultimately hurts both producers and consumers of media”, then allowing it for Amazon and B&N but not for smaller publishers smacks of hypocrisy. If it’s bad for me to use it, it’s bad for Amazon to use it, and Lulu should take the principled stand and remove their works from those distribution outlets until they stop using it, too.

But here, the argument simply seems to be “We want to make more money, and so we’re removing an option that some of our publishers choose to avail themselves of,” and I personally find that less than idealistic. Let the producers of the content make the decision, and live with the consequences, good or ill.

Written by 

Wargamer and RPG'er since the 1970's, author of Adventures Dark and Deep, Castle of the Mad Archmage, and other things, and proprietor of the Greyhawk Grognard blog.

2 thoughts on “Lulu No Longer Allowing DRM Protection

  1. Actually, the way I’m reading that is that Lulu isn’t offering DRM on Amazon either. Amazon is offering DRM on Amazon, and it can still apply to works published via Lulu. “They include encryption applied by the retailer.”

    I can offer my personal experience, which is that the only DRM’d PDF I bought on Lulu turned out to have the DRM applied incorrectly by the seller which meant I couldn’t see any of the images, which were the reason I’d bought the book; they had to spend several man-hours tracking that down, and in the end refunded my purchase (and probably other people’s too), remove the book, and ask the seller to fix it.

    As a buyer, I was generally happy with how Lulu handled it; as a person who also uses Lulu to print, I thought, having to deal with DRM is one of the reasons Lulu books cost more than I’d like.

    This move appears to mean that when a purchaser has trouble with DRM, it will be Amazon’s (or Barnes and Noble’s) problem to deal with, not Lulu’s.

  2. Yeah, what I get out of their explanation is that LULU are acknowledging that they themselves are having trouble supporting DRM that they themselves don't control, and they don't care enough about DRM to control a DRM solution, so they're getting out of it altogether and letting others deal with it.

    Less DRM is a win for any reason, in my book.

Comments are closed.