Tag: Amazon

Fauxpen Source

Back in December, Bryan Cantrill wrote a pretty good article titled Open source confronts its midlife crisis. He discusses a particular problem that's started cropping up over the past year or so: companies deciding that free software/open source licenses are unfair, and modifying them so that they're no longer free/open-source.

It's the same old problem we've been seeing since the start of the Free Software movement: how can you make a profit giving your software away for free? How can you stay in business if somebody else can just take your software and resell it without giving you a cut?

There's a growing trend toward answering that question with "Change the license so they can't do that."

One particular example is the inaccurately-named Commons Clause, which is a clause you can attach to some other license; here it is in its entirety:

"Commons Clause" License Condition v1.0

The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition.

Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.

For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.

The Free Software Foundation has added the Commons Clause to its license list under "Nonfree Software Licenses". In its update notes, the FSF explained the move:

We added the Commons Clause to our list of nonfree licenses. Not a stand-alone license in and of itself, it is meant to be added to an existing free license to prevent using the work commercially, rendering the work nonfree. It's particularly nasty given that the name, and the fact that it is attached to pre-existing free licenses, may make it seem as if the work is still free software.

Cantrill called out other nonfree licenses too, including Confluent's Community License. Confluent's Jay Kreps objected:

We actually aren’t trying to "co-opt" the community or open source terminology. We tried really hard both in the license and in the blog post to be honest and upfront. Whether you like Confluent's license or not, you have to agree it is exceptionally permissive and the software has a pretty great community of users. How do you describe a license that lets you run, modify, fork, and redistribute the code and do virtually anything other than offer a competing SaaS offering of the product?

I describe it as "Not open source."

"Open source" is not a generic term. It doesn't just mean that you can look at a program's source code. It's a term of art, subject to the Open Source Definition. And the definition includes section 6:

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

I'm not a lawyer, but I'm pretty sure "a competing SaaS offering" counts as a field of endeavor.

Bruce Perens, who wrote the OSD, explains more in a blog post titled When Licenses Discriminate. It's a relatively short post, so I'm going to quote it in its entirety:

A long time ago, well-meaning people at the University of California, Berkeley created a license for their SPICE electronic simulation software that prohibited use by the Police of South Africa. This was, of course, during Apartheid.

Years later, Apartheid ended. The Police of South Africa now included Blacks and Whites with the same duties and powers. And they were still prohibited from using Berkeley SPICE. Getting the University of California to change the license, so that the software could be carried in Debian as "Free Software", was impossible at the time.

I took this example (among others) and wrote into the Open Source Definition (then the Debian Free Software Guidelines) that licenses could not discriminate against persons or groups, or against fields of endeavor.

This implements a major principle of Free Software. Freedom means Freedom for Everyone, not Freedom For People I Approve Of. Even when those folks abuse the freedom of others.

Someone recently created a license that discriminates against companies that have contracts with the U.S. Immigration and Customs Enforcement (ICE), a division of the Department of Homeland Security. Ironically, this is called "Moral Programming" or "Moral Licensing". I have to object to it on moral grounds.

I don't approve of the recent conduct of ICE under the direction of Donald Trump and his gang. Far, far from it. I am happy to say so, to participate in protests, and most importantly, I will not vote Republican in upcoming elections.

But if you insist on denying them the right to run your software in your license, please be careful not to call it Open Source or Free Software. Because your license will not comply with the Open Source Definition or the Four Freedoms of the Free Software Foundation. Which protect Freedom for everyone.

There's another license that's been getting some attention lately: MongoDB's Server Side Public License. It's based on the GNU Affero General Public License (which in turn is based on the GNU General Public License), but it makes a significant change. Here's Section 13 of the Affero GPL:

13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

Here's the modified version in the SSPL:

13. Offering the Program as a Service.

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

"Service Source Code" means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

That's some pretty dry legalese, but if you've made it this far, I suppose you're interested in reading about technical differences in free software licenses. So here goes:

If you take a program that's licensed under the Affero GPL, modify it, and make that modified version available to run over a network, you have to license your modified version under the Affero GPL.

Whereas under the SSPL, if you use MongoDB as part of a service package you offer to third parties, you have to release the entire package under the SSPL.

While MongoDB is couching this in the language of the GPL and copyleft, its goal seems more inline with the Commons Clause. It doesn't actually expect anyone to use MongoDB as part of a package and then release the entire software stack under the SSPL; it expects the terms of the SSPL to be so onerous that companies just pay MongoDB to license the software without the SSPL.

What's the point of all this?

It gets back to that earlier question: how do you make money on software you give away for free?

One of the traditional answers to that question has been that you charge for support. That was the idea behind MongoDB: they'd give the software away for free, but charge for support.

That may have been a viable business strategy a decade ago, but the market has changed. More and more companies are choosing not to run their own servers on-site, but instead to use Amazon Web Services. And that disrupts the traditional "pay for service" model -- because now companies are using MongoDB, and they're paying for service, but they're not paying MongoDB for service, they're paying Amazon for it.

Clearly the bean-counters at MongoDB saw this as a problem, and so they wrote a license that they hoped would force Amazon to pay them to continue using their software.

It didn't work. Amazon responded by creating a competing database format called DocumentDB. As soon as Amazon announced the project, MongoDB's stock dropped nearly 15 points. Whoops.

Meanwhile, neither the Free Software Foundation nor the Open Source Initiative has reached an official verdict yet on whether the SSPL is a free/open-source license, but it's under review, and Bruce Perens has his doubts.

First of all, he notes that it almost certainly violates the FSF's copyright on the AGPL; just because it's a license that allows redistribution of modified versions of software doesn't mean that it allows redistribution of modified versions of the text of the license.

The issue of the license text being infringing of FSF's copyright needs to be addressed. I doubt FSF is going to give permission for this use of their text. There is a possible 17 USC 102(b) argument, but most sources (Nimmer, Adams) disagree, and I don't know of any case law. This might require a full rewrite, and IMO OSI would face a risk of being a contributory infringer simply by hosting a copy of the current text on their site. The legal ambiguity of that might be sufficient reason for rejection.

And in the same post, he suggests it might violate sections 6 and 9 of the OSD. I've already quoted #6; here's the text of #9:

9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

And here's what Perens has to say about the SSPL:

I am most concerned with the second paragraph of section 13, and its conflict with OSD #9 and #6. The definition of how those pieces are coupled needs to be tighter. Management software, backup software, etc. may be used as part of the offering of a service, but they don't create a derivative work, nor are they combined into the same program. So, we get a restriction on works that are simply aggregated together (#9) or a restriction on use of the program if the data is backed up using a non-Open-Source backup program (#6).

In a later post, and with deep apologies, Perens backs off the Section 9 claims and states that the SSPL violates the spirit of Section 9, but not the letter.

The OSD terms were not written for software-as-a-service. OSD #9 very clearly states

The license must not place restrictions on other software that is *distributed* along with the licensed software. For example, the license must not insist that all other programs *distributed on the same medium* must be open-source software.

Since software-as-a-service software is not distributed, OSD #9 doesn't apply. Sorry. The document was written for another time and I could not predict today's conditions.

Regardless, even if it doesn't violate #9, it would nonetheless appear to violate #6. At any rate, Red Hat and its community version, Fedora, think so; they've rejected the SSPL and will be removing MongoDB from their software repositories. The Debian maintainers don't even think a strict analysis of the Debian Free Software Guidelines is necessary; it clearly violates the spirit of the DFSG, and that's good enough for exclusion from Debian.

Here's the thing: a change in license can kill a project. XFree86 was a much more essential package than MongoDB, and its owners made a much more minor change to its license. But that was enough to completely destroy the project. A previous version, with the old license, was forked as X.Org, and within a matter of months every Linux and BSD release had switched.

MongoDB is well along that path. The company has since introduced SSPL v2 in the hopes that it will prove more acceptable than v1, but MongoDB itself is still published under v1.

Maybe v2 will prove more acceptable. Maybe MongoDB won't end up like XFree86 and it'll end up like, say, KDE instead -- a project which initially used a nonfree license but then switched to a free license and continues to be widely used. Those are MongoDB's options: make your license acceptable to the free/open-source community, or fade into irrelevance as everybody switches to a fork. Time will tell which path MongoDB ultimately takes -- and what impact that has on the rest of this new crop of projects trying to pass off proprietary licenses as free ones.

How I Created and Self-Published My eBook

I wrote Old Tom and the Old Tome in Scrivener. I converted it to an EPUB with Sigil. I tested it using Calibre, FBReader, Nook, Kobo, and Google Play Books. Then I published it on Smashwords and Kindle Direct.

Why a short story?

This one is probably obvious, but just in case it isn't: I started with a short story because when you want to learn a new skill, you want to start small. I didn't want to write something novel-length and then run into a bunch of problems.

A short story's the perfect length to start with. Old Tom and the Old Tome clocks in around 3,000 words, split up into 4 separate sections (cover, copyright, story, About the Author). It has a great structure for learning the ropes.

Of course, you don't have to go the fiction route. In fact, it occurs to me that this blog post would actually convert quite nicely into a short eBook. Hm, food for thought.


I checked out Scrivener because Charles Stross swears by it. It's basically an IDE for writing books; it's quite simply the most advanced and mature piece of software there is for the purpose.

There's a Linux version, but it's abandonware. For a GNU/Linux user such as myself, this is something of a double-edged sword: on the plus side, I get Scrivener for free, where Mac and Windows users have to pay $40 for it; on the minus side, if a system upgrade ever causes it to stop working, I'm SOL. If Scrivener stops working on my system, there's not going to be a fix, I'll be locked into a platform I can no longer use. I could try and see if the Windows version will run under WINE, but there's no guarantee of that.

The good news is that Scrivener saves its files in standard formats, so if it ever stops working I'll still be able to access my content in other programs. The bad news is that it saves its individual files with names like 3.rtf and 3_synopsis.txt.

So Scrivener's pretty great, and I'll probably stick with it for a little while even though there are no more updates on the horizon for my OS -- but there's a definite downside to using the Linux version. (And if they decided the Linux version wasn't going to bring in enough profit to justify maintaining it, what happens if they decide the same thing for the Windows version someday, maybe leave it as a Mac-only product?)

Getting Started

Scrivener's got a great tutorial to run through its functionality; start there.

When you're done with the tutorial and ready to get to work on your book, I recommend using the Novel template, even if you're not writing a novel, because it automatically includes Front Matter and Back Matter sections; the Short Story template does not.

Scrivener's got your standard MS-word-style tools for formatting your work. I didn't use them. Since I was targeting a digital-only release and no print version, I wrote my story in Markdown, which converts trivially to HTML but isn't as verbose as HTML.

Output Formats

Since I went the Markdown route, I found that the best option for output at compile time was Plain Text (.txt). The most vexing thing I found about the output was the limited options under the "Text Separator" option -- the thing that goes between different sections. What I wanted was a linebreak, followed by ***, followed by another linebreak. Scrivener doesn't have any option for that -- your options are Single Return, Empty Line, Page Break, and Custom. Under Custom you can put ***, but there doesn't seem to be any way to put a linebreak on either side of it. So I found the best option was to just do that, and then manually edit the text file it put out and add a linebreak on either side of each one.

If you plan on making an EPUB file, you'll probably want to keep all the "smart quotes" and other symbols that Scrivener adds to your text file. However, if you want to distribute the Markdown file in plain text and want it to be readable in Chrome, you'll need to remove all the pretty-print characters, because Chrome won't render them correctly in a plain-text file (though it'll do it just fine in a properly-formatted HTML file). You'll also want to use the .txt extension rather than .md or .markdown if you want the file to display in Firefox (instead of prompting a download).

You've got different options for converting from Markdown to HTML. Pandoc is a versatile command-line tool for converting between all sorts of different formats, but I don't like the way it converts from Markdown to HTML; not enough linebreaks or tabs for my tastes. There are probably command-line flags to customize those output settings, but I didn't find them when I glanced through the man page.

I thought Scrivener's Multimarkdown to Web Page (.html) compile option worked pretty well, although the version I used (1.9 for Linux) has a bug that none of the checkboxes to remove fancy characters work correctly: you're getting smartquotes whether you want them or not. You also don't want to use *** as your section separator, because Scrivener reads it as an italicized asterisk (an asterisk in-between two other asterisks, get it?) instead of an HR. Similarly, it reads --- as an indicator that the previous line of text is an h2.

So your best bet for a section break is something like



<div class="break">*</div>

(Actually, you don't want to use HR's at all in an EPUB, for reasons I'll get to later, but if you want to distribute an HTML version of your book, it's fine to use them in that version.)


Sigil is an excellent, very straightforward tool for editing the EPUB format. I recommend you grab the Sigil User Guide, go through the Tutorial section, and do what it tells you -- even the stuff that generates seemingly ugly code. For example, if you use Sigil's Add Cover tool, you wind up with code that looks like this:

<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 900 1350" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
  <image width="900" height="1350" xlink:href="../Images/cover.jpg"/>

If you're like me, looking at that makes you wince. And your instinct will be to replace it with something simple, like this:

<img src="../Images/cover.jpg" alt="Cover" />

But don't do that. Removing the <svg> tag, or even removing those ugly-ass inline styling attributes, will prevent the cover from displaying correctly as a thumbnail in readers.

(If there is a way to clean up that ugly <svg> tag and still have the thumbnail display correctly, please let me know; I'd love to hear it.)

Now, Sigil is for the EPUB2 format. It doesn't support any of the newfangled fancy features of EPUB3, and neither do most readers at this point. You're going to want to keep your styles simple. In fact, here's the entire CSS file from Old Tom and the Old Tome:

img {
  max-width: 100%;

h1 {
  text-align: left;
  text-indent: 0;
  font-size: 200%;

.noindent {
  text-indent: 0;

.break {
  margin: 1em 0;
  text-align: center;

Oh, and that last class, .break? That's there because some readers ignore <hr/> tags. FBReader on Android, for example, will not display an HR. No matter how I tried formatting it, it wouldn't render. Not as a thin line, not even as a margin. If you use an <hr/> tag in your EPUB file, FBReader will act as if it isn't there.

So I wound up cribbing a style I saw in Tor's EPUB version of The Bloodline Feud by Charles Stross:

<div class="break">*</div>

where, as noted in the above CSS, the .break class centers the text and puts a 1em margin above and below it.

(Some readers won't respect even that sort of simple styling, either; Okular parses the margin above and below the * but ignores the text-align: center style. Keep this in mind when you're building an EPUB file: keep the styles simple, and remember that some readers will straight-up ignore them anyway.)

(Also: this should go without saying, but while it's okay to look through other eBooks for formatting suggestions and lifting a few lines' worth of obvious styling is no problem, you don't want to go and do anything foolish like grab an entire CSS file, unless it's from a source that explicitly allows it. Even then, it might not be a good idea; formatting that works in somebody else's book may not be a good idea in yours.)


Once my EPUB was done, I tested it in a number of different readers for a number of different platforms at a number of different resolutions. There are a lot of e-readers out there, and their standards compliance is inconsistent -- much moreso than the browser market, where there are essentially only three families of rendering engines.

If you're used to using an exhaustive, precise set of CSS resets for cross-browser consistency, you probably expect to use something similar for e-readers. Put that thought out of your head; you're not going to find them. The best you're going to get are a few loose guidelines.

Consistency across different e-readers just isn't attainable in the way that it is across different web browsers. Don't make that a goal, and don't expect it to happen. You're not looking for your eBook to display perfectly in every reader; you're just looking for it to be good enough in a few of the most-used readers.

For example, I found that the margins the Nook reader put around my story were fine on a tablet, but I thought they were too much on a phone. If I'd wanted, I could have futzed around with media queries and seen if that was possible to fix -- but I decided no, it was Good Enough; it wasn't worth the effort of trying to fix it just for that one use-case.


Smashwords has a useful FAQ on self-publishing, and also provides a free EPUB download called the Smashwords Style Guide.

If you already know HTML, here's what I can tell you about the Smashwords Style Guide: read the FAQ at the beginning, then skip to Step 21: Front Matter. Because it turns out that Steps 1-20 are about how to try and make Microsoft Word output clean HTML and CSS. If you already know how to write HTML and CSS yourself, there is of course absolutely no fucking reason why you would ever want to use Word to write your HTML and CSS for you.

It's probably a good idea to read the rest of the guide from Step 21 through the end, but most of it's pretty simple stuff. To tell the truth, there are exactly two modifications I made to the EPUB for the Smashwords edition: I added the phrase "Smashwords edition" to the copyright page, and I put ### at the end of the story (before the back matter). That's it.

For all the time the guide spends telling you how easy it is to fuck up and submit a file that will fail validation, I experienced none of that. My EPUB validated immediately, and it was approved for Smashwords Premium the next day (though Smashwords says it usually takes 1-2 weeks; the quick turnaround may have been a function of how short my short story is).


Most of the forms you fill out on the Smashwords Publish page are well-documented and/or self-explanatory. The Long Description and Short Description fields are exceptions; it's probably not entirely clear, at a glance, where your listing will show the short description and where it will show the short one. So here's how they work:

On Smashwords, your book's listing shows the short description, followed by a link that says "More". When you click "More", the long description appears underneath the short description.

  • Smashwords default
  • Smashwords expanded

Kobo and iBooks don't appear to use the short description at all. Your book's listing will show the first few lines of your long description, followed by an arrow (on Kobo) or a "More..." link (on iBooks), which you can click to expand to show the entire description.

  • Kobo default
  • Kobo expanded
  • iBooks default
  • iBooks expanded
Aside: Why the fuck does it do this?
Look at all that whitespace. What's the point of hiding the text?

Inktera shows the long description, followed by an HR, followed by the short description.



And Scribd just shows the long description.



Lastly, Blio doesn't show either description of my book. Clearly this is a problem and I should probably talk to tech support about it.

As you might expect, the various different ways the different sites use the two descriptions create a bit of a conundrum: how can you write a short description that is the primary description on one site and a long description that is the primary description on four other sites, and write the two descriptions so that they don't look pointless and redundant when you put them side-by-side?

I haven't come up with a good solution for this in the case of Old Tom yet.


It turns out the Amazon conversion is really easy. I just set up an account at kdp.amazon.com, filled out the forms, uploaded the cover and the EPUB file, and Amazon's automatic conversion software switched it over to Kindle format with no trouble at all. Amazon's even got a really nice online reader that lets you check how your file will look in the Kindle Reader on various devices (Kindle Fire HD, iPhone, iPad, Android phone, Android tablet, etc.).

I only hit one speed bump when I submitted to Amazon: after a few hours, I got an E-Mail back saying that the book was freely available online (because of course it is; I've posted it in multiple places, including this site). Amazon required me to go back through and reaffirm that I am the copyright holder of the book -- which meant just going through the exact same forms I'd already filled out and clicking the Submit button again. It was a little bit annoying, but not time-consuming and mostly painless, and the book appeared for download on Amazon shortly after.

And that's it.

The hardest part of self-publishing an eBook was finding the time, figuring out what resources to use, and learning the EPUB format. And now that I know what resources to use and understand the EPUB format, it doesn't take nearly as much time. For my next book, I'll be able to spend a lot more time writing and a lot less time formatting. Hopefully this blog post has helped you so that you can do the same.

Marketplace on NPR

So, since May I've been working a job that goes from 10 AM to 6 PM.

I like it. It gives me time to walk the dog in the morning, and getting off at 6 means I miss both the worst heat and the worst traffic of the day.

The biggest problem with getting off at 6 is that Marketplace is on NPR, and so that's what I end up listening to on my way home, because it's that or play Preset Lottery and try to find a song I like amid all the obnoxious pop and worse commercials on all the other stations.

I've been trying, for months, to figure out why I don't like Marketplace. Is it my innate disdain for the finance industry? The constant handholding on basic economics and technology?

No. I have come to realize that it's because the questions Kai Ryssdal asks are actually stupid.

Here's a bit from yesterday's interview with Amazon Studios' Roy Price:

Ryssdal: At this point, you might reasonably stop and ask, How did an online retailer end up making television shows, and, y'know, why? Roy Price is the guy with the answers; he runs Amazon Studios. Roy, it's good to have you on.

Price: Thank you, Kai; it's great to be here.

Ryssdal: So when you go to a dinner party, or your kid's soccer game, or you're hangin' out at the beach, and people say, "What do you do?" what do you tell them?

Price: I run Amazon Studios, and we develop TV shows for amazon.com. That's usually what I tell them, unless I'm in a kidding mood.

Emphasis added, because seriously, what the fuck is that? The dude says what Price's job is, and then asks him what he tells people his job is. This is, like, Tim Meadows as Lionel Osbourne-caliber interviewing.

And then he just keeps rambling on about how crazy it is that Amazon is making original TV shows.

This is not 1999. He is not asking why bookseller Amazon has started selling CD's, VHS tapes, and DVD's.

This is not 2003. He is not asking why media seller Amazon has started selling clothing, and advertising it with baffling recommendations beginning with "People who wear clothes also shop for:"

This is not 2007. He is not asking why physical media/clothing seller Amazon has started selling consumer electronics, household goods, and MP3's.

This is not 2011. He is not asking why physical goods/ebook/MP3 seller Amazon has started its own Android app store and video streaming service.

This is goddamn yesterday, and he is seemingly baffled that an online retailer that has been constantly branching out into new markets for the past 15 years has branched out into a new market.

Jesus Christ. I'd rather listen to Car Talk.

Cheap DVD's: Earthworm Jim

I was perusing Amazon the other day and, under my recommendations, I noticed that it listed Earthworm Jim: The Complete Series (affiliate link). As EWJ is easily one of my two favorite 1990's animated video game adaptations to feature Kath Soucie as a redheaded princess and Jim Cummings as the bad guy, I went ahead and ordered it.

Initial Impressions

The Good:

  • Good animation
  • Great cast
  • Still funny
  • All 23 episodes for only eleven bucks
  • Way better quality than that torrent you grabbed a few years ago that somebody made from old VHS tapes

The Bad:

  • Totally barebones; no special features or even scene selection.
  • If you buy this, part of that money probably goes to Doug TenNapel.