Can e-Publishing Overcome Copyright Concerns?

[DMcCunney]

Originally Posted by nekokami

Hm. But if you get ePub as your intermediate format, and the Mobipocket (or whatever) desktop software takes in the ePub file and loads the Mobi formatted version onto your reader, does it matter that it just did a conversion for you? I think a lot of people have or expect some kind of main computer book management system. (I don't, but I'm a geek. I also drive a stick shift by preference. )

That works, too. The point is simply that it needs to be seamless and transparent to the user. The user simply wants the book in a format she can read on her device, and ideally should need to neither know nor care what that format is.

If I had to have DRM, I suppose the eReader method of using a credit card number could be ok, but it still relies on some software being ported forward to any system I might want to use in the future. I'd rather not have to rely on that sort of goodwill (or longevity).

Nor would I. But a CC number is simply a unique key to use in creating the passphrase to unlock the encryption. The advantage to using a CC number is that you aren't likely to give it out, and thus not likely to copy and share to book with others.
______
Dennis

[tirsales]

Really - whats the point of DRM?
If you want to tell the user "we could sue you" - okay. Use watermarks and user-customized branding. Not more security but not less then with DRM (possible even more because fewer people would remove it). You could even leave that whole stupid "register your device, your credit cards and your wifes panties size here" idea out.

Regarding ePub as an intermediate formate .. Why not give ePub to the customer? Your reader-software could be able to convert ePub to the reader-format on the fly and without the user knowing, or the reader could support ePub directly.
But I dont really care about the format - as long as it is an open standard, easy to implement (e.g. NOT ooxml) and uses no drm whatsoever.

[Steven Lyle Jordan]

Originally Posted by DMcCunney

As it happens, I can do the format conversion. I have the software and technical skills. So could you. Most people couldn't, and shouldn't be expected to.

But if your device already has on-board conversion SW, such that you just upload the ePub and the device auto-converts to the appropriate format, the user doesn't have to lift a finger. That's what I'm talking about.

The reason I think that's a better system is that the publisher only has to send you one file, once. You don't have to repurchase, or even go back to the publisher's site for another download for your purchased file (which they'd have to keep track of... more databases tracking your moves and purchases), every time you get another device. Once you have the ePub file, the publisher is out of it.

[DMcCunney]

Originally Posted by Steve Jordan

But if your device already has on-board conversion SW, such that you just upload the ePub and the device auto-converts to the appropriate format, the user doesn't have to lift a finger. That's what I'm talking about.

That's fine, if the device does. I don't expect to see that happen, near term.

And if it does happen, it's likely to be for dedicated reader devices like the Kindle or the Sony Reader. If what you use isn't one of those devices, you may be SOL. (Can you see this happening on, say, a smartphone?)

The reason I think that's a better system is that the publisher only has to send you one file, once. You don't have to repurchase, or even go back to the publisher's site for another download for your purchased file (which they'd have to keep track of... more databases tracking your moves and purchases), every time you get another device. Once you have the ePub file, the publisher is out of it.

No, the publisher will still be in it, as you'll likely need to register the new device before you can load/convert the ePub file, if any sort of DRM is in the picture.

My scenario could be implemented now. Yours can't, as it requires software not on reader's devices.

And if the manufacturer is willing to create the software that will let their device automagically convert from ePub to whatever the native format is, their time and effort is better spent on software upgrades that will let their device read ePub native in the first place, and not require conversion.
______
Dennis

[DMcCunney]

Originally Posted by tirsales

Really - whats the point of DRM?

It makes content providers happy.

Regarding ePub as an intermediate formate .. Why not give ePub to the customer? Your reader-software could be able to convert ePub to the reader-format on the fly and without the user knowing, or the reader could support ePub directly.

Doing the conversion on the publisher's end doesn't require updates the the reader software. If the reader software does get an update, it makes more sense for the update to be native support of ePub documents.

But I dont really care about the format - as long as it is an open standard, easy to implement (e.g. NOT ooxml) and uses no drm whatsoever.

Good luck on the last. But remember that DRM and ebook format are two separate issues. All ebook publishers may standardize on ePub as the format, but I doub't they'll standardize on the same DRM schemes.
______
Dennis

[Steven Lyle Jordan]

Originally Posted by DMcCunney

My scenario could be implemented now. Yours can't, as it requires software not on reader's devices.

Maybe... but if publishers don't want the extra work of multiple formats, multiple downloads, etc--which they don't--they just won't.

Yes, my scenario requires every device maker to create the appropriate software for compatibility with standardized formats... but that's not unheard-of in the HW/SW business. Just look at all the e-book devices that have PDF readers. And the first devices to achieve auto-convert, and can tell publishers to just create one format, the pubs will love it.

So: My scenario isn't ready today; and yours isn't being used today. I guess we'll see which one kicks off first!

Originally Posted by DMcCunney

And if the manufacturer is willing to create the software that will let their device automagically convert from ePub to whatever the native format is, their time and effort is better spent on software upgrades that will let their device read ePub native in the first place, and not require conversion.

Very true... why convert, when you can just read e-pub? Though that's logical, there will always be a reader maker that will feel their reader does something special with content (like cue-ing up theme music or mood lighting with certain passages, or something silly like that), so it requires a proprietary format to do it, and thereby must be converted.

I'd guess there will eventually be native ePub readers, and the uber-special Mood-Lighting, John Williams Orchestral Sampler Readers that must convert.

[tirsales]

Originally Posted by DMcCunney

It makes content providers happy.

So do Sex, Drugs and Rock'n'Roll.

Good luck on the last. But remember that DRM and ebook format are two separate issues. All ebook publishers may standardize on ePub as the format, but I doub't they'll standardize on the same DRM schemes.

Yes, and that's why I dont want ANY DRM. DRM offers no protection but still annoys customers, removes the possibility to read a book on the reader you want, etc
In short: DRM is one of the worst ideas that ever crossed someones minds. And one of the least successful and practical approaches to piracy-combat.

[DaleDe]

Originally Posted by Steve Jordan

Maybe... but if publishers don't want the extra work of multiple formats, multiple downloads, etc--which they don't--they just won't.

Yes, my scenario requires every device maker to create the appropriate software for compatibility with standardized formats... but that's not unheard-of in the HW/SW business. Just look at all the e-book devices that have PDF readers. And the first devices to achieve auto-convert, and can tell publishers to just create one format, the pubs will love it.

So: My scenario isn't ready today; and yours isn't being used today. I guess we'll see which one kicks off first!



Very true... why convert, when you can just read e-pub? Though that's logical, there will always be a reader maker that will feel their reader does something special with content (like cue-ing up theme music or mood lighting with certain passages, or something silly like that), so it requires a proprietary format to do it, and thereby must be converted.

I'd guess there will eventually be native ePub readers, and the uber-special Mood-Lighting, John Williams Orchestral Sampler Readers that must convert.

A more pressing need for convert is the one posed by Mobipocket. They have a multitude of platforms, many on low horsepower machines. Converting on a PC is an easy solution for them and it is available today with the 6.2 release of the windows version. ePub support requires a fair amount of horsepower to be compliant. I think this is an oversight of the committee.

Dale

[DMcCunney]

Originally Posted by Steve Jordan

Maybe... but if publishers don't want the extra work of multiple formats, multiple downloads, etc--which they don't--they just won't.

What extra work? The effort is up front. Once the infrastructure is in place, things happen automatically.

The publisher must do the markup and get the manuscript into ePub format. Once done, a conversion routine sucks up ePub files and spits out conversions to Mobi, LRF, what have you. The converted files get uploaded to the server that handles distribution. The user orders a book from the website, pays for it, and downloads it. The website is likely keeping an account file for the user in any case with things like CC info. The format the user requires is something that can be kept in the account record, and only needs to be updated if the user changes devices.

Most of the infrastructure will already be in place if the publisher sells ebooks, as the books must be put into electronic format and made available for sale over the web site. The main differences will be use of ePub as the master format, and the conversion routines to create the files provided to the customers. But once that's in place, no additional work is required, because it happens automatically as part of the production process.

Scale matters. Making this happen may be a major undertaking for a one man shop like you, and probably more effort than would be justified by the returns. It's not a major effort for a major publisher who already does electronic publishing.

Yes, my scenario requires every device maker to create the appropriate software for compatibility with standardized formats... but that's not unheard-of in the HW/SW business. Just look at all the e-book devices that have PDF readers.

First you need agreement on and adoption of said standardized formats. Lack of an ebook standard is one of the problems we're talking about.

And the first devices to achieve auto-convert, and can tell publishers to just create one format, the pubs will love it.

Like I said: why auto-convert? Just support the standard format in the first place.

So: My scenario isn't ready today; and yours isn't being used today. I guess we'll see which one kicks off first!

Agreed. I made a proposal that could be implemented as a work around for the fact that there isn't a standard format everyone supports. The issue isn't on the publisher's end, so much as the user's. ePub is all well and good, but who issues books in that format, and more important, what user software reads it?

Very true... why convert, when you can just read e-pub? Though that's logical, there will always be a reader maker that will feel their reader does something special with content (like cue-ing up theme music or mood lighting with certain passages, or something silly like that), so it requires a proprietary format to do it, and thereby must be converted.

Good luck to them, but extensions like that are outside the scope of ePub and not standard. Supporting it is their problem, and if conversion is required, they'll have to do it.

I'd guess there will eventually be native ePub readers, and the uber-special Mood-Lighting, John Williams Orchestral Sampler Readers that must convert.

The question is when there will be native ePub readers. I'm not holding my breath, and I suggest you don't either.
_______
Dennis

[DMcCunney]

Originally Posted by DaleDe

A more pressing need for convert is the one posed by Mobipocket. They have a multitude of platforms, many on low horsepower machines. Converting on a PC is an easy solution for them and it is available today with the 6.2 release of the windows version. ePub support requires a fair amount of horsepower to be compliant. I think this is an oversight of the committee.

Mobi isn't the only one. eReader suffers a similar handicap.

I read Mobi files on a Palm OS PDA with a 200 mhz CPU and 128MB of RAM. Maybe Mobi could support ePub directly on the device, and maybe not. Same for eReader. And what about folks using Symbian based smartphones, or something like the Blackberry with a Java based setup?

Direct support of ePub would be problematic, and I really can't see conversion from ePub to native format on the device.

This is another reason why I think ePub has a better chance as an intermediate format used by publishers, which can be converted to the format the reader will use.
______
Dennis

[DaleDe]

Originally Posted by DMcCunney

Mobi isn't the only one. eReader suffers a similar handicap.

I read Mobi files on a Palm OS PDA with a 200 mhz CPU and 128MB of RAM. Maybe Mobi could support ePub directly on the device, and maybe not. Same for eReader. And what about folks using Symbian based smartphones, or something like the Blackberry with a Java based setup?

Direct support of ePub would be problematic, and I really can't see conversion from ePub to native format on the device.

This is another reason why I think ePub has a better chance as an intermediate format used by publishers, which can be converted to the format the reader will use.
______
Dennis

I agree. There are lots of devices that are going to be strained to fully support ePUB. I only used Mobipocket because they have already done it this way and they did the same thing with the earlier OEB standard. It also points out that it has already been done contrary to what was stated in this thread.

You also said:

What extra work? The effort is up front. Once the infrastructure is in place, things happen automatically.

I guess you never worked in IT. There is always changes to deal with in software. It is never just automatic and then forget it. New versions have to be tested and integrated. Workarounds have to be revised. Source documents may even need changing.

Dale

[DMcCunney]

Originally Posted by DaleDe

I guess you never worked in IT. There is always changes to deal with in software. It is never just automatic and then forget it. New versions have to be tested and integrated. Workarounds have to be revised. Source documents may even need changing.

Wrong guess. About 25 years worth of IT in one form or another, starting on IBM mainframes running OS/VS1 and MVS, and working down though DEC PDP-11s runnig RSTS-E and RSX-11M+, DEC VAXen running VMS, IBM PCs and an assortment of other things. These days I'm mostly a Solaris guy, with Linux in the mix. (A Sunfire X100 server is sitting under my monitor, with a background project to get Solaris 10 up on it and add it to my network.)

Yes, there are software changes, but those are part of what IT does. The point was that once you build the pipeline and automate the work flow, it's built.

The hard part is getting it all set up correctly in the first place. Maintenance should be a relatively minor effort. The point is that using ePub as the master format, and supporting Mobi, Sony LRF, etc. as output formats done by automatic conversion shouldn't be enough extra work to make it infeasible.

It doesn't even have to be done by the publisher. There are third party editorial production houses that do that sort of thing as a service.
______
Dennis

[DaleDe]

DMcCunny - you clearly have no reason to have said that it is no work to do with your experience. I agree with your expanded statement but the original statement was to simplistic and wrong.

Dale

[DMcCunney]

Originally Posted by DaleDe

DMcCunny - you clearly have no reason to have said that it is no work to do with your experience. I agree with your expanded statement but the original statement was to simplistic and wrong.

Simplistic? Yes. Wrong? No. It depends upon whose perspective you are using.

I simplified and glossed over the implementation details because they weren't germane to the discussion. Sure, if you're the IT guys making it happen, there's work involved. But once you've implemented it and validated that it works correctly, you turn it over to the users and off they go. There will be the occasional glitch or need for maintenance, but there always is, and this shouldn't require any more effort than other major parts of the publisher's workflow.

The concept is that the publisher's production people take an author's manuscript and mark it up for publication, using an application like Adobe InDesign. InDesign outputs an ePub file. Another process takes the ePub file and converts it to Mobi, Sony LRF, or other electronic formats. Another process can take the converted files and place them in the appropriate place on the server where they can be stored for download to the customer buying the titles.

It should be possible to automate everything after the markup. In that scenario, maintaining six different digital editions of a title really isn't any more work than maintaining one. It all happens automatically as part of the process that creates the electronic edition.

How feasible this is depends upon who the publisher is. A small press or a one man shop like Steve might not have the resources to do it. A major trade publisher should.

And the purpose of doing it is simple: to provide the customer with books they want to read in formats they can use. The user should be able to buy the book, download it, put it on whatever device they use to read it, and read. They shouldn't have to worry about the technical details.

The publisher needs to make it as easy as possible for the customer to buy ebooks from them, and beyond specifying when they create their account what they will use to read the books, they should not have to be concerned with what the format is.
______
Dennis

[nekokami]

It's already being done. See Feedbooks.