Tech Book Contracts

Several tech authors recently contacted me for advice about problems with their publishers. (No publisher in particular, mind you.) Apparently I’ve been doing this long enough that I’m considered an expert. I’m writing this post so I can point these people at it later.

If you’re a tech author thinking of asking for my wisdom: this is basically it.

None of this is anything against any particular publisher or any particular writer.

This is not legal advice. I am not a lawyer, nor do I play one on TV, nor do I write stories involving lawyers.

No, I will not look at your publishing contract.

I’ll point you to resources for fiction authors. Genre authors have been bludgeoned over the head repeatedly with this stuff. Tech book authors? Not so much. Most tech authors are technologists first, gamers second, have another hobby or a family or something, and write books as a distant fourth or fifth. Fiction writers who make a living writing have been forced to defend themselves against predatory practices. (“Fool me once, shame on me. Fool me and all of my peers for years, we will gang up on you and burn down your house.”)

Now that the disclaimers are done:

So, you’ve written a tech book. Or you want to write a tech book. You’ve found a publisher. They express interest, and send you a contract. Hurrah! You’re going to be published! An antload of fame and a soupcon of fortune will be yours!

STOP.

Do not sign the contract.

Techies in particular have a disdain for paperwork, but the wrong contract can ruin your life. Even if you know the publisher. Even if the publisher is your best friend, like, ever. Even if you’ve been trained to automatically click on “I accept the license terms.” Overcome that disdain.

READ THE DANGED CONTRACT.

Maybe Microsoft isn’t going to come after you for that extra copy of Windows 95, but your publishing contract is much more personal. It’s aimed at you. And contracts tend to favor the side that writes the contract. Even the most scrupulously even-handed contract by the most good-hearted publisher in the world includes provisions where you agree to do stuff. It’s not as simple as “you write the book, you get paid.”

By signing the contract, you’re agreeing to do what the contract says. The written contract overrides anything verbal. That handshake deal? Utterly worthless. The email paper trail? Also worthless in the face of the contract. Mutual understandings? Nonexistent.

A publishing contract exists between you and the publishing company. The publishing company is not the nice acquisitions editor you’ve been talking to. It’s a legal entity owned by someone. That legal entity can be sold to another entity at any time. The new owner can fire the nice editor and assign you one with a ninth grade diploma and a deeply rooted, highly personal distaste for your work, your subject, your family, your religion, your college, and your personal aroma, who wants to know what button to push to make Microsoft Word do this FECN thing you’re talking about.

I agree that the publisher’s attitude and reputation are important. I work with No Starch Press because they’re awesome to work with. They focus on making the best book possible. That’s great. But:

The only binding agreement is the contract.

Read it. Understand it. Print it out. Highlight anything you don’t understand. Highlight anything that might be a legal term of art. Highlight anything that could be used against you.

What sorts of things should you look for? There are things that real publishers include in their contracts. The exact terms differ, but the bones are there. If any of these things are missing from a contract, the publisher is not a real publisher. Run away. Run away quickly. Put their gmail address in your spam bucket and blacklist their IP address at your network border.

  • Real publishers offer advances against royalties. No Starch has an interesting model where they offer a large advance and a small royalty, a middling advance and a middling royalty, or no advance and a great big freaking royalty. I’m playing a long game, so I take the big royalty — but the important thing is, they offered me an advance and I chose not to take it. (An advance is an interest-free loan against future royalties; you don’t get any more money until your royalties exceed the advance.) A publisher that does not offer a royalty is not a real publisher.
  • Real publishers say what rights they’re buying. This is frequently World English Rights. Some, such as NSP, also buy world rights, sell translation rights, and share the proceeds with the author. Whatever those rights are, they’re spelled out. Authors do not sell books. They license copyright.
  • How long does the contract last? For technology books, “life of copyright” is not uncommon. But tech books have a shelf life. The rights to Windows 2.0 Unleashed for Complete Dummies are basically worthless now. Still, the contract should give a length. It should also include conditions under which the contract can be terminated early, and you get those rights back.
  • Due dates. Can you really fulfill everything in the contract in the stated time? Are you assuming everything goes correctly? What about when things go wrong? What if your appendix ruptures a week before the contract is due? The publisher is signing contracts for printing, distribution, and marketing based on your commitments. If a contract doesn’t include a due date, someone could take an advance and never write the book. I’ve seen a tech book contract without a due date.
  • How will the publisher request changes and/or reject the manuscript? How long will you have to do revisions?
  • When will they publish? They should say they will publish within X days/months/years of manuscript delivery. If they don’t publish, you never get royalties.
  • Will they promote the book? If it’s not in the contract, it doesn’t have to happen.
  • When do you get paid? Publishing has a baroque distribution system, including things like “rolling reserves against returns.” It’s an infuriating system. Any engineer or business person could design better, but the system was built by people who love books. You will get paid… eventually.
  • Then there’s warrants and indemnifications. It’s reasonable to warrant that you are the author of the book, and that you have the rights for all content. It’s not reasonable to warrant your book against any and all possible damages that might be caused by it. If one of my books mortally and morally offends someone and they decide to sue the publisher, too bad.
  • How many copies do you get? They’ll go quick.
  • How can YOU terminate the contract? Under what circumstances? I’ve seen tech publishing contracts without termination clauses.
  • How can THEY terminate the contract?

    You might see other things. NSP has a nice “artistic control” section where they enumerate the various decisions that they’ll consult me on. They won’t guarantee to follow my desires, which is why my books don’t come with a glossy cover featuring an extreme close-up of my smiling face, but being asked gives me warm fuzzies. While NSP takes my input seriously, it won’t help me get my way against Ninth-Grade Diploma Editor.

    Lots of details in publishing contracts can bite you. Some of these seem harmless at first glance. My favorite example is the “right of first refusal,” where the publisher says they get first dibs on your next book, under the same contract terms. This seems like it’s to your advantage, but it’s not. The proper form for the publisher to express interest in your next book is by saying “Hey, what are you writing next? We’d really like a look.” If your first book is a smash hit at Wal-Mart, you want freedom to negotiate your next contract. If your publisher totally screws up your first book, you want freedom to work with a different publisher next time. If the publisher treats you well, follows their own terms, and produces a good book, you will want to stick with them — they don’t need this clause. There are really good reasons why I’ve stuck with NSP for over a decade, despite being repeatedly courted by editors for other publishers.

    Publishers have all kinds of tricks. They’ve been in the business longer than you. They have better lawyers. Don’t fear them. Do respect the crap out of them.

    If you really want to get into how contracts can abuse you, check out genre writer resources like Writer Beware. And you should really read Kris Rusch’s Business Rusch blog every Thursday. They’re for fiction, but Rusch has been a writer long enough to have suffered every abuse and indignity a publisher or agent can perpetrate. Learn from her mistakes, as you don’t have time to make them all yourself.

    Now that you have your marked-up contract, talk to someone about it — not your buddy, and not an experienced author. Hire a lawyer, preferably one with publishing experience. A couple hours of a lawyer’s time to explain the contract to you might save you years of grief. And yes, I mean years.

    Most publishing contracts include at least one objectionable clause. If a publishing contract includes no objectionable clauses, you do not understand the contract. Group the problems into “things you’d like changed” and “things that I will not accept.” This is where that lawyer comes in really handy, especially a lawyer experienced in publishing.

    Talk with the publisher about the problem terms. Some terms cannot be changed — the publisher pays all their royalties at the same time, so you’ll get paid quarterly or twice a year or once a leap decade along with every other author. Some terms can change. Ask. See what you can get.

    If one of your deal-breakers can’t change?

    Walk away. That’s what a deal-breaker means.

    Or accept what follows.

  • Some “Absolute OpenBSD 2/e” dates

    No Starch intends to send AO2e to the printer on 22 March 2013. This would give a “bound book date” of approximately 12 April. Books would be in their hands roughly 19 April. They’re really good about shipping books to purchasers as soon as possible.

    Note that DNSSec Mastery should be available in ebook form about then. Not only do I have two books coming in 2013, I have two books coming in April 2013.

    All dates are subject to change based on the whim of the printer, phase of the moon, gasoline shortages, insurrections and iniquity and incivility, or any other reason whatsoever.

    Any Firefox add-on people out there?

    I’ve had really good luck asking random people to do work for me, so I’m going to try it again.

    RFC6698 defines the DANE protocol for attaching information to DNSSEC-secured DNS. Notably, you can validate SSL certificates via DNS. This is a game-changer. The key here is the TLSA DNS record.

    Web browsers don’t support this yet, but there is the Extended DNSSEC Validator Firefox add-on at os3sec.com, with source at github.

    If you have the newest version of the add-on installed, sites like https://www.dnssec.michaelwlucas.com/ show up as secure. There is no “invalid certificate” warning. That’s because I’ve published a TLSA record for this zone, telling the browser that the certificate with fingerprint such-and-such on this port on this host is trustworthy. (Install the plugin from the github source, not from the xpi on the site.)

    The interesting thing about this add-on is that it uses libunbound to perform DNSSEC validation at the client. Your local DNS servers don’t need to support DNSSEC. All you need to hack on this plugin is a desktop.

    But the add-on doesn’t support BSD — it’s Linux, MS, and Mac only. The add-on authors don’t have time for BSD support, but gave me a couple hints on how to implement it. The plugin can’t find libunbound on BSD.

    That seems like it would be easy to do. I’m capable of building the add-on from source, but I’ve never programmed any add-ons before. The source code looks like it’s easy to hack, but my efforts all segfaulted Firefox. Obviously, I need more expertise.

    So, if you know anything about Firefox add-ons, or have ever wanted to hack on them, this is your chance.

    DANE and TLSA are the killer applications for DNSSEC. The ability to validate cryptographic certificates via DNS is a game changer. (Cliche, but true.) You can have separate certificates for separate ports on a host. With DANE, there’s no longer any need for a self-signed certificate to be a disadvantage.

    Absolute OpenBSD blurbs

    One of the tasks on an author’s to-do list is gathering blurbs for the new book. A blurb is blatant promotion from a name a reader might recognize. Preferably a name that has some bearing on the topic of the book. You frequently see this in fiction, where the first couple of pages are other people saying “this book is fantastic! It cured my leprous bulemia!” Most often it’s multiple authors each saying nice things about the others’ books.

    “Nice,” I think. “They’re doing each other favors. It’s blatant backscratching. When I’m successful, I swear I will never do that.”

    For the first time, the fine folks at No Starch Press asked me to get blurbs for the new book. Apparently I have reached the point where I merit that. It’s not bad enough that going around asking people to praise me is like begging for approval. No, I’m a computer dork. Telling others about my accomplishments doesn’t come naturally, and doesn’t work well when I try. Apparently this is common.

    (For the record, I don’t particularly like bacon. Pig, yes, but bacon, not so much. I’m aware this is heresy on the Internet. Deal.)

    So I have my mission: get blurbs. I think about who I know, who might be interested in the book. With growing horror, I realize: most of them are writers. All of them are friends on some scale, somewhere on the spectrum from “call up when you’re in town and we’ll get gelato” to “I heard you need to borrow a kidney, my back is already shaved.”

    I guess I’m going back on my younger and dumber self’s sworn word. Dammit.

    At least they all wanted to see the book before they said nice things about it. That’s mild balm to my conscience.

    So, I’ve gotten a couple of them back and felt like sharing them. Actually, no, I misspeak. I don’t feel like sharing them. But if something embarrassing is going to happen, it’s best to take control and get it over with. So, in that spirit:

    From George Rosamond, a founding member of NYC*BSD User Group and noted detester of string beans and beets:

    “The space for BSD books is small, indeed.

    All the BSDs provide excellent documentation, from their handbooks and FAQs to their native manual pages. Got a question? There’s a good chance you will find the answer in the official documentation.

    Michael W. Lucas manages to squeeze into that ‘other’ space. He engages the reader. He answers those specific questions and addresses those methods that a manual page or online documentation can’t approach.

    He is the modest sysadmin sitting next to you in front of an OpenBSD box, narrating as you dive into an operating system that does things minimally without fuss. He’s not perched up high on a pedestal, preaching or obfuscating his words. He is a layperson’s tutor, who’s working through the same issues the average sysadmin does.

    So buy this book. Buy it because for the amateur or intermediate OpenBSD end-user, you will flatten any learning curves real or perceived. You will find the elegant simplicity of OpenBSD, while sometimes discouraging for the uninitiated user, is a fruitful path for building systems that just run.”

    And from Chris Sanders, author of the essential Practical Packet Analysis and better human being than I am:

    “It’s rare to find a book that can cover so much technical content while still being engaging and enjoyable to read. Absolute OpenBSD, 2nd edition, is one of those books that achieves that with flare. Whether you are an experienced OpenBSD user seeking a functional desk reference, or a new OpenBSD user seeking to gain the carnal knowledge necessary to become an expert, then Absolute OpenBSD is the book you have to have.”

    Somehow, I don’t think NSP will let me use those blurber descriptions, though. Pity.

    [UPDATE] Oh, yes, the plug. Forgot the plug. Preorder Absolute OpenBSD, 2nd Edition. Get ebook and print together for one low price. Use coupon code ILUVMICHAEL for a 30% discount and give me a couple extra bucks. Or, if you’re in a place where shipping from the US is prohibitive, get it locally. Whatever. In either case, thank you.

    DNSSEC Tech Reviewers Wanted

    Last night, I finished the first draft of DNSSEC Mastery. If you’re one of my fans who wants to see the existing work, a pre-pub version is now available on LeanPub.

    Now I’m looking for people familiar with DNSSEC on BIND to read the book and tell me where I’ve screwed up.

    This book is for an established DNS administrator who wants to deploy DNSSEC. I assume you know what named.conf is, why you don’t put PTR records in a forward zone, and so on. The goal is not to get 100% of the people 100% there, but to get 90% of the people 100% there and ground the other 10% so that they can identify their own rough edges. (The idea is roughly similar to my SSH Mastery or Cisco Routers for the Desperate.)

    The contents are:

      1. Introducing DNSSEC
      2. Cryptography and DNSSEC
      3. How DNSSEC changes DNS
      4. DNSSEC Resolver
      5. dig and DNSSEC
      6. Securing Zone Transfers
      7. KSKs and ZSKs
      8. Signing Zones
      9. Debugging
      10. Key Rotation
      11. Delegations and Islands of Trust
      12. DNSSEC for Data Distribution (needs better title, it’s SSHFP and TLSA)

    Many of these chapters are short. Chapter 10 is not. The writing is rough, especially near the end.

    So, if you know DNSSEC, and you’re interested in spreading the DNSSEC gospel, and you have enough time to read something about half the length of a short paperback novel, contact me via email at mwlucas at my domain.

    I’d need any comments by 15 March. I plan to revise that week and get the book into copyedit, so it can be out for BSDCan. Barring any really appalling revelations from the reviewers, that is. I’d rather the book be late than wrong.

    my OpenSSH AuthorizedKeysCommand script

    The bleeding-edge OpenSSH supports using an AuthorizedKeysCommand statement in sshd_config to get the authorized_keys file for a user. This lets you store your authorized_keys files in LDAP, but avoids linking OpenSSH against OpenLDAP. (You could actually use any data store for your back end, but LDAP is both the most popular and what I have.)

    Your AuthorizedKeysCommands script should take one argument, and return a series of authorized keys, one per line. CentOS has a script, which I previously mentioned, and one of my readers was kind enough to put together an OpenBSD port for it.

    But there’s some problems with the CentOS approach, from a cross-platform perspective. While it’s fine on CentOS, porting and installing it on other platforms is more difficult than it needs to be. I’d really like something that has very few dependencies, is easy to install, and is easily portable across platforms.

    When setting up a couple of Ubuntu boxes I came across an Ubuntu AuthorizedKeysCommand script. His approach is much simpler than the CentOS approach, but his script didn’t work for me out of the box, and it wouldn’t work on other operating systems without modification. But it inspired me to write my own script, one that works across all of my operating systems, using only the tools I already have on all of my servers. My results follow. But before I offer my script, I feel obliged to warn you.

    The bad news is, I am not a programmer. I have been told by multiple independent parties that my code makes the Baby Jesus cry.

    The really bad with this is that you need an ldapsearch command that returns your public keys, and this command is hard-coded with this script. The ideal script would read the system ldap config, but you’d probably have to hard-code a path to ldap.conf anyway.

    The appalling news is, I wrote it in Perl. Why? Well, the evidence indicates that I am insane. But every server in my environment runs Perl, and it’s been ten years since I used enough sed/awk to make this work. A proper authentication credentials script would not use Perl.

    I’m not suggesting that you take my code. I’m hoping to motivate one of my programmer readers, whose code only makes the Baby Jesus grimace a little, to do better. I mean, I’ve set a pretty low bar here.


    #!/usr/bin/perl
    #takes one argument, the username to get the keys for
    die unless $ARGV[0];

    open (LDAP, "/usr/bin/ldapsearch -L -xZb\"dc=michaelwlucas,dc=com\" '(&(objectClass=posixAccount)(uid=$ARGV[0]))' sshPublicKey |") || die "ldapsearch failed $!\n";

    while (<LDAP>) {
    next if /^#|^version|^dn\:|^\s*$/;
    s/\n//;
    s/\://g;
    s/sshPublicKey/\n/;

    s/^ //;
    print;
    }
    print "\n";

    One catch with this is that you’re processing the raw output of ldapsearch. An acceptable ldapsearch will return keys that look something like this:


    ...
    sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAw9zmtbk8bT+7OVpVvzuYYQqRhF8j
    ...blah, blah, blah...
    ilXzBw== rsa-key-20110114

    Initially, my LDAP searches returned some keys that looked like this:
    ...
    sshPublicKey:: c3NoLWRzcyANCkFBQUFCM056YUMxa2MzTUFBQUNCQVBhZmNhemdmUHI1T29DdFp
    ...blah, blah, blah...
    y5sb2NhbA==

    This key doesn’t start with ssh-rsa or ssh-dss, and it doesn’t even look like a SSH key. But if you look at the key in a graphical tool like phpLDAPAdmin, it has the leading ssh-rsa. In my case, the key had an extra carriage return at the end of the key, which meant that ldapsearch had to base64 encode it. Get rid of extra whitespace. The LPK patch doesn’t notice that space, but a simple external script does.

    Of course, if someone wanted to write an AuthorizedKeysCommand that was portable, handled that encoding, and didn’t suck as bad as mine, it wouldn’t hurt my feelings at all. Really.

    Book status, 9 Feb 2013, and the Missing Contest Winner

    Fast and furious progress these days:

    Absolute OpenBSD: Peter has finished the tech edit on the entire manuscript. Chapters 1-18 are copyedited and returned to NSP. Chapters 1-17 are laid out and look somewhat like an actual book. (Seeing a book in laid out forces me to view it with new eyes. It makes me want to tear up the whole thing and start over. I know I can write better than that. But I think that both the publisher and you lot would lynch me if I delayed the book until 2016 for a proper rewrite.) I’m sending prepub PDFs out to various OpenBSD celebrities in the hope of getting blurbs for the front of the book. Best quote so far, from someone who will remain anonymous: ” It’s unfortunate that the strength of BSD man pages undercut his sales so much.”

    DNSSec Mastery: I’ve made the second version available on LeanPub. It now contains everything you need to deploy DNSSec, provided nothing goes wrong and you don’t have to rotate keys. Plus, the introduction now gives you a reason to read the book, which is a bonus. (That last sentence originally read “The introduction no longer blows chunks.” And people say I can’t be tactful.)

    To Ludovic ‘Ludy’ Simpson: You won the haiku contest. But you didn’t leave me contact info. Please get me your shipping address. Thank you.

    “DNSSec Mastery” in-progress version available

    By popular demand (mainly on Twitter) I’ve made the work-in-progress version of DNSSec Mastery available on LeanPub.

    This is an experiment. If it works well, I’ll do it again. If not… I won’t.

    Why would you be interested?

      It’s cheap. I intend to sell the finished ebook for $9.99. The work-in-progress version is $7.99. I will continue to update the manuscript on LeanPub until it’s finished.
      Once the manuscript is complete, I’ll raise the LeanPub price to $9.99 to match other vendors.
      If you want to provide feedback on an incomplete book, this is your chance.

    Why would I do this?

      I can usually get subject matter experts to review a book. I have a real problem with getting non-experts to review a book before publication, however. Non-expert feedback is important — those are the people most likely to catch when I explain something poorly, as opposed to the experts who already understand what I’m writing about. I can only handle so much feedback, so I wind up picking a select group of volunteers based on their apparent enthusiasm for the book. Measuring by the results, either I am a poor judge of enthusiasm or enthusiasm is the wrong measurement. This method might work better.
      I get paid earlier. That’s always nice.
      I want feedback from people trying to use it.

      Do I care what you do? No.

      In the long run, sales made via Amazon, B&N, Smashwords, or other ebookstores are better for my career. I’m expecting that only my most hardcore fans will buy the book early. If you’re a hardcore fan, but want to wait for the release of an actual book to buy it, I don’t blame you. I wouldn’t buy an incomplete book.

      But it’s here if you want it.