Tuesday, June 19, 2012

"Open Access eBooks" eBook is on GitHub


When I try to explain to book industry people why ebooks can and should be free, I often get a look that says "What planet are you from?" In contrast, many of my software developer friends take it as dogma that ebooks should not only be free, but also "Free". And so I seem to spend a lot of time explaining one point of view to the other.

What we're trying to do with unglue.it is to skip over the theory, and just show everyone that it works.

First, an explanation for the 99% of real people who haven't encountered the Free vs. free distinction. An ebook that's Free means more than just not having to pay for the ebook, it means that the ebook is not locked up in any way. You can do things with it without needing permission. Copy it, distribute it, convert it, print it, slice it and dice it. Extract it, analyze it, translate it compute it, archive it. In the software world, that's the essence of Free Open Source Software (FOSS). But the 99% just wants to read the book. So why should it bother with Free?

The book that is on the brink of having a successful ungluing campaign at Unglue.it, Oral Literature in Africa, has a Free license proposed for it, CC BY (Creative Commons Attribution). We can't be certain how much the Free license has been responsible for the success of the campaign (you HAVE pledged, haven't you?), but it certainly adds to the appeal. A successful conclusion to the campaign will do more than just let people read the book. It will allow scholars of African culture to add to the book, to use chapters as course material, to use large excerpts in their own work, to make corrections and translations. And the media handling capabilities of new ebook formats will allow the addition of audio to a work about material that deserves to be audible.

What frustrates me, though, is how difficult it is to actually do all the things that you would want to do with a not-locked-up ebook, even the things that don't require it to be Free. Something as simple as correcting a typo is hard for 99.9% of the public. It shouldn't be that way. There should be tools that make this easy. If I want to add my voice into Oral Literature in Africa, there should be an application that allows me to click and speak.

The software world has developed a wealth of tools that allow distributed teams of developers to work together on free software. Source control systems help to track and manage changes in software. We need the same sort of tools that work for books. Wikis do part of the job, but we need more.

So as a first step, I'm putting the short book I've written using this blog, Open Access eBooks, on GitHub, the service we use to track and manage the software behind Unglue.it. All the book's source code is there, mistakes and all. Its CC BY license allows you to take it, branch it, fix it, translate or modify it, redesign and recode it, whatever. You can send me a pull request if you want to merge your changes with my branch. Maybe you want to update the references or add a chapter. Maybe you want to embed metadata or improve accessibility. Maybe you want to fuse it with Moby Dick for some bizarre art project. Whatever. The future of books is all of ours to create.

Notes


  1. Other factors contributing to the imminent success of the Oral Literature in Africa Campaign have been its academic nature, its modest ungluing fee, and its inherent coolness. What, you haven't contributed yet?
  2. Among the Creative Commons Licenses usable at Unglue.it, CC BY and CC BY-SA are considered by Free Culture advocates to be "Free". The Public Domain Dedication (CC0) is not a license, but is another way to make a work "Free". The SA (Share Alike) restriction is a form of "copyleft" which requires derivative works to be similarly made available.
  3. Other CC licenses may add conditions including NC (Non-Commercial) and ND (No Derivatives).
  4. Wikipedia is a good example of a site that won't allow posting of NC or ND licensed content.
  5. The license used for an unglue.it campaign is specified by the rightsholder who may be constrained by  publishing contracts and byzantine international licensing regimes.
  6. I was disappointed by the lack of good tools to create ebooks. I did everything by hand and was surprised at the mess of shifting standards, conflicting ereader implementations and insular documentation.
  7. Whenever I encounter a roadblock in python or django, Google sends me to StackOverflow for the answer. With ebook production, I always end up at MobileRead, ThreePress or Liz Castro's blog. These are wonderful resources, but they're not StackOverflow.
  8. Despite my struggles with EPUB, Amazon's MOBI tools were painless. I felt so naughty!
  9. Because Git is line oriented, I put every sentence in the content file on its own line. Hope that makes sense!
  10. For an example of another ebook with source on GitHub, check out Structure and Interpretation of Computer Programs, Second Edition (SICP). It's not Free, though.
  11. If you want a really nice "free" dinner next Saturday in Anaheim California, make a $100 unglue.it pledge and ask me for an invite. Space is limited!


Enhanced by Zemanta

6 comments:

  1. did you mess with sigil? though they're _still_ working on epub3 (sometimes free means slow development by a few dudes with no financial incentive), it has pretty workable epub2 output.

    ReplyDelete
    Replies
    1. I plan to, but haven't had time to give it a try.

      Delete
  2. I think I know where you are going/coming from with this approach (one of my favourite quotes is - I think - from Minsky at MIT, who said 'was there ever a time when the books in the library didn't talk to each other?' - I may have the wording slightly wrong but that was the essence of it) and I agree that Free is Good. In some cases. Because there is a counter argument. Just because you can track changes doesn't make changes good - I am assuming you wouldn't subscribe to the idea that ANY book should be made available Free - novels by James Joyce or Henry James; poems by e e cummings; even the works of Enid Blyton were all carefully crafted to put the right words in the right place. Imagine a world where a quick search-and-replace renders the beginning of Herman Melville's great novel as "Call me Janet"! That is no brave new world that I want. So how are we to distinguish - easily - the mutable from the immutable? How can authors feel that their intellectual property is safe? Do we need to distinguish books and e-books from this new breed by way of terminology - what you are describing may not be a book but a (I feel the need of Joycean help, here) Chimeratext. I think we need a new lexicon of publishing if all who write or publish are to be happy with Free in this context.

    ReplyDelete
    Replies
    1. The Melville example proves the point. It IS Free. There's nothing to stop anyone from defacing Moby Dick for fun or profit, yet no horror has resulted. There's perhaps an increased need for validation and verification of authenticity, and that's an opportunity for publishers.

      At the same time, you'd not want a regime where it was forbidden to make a better translation of "the Whale". Even if the target language was Klingon. You might be horrified to hear it as a hip-hop lyric, but that's your problem and not something we need to words for.

      Delete
  3. Hmmm. I'm not sure that Melville DOES prove the point at all. Just because it hasn't happened yet! I think the problem we have is similar to that faced by Open Access Institutional Repositories: version control. What if, through a series of [your-world] events, the 'Call me Janet' version came to be viewed as the copy of record? And gradually the genuine Melville copy is lost to the world's culture. OK, not so likely with a known author, but what of a lesser-known writer whose first novel becomes subverted?
    Translations into Klingon or hip-hop are one thing - over-writing to change context, political or religious views, etc are quite another. Tracking changes is only an answer if every reader is aware that they need to check the track.

    ReplyDelete
    Replies
    1. I agree it's a potential problem (as I previously noted) , but the technical solutions are so easy, I don't think it will be an issue.

      Delete