A serious issue for big publishers

Posted by Mike Shatzkin on April 14, 2009 at 5:32 am · Under General Trade Publishing, New Models, Publishing


The Google settlement brings into bold relief what has been a quiet issue for book publishers, particularly the biggest ones.

They are largely in the dark about what rights they own.

It is not really hard to understand why they’re in this position and it isn’t really anybody’s “fault”, but it sure is a mess. The “rights database” or “contracts database” for most publishers consists largely of paper contracts in file drawers. That’s because all the big publishers gain a substantial portion of their income from backlist that was acquired years, decades, or even many decades ago, long before electronic rights databases were even conceived of.

There have been big improvements in the possibilities for storing this data in recent years. We’ve written extensively about StartWithXML processes and the idea that the rights information could “travel along” with the content in an XML document. That’s new stuff. So is the Klopotek system that actually builds the publisher-author contract from a rights database; the workflow had always had this work the other way around.

But these solutions, even for publishers farsighted enough to employ them, don’t solve the problem of thousands of legacy contracts in file cabinets. The Google-related issues primarily revolve around whether the rights to an inactive book (or, in the settlement lingo, what they would call “not commercially available”) have reverted to the author or are still held by the publisher.

Publishers also have problems with books on which they unambiguously have the rights to print and sell copies. What they don’t know, without looking at the original contract, is whether the language in it gives them a shot at an ebook, a print-on-demand edition, or allows them to include some of the material in that book in an electronic database. Even looking at the book contract might not tell them if they have the rights to use artwork that is in the book in any other edition. 

We are working on a future post on “business development”, which we figure is a big opportunity for publishers who have digitized a large amount of legacy content, which many (if not all) of the big publishers have. But any hopes of business development are stopped in their tracks if a publisher doesn’t know what rights are controlled.

The challenge of building a comprehensive rights database for the many tens of thousands of titles the big publishers control is probably cost-prohibitive. And even if money were no object, there would be a lot of empty cells in that database where information should be because contracts would be lost or incomplete. Figuring out how to attack that problem cost-effectively is one of the most important puzzles facing the senior executives of the major houses.


  Back to blog

  • Mike, thank you for your thesis. I particularly agree to the described need that rights, structural contract data (rights is an important part, but we also need to store royalty rates, terms, …) and printed/signed contract must be kept together.

    Keeping the structural contract data and the printed/signed contract aligned is not a simple task. How often have we seen that a contract addendum has never found its way to the royalty database. I would also like to underpin your statement that the only working solution is to give up handmade contracts and to produce the contracts from the structural contracts and rights data.

    @ Gwyn: I appreciate that building a database is by no means as complicated as some people describe it. However, a database alone has limited value. Value comes from functionality on top of data, and this is software, and this is not easy, always underestimated and time-consuming. An example: It is not a bad idea to store the acquired rights and the sold rights in a database. But real value comes, if a rights sale function looks into the acquired rights data if you try to offer or sell rights, and if this function tells you what you can do and what you cannot do. When we look at the Klopotek CR&R software, I would estimate that database design including all the simple store and retrieve functionality is less then 10% of the development effort. 90% is functionality. It is questionable whether a publisher wants to build this alone.
  • Gregor,
    Quite right that the royalty rate and term detail is essential along with the rights information. But that's a philosophy for going forward. The legacy problem that publishers have to identify information that is within the contract is a huge task even without adding in this other information which would not be in the contract.
    And we agree that these challenges lend themselves to "best practice" solutions that are probably best developed by a third party acting on behalf of many publishers, rather than by any publisher alone.
  • Greg
    Mike, I think this is the takeaway:

    "What they don’t know, without looking at the original contract, is whether the language in it gives them a shot at an ebook, a print-on-demand edition, or allows them to include some of the material in that book in an electronic database. Even looking at the book contract might not tell them if they have the rights to use artwork that is in the book in any other edition."

    The language of contracts has changed to make it difficult for any rights system to exist beyond a year after its current state. How does a publisher know if it can put a title on Scribd if the contract was written in 1970? The lawyer reads it and makes an interpretation of the original language. Unfortunately, these interpretations are not easily allocated to silos in a rights management sytem. I think a question for publishers to ask is whether they still have open dialog with authors that they'd like to continue publishing as new media forms pop up. If they do, the partnership could have a higher chance of continuing.
  • Greg, you are quite right that "all technologies hereafter invented" or whatever catch-all language people tried to use in years past are hard to apply to current contexts. No doubt that ongoing communication with authors is by far the best solution. But, as you know, there are lots of books that still sell big numbers where the author is no longer engageable. There are many situations where it would be best if there could be a dynamic "working out" of things with the author, particularly as we move to new commercial models. It is extremely difficult to develop that kind of relationship; agents tend to insist on highly defined contractual relationships (which isn't necessarily "wrong", but which certainly doesn't help build the kind of flexible interaction that would best suit these times of change.
  • Don Linn
    Mike, you are absolutely correct about the size of this task. We are a small publisher with only 30 years of publishing history but typically have multiple contributors (authors, photographers, artists) in our titles. For many years, rights management for us (and most others) has been a filing task.

    As we are working on digitizing products and on simply completing the GBS spreadsheets for our titles, we realize how big the job of building a comprehensive rights database is. We also realize we can't afford not to do it.
  • This is one of the many costs of the transitional era of publishing we are in. We're supporting the old business and needing to invest to create the new business, even thought we don't know exactly what the commercial model of the new business is going to look like. This business is going to keep getting more challenging for some time, even for smart niche-oriented publishers like yours.
  • Building a big database is by no means as costly as the people who sell big database systems would have you believe — as long as you know what you're doing and whom to ask. And empty fields do not impinge on the functionality of the asset; rather they represent a challenge to a dedicated and curious systems administrator, who would start asking the right people the right questions in order to get those fields filled in.
    fotoLibra has built 92 separate but related databases to service the needs (including comprehensive rights data) of 300,000 assets, a more complex scenario than any book publisher is likely to have to deal with. Once constructed, it's infinitely expandable and needs relatively low level maintenance.
    The major costs would be the sys admin and the data entry. Then it's off to the beach.
  • Indeed, the big cost in this database is the data research and entry. If somebody can figure out a way around that, it will be a big deal.
blog comments powered by Disqus

« Times Book Review on advances, and related thoughts
The Google settlement and unanswered questions, particularly about the windfall »
Go Back | Top