wonko.com

Last week, Google banned my PHP port of JSMin from Google Code due to a quibble over a line in the license stating that “The Software shall be used for Good, not Evil”, which they believe makes the license non-free. When I asked Google’s Chris DiBona whether all Google Code projects including JSMin would be subject to bans due to this clause in the license, he replied, “Sadly, yes”.

Today, Etherpad (which was recently acquired by Google) released their source code on Google Code. Unfortunately, their source tree contains at least two different JSMin ports (one in JavaScript and one in Python), thus making Etherpad non-free and violating Google Code’s terms of service. I’ve notified Google via an email to the Google Code mailing list.

I bring this up not because I have anything against Etherpad or Google Code, and not because I want to start a fight, but because it demonstrates the slipperiness of the slope Google launched themselves down when they banned jsmin-php last week. While I may disagree with their interpretation of the JSMin license as non-free, Google is certainly within their rights to refuse to host it. However, since JSMin is so widely used by so many open source projects, Google now has to choose between banning popular, high profile projects (including their own) or applying their rules selectively and thus promoting a double standard.

So what will it be, Google? Will you remove JSMin from Etherpad, ban Etherpad, or just be—dare I say it—evil and ignore your own rules when they’re inconvenient?

If you need a new host for the Etherpad project, the lovely folks over at GitHub don’t seem to have any problem hosting JSMin.

Update (2009-12-18): Chris clarifies: “As a side note, it’s not a matter of violating the terms of service, which don’t mention specific licenses, it is against our practices, though.” I’ve updated the title of this post accordingly. Chris has also asked the Etherpad maintainers to remove JSMin, which seems to indicate that Google is going to do the right thing and follow their own rules. Admirable!

Update 2 (2009-12-18): There are several other Google-sponsored projects that fall afoul of this ban as well:

• Google’s Page Speed Firefox plugin includes JSMin.
• The SoC project, which lists Chris DiBona as an owner, includes JSLint, which is distributed under the same license as JSMin.
• The GMaps Utility Library also includes JSLint.

Google’s Chris DiBona emailed me this morning to tell me that unless I removed a specific line from the license of my jsmin-php project (a PHP port of Douglas Crockford’s JSMin), Google Code would no longer host the project.

The license in question is the one attached to the original jsmin.c, and is a slightly modified version of the MIT License. Here it is with the offending line emphasized:

Copyright (c) 2002 Douglas Crockford (www.crockford.com)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The Software shall be used for Good, not Evil.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

As Google (and some others) interpret it, this additional requirement constitutes a vague use restriction and thus makes the license non-free. Chris explained that if I were to remove that line from the license and “return to a proper open source license that we support”, then jsmin-php could stay on Google Code. Otherwise, he said, “we can’t host you”.

Of course, I can’t change the license, because it’s not my license. It’s Douglas’s license, and he wants people who use his software and derivative works of his software to use it for good and not evil. All derivative works and copies of jsmin.c either include this license or are in violation of it.

I added jsmin-php to Google Code in 2007. Since then, it’s been downloaded over 20,000 times. As of today, its new home is GitHub.

I don’t really mind moving the project—I’ve been intending to do it for a while anyway—and I certainly appreciate the fact that Chris was kind enough to send me a personal email about this before taking any action. But jsmin-php is unlikely to be the only project affected by Google’s discovery of JSMin’s license.

In my reply to Chris, I asked him:

There are quite a few other projects on Google Code that are ports of jsmin.c or include either ports or the original. Does this mean those projects will also be banned from Google Code unless jsmin.c's license changes?

Chris responded: “Sadly, yes.”

I don’t know if Google intends to proactively hunt down all projects using JSMin or whether they’ll only take action when someone rats you out, but if you currently have a project on Google Code that is derived from or includes jsmin.c, you might want to consider migrating to a new host with less restrictive policies.

I asked Douglas what he thought of this. He responded: “When did Google stop being against evil?”

Update (2009-12-09): Via @miraglia, here’s a hilarious excerpt from Doug’s talk, “The JSON Saga”, in which he gives some background on why he added this clause to the license and how often people ask him to remove it:

When I put the reference implementation onto the website, I needed to put a software license on it. I looked up all the licenses that are available, and there were a lot of them. I decided the one I liked the best was the MIT license, which was a notice that you would put on your source, and it would say: "you're allowed to use this for any purpose you want, just leave the notice in the source, and don't sue me." I love that license, it's really good.

But this was late in 2002, we'd just started the War On Terror, and we were going after the evil-doers with the President, and the Vice-President, and I felt like I need to do my part.

[laughter]

So I added one more line to my license, which was: "The Software shall be used for Good, not Evil." I thought I'd done my job. About once a year I'll get a letter from a crank who says: "I should have a right to use it for evil!"

[laughter]

"I'm not going to use it until you change your license!" Or they'll write to me and say: "How do I know if it's evil or not? I don't think it's evil, but someone else might think it's evil, so I'm not going to use it." Great, it's working. My license works, I'm stopping the evil doers!

Audience member: If you ask for a separate license, can you use it for evil?

Douglas: That's an interesting point. Also about once a year, I get a letter from a lawyer, every year a different lawyer, at a company--I don't want to embarrass the company by saying their name, so I'll just say their initials--IBM...

[laughter]

...saying that they want to use something I wrote. Because I put this on everything I write, now. They want to use something that I wrote in something that they wrote, and they were pretty sure they weren't going to use it for evil, but they couldn't say for sure about their customers. So could I give them a special license for that?

Of course. So I wrote back--this happened literally two weeks ago--"I give permission for IBM, its customers, partners, and minions, to use JSLint for evil."

[laughter and applause]

And the attorney wrote back and said: "Thanks very much, Douglas!"

You can see the full video of the talk at YUI Theater (the excerpt above is from 39:45).

History Lite is a new YUI 3 Gallery module that provides an extremely lightweight (856 bytes minified and gzipped) and flexible Ajax browser history API. I originally wrote History Lite as a YUI 2 module for use on Yahoo! Search, and when the YUI 3 Gallery was announced recently, I jumped at the chance to port it to YUI 3 and release it publicly.

What’s it For?

Ajax applications often involve client-side interactions that change the contents or state of the page without performing a full page refresh. Unfortunately, browsers don’t record new history events for this kind of interaction, which means that the back/forward buttons cannot be used to navigate through the client-side changes. It also means that bookmarks and copied/pasted URLs will not return the user to the actual page state they might expect.

History Lite and other similar libraries provide APIs that Ajax applications can use to programmatically add state information to the browser’s history by manipulating the document’s location hash (the part of the URL after the # character), thus preserving the expected back/forward button behavior. This also results in copyable, bookmarkable URLs that allow an Ajax application to restore its state when it’s loaded.

YUI 2 and 3 already provide an excellent History utility written by my colleague Julien Lecomte. However, it has a few inconvenient requirements — an <iframe> must be added to the page, and all state parameters must be pre-registered before the module is initialized — which are necessary in order to provide full support for IE6 and IE7. This makes it a bit heavy for performance-sensitive use cases (especially since the <iframe> causes another HTTP request) and results in an API that can be difficult to share between multiple unrelated modules that coexist on a page.

History Lite provides only partial support for IE6 and IE7, which makes it possible to have a much smaller implementation and a more flexible API that doesn’t require any pre-existing markup or initialization. If supporting older versions of IE is critical for you, then you should use the YUI History utility. However, if you’re willing to do without legacy IE support, History Lite is a good alternative.

Usage

History Lite is hosted on the same Yahoo! CDN as YUI 3 itself, so you don’t even need to download anything to use it. Just tell YUI where to find it and it’ll be loaded automatically on demand:

<script src="http://yui.yahooapis.com/3.0.0/build/yui/yui-min.js"></script>
<script>
  YUI({modules: {
    'gallery-history-lite': {
      fullpath: 'http://yui.yahooapis.com/gallery-2009.12.15-22/build/gallery-history-lite/gallery-history-lite-min.js',
      requires: ['event-custom', 'event-custom-complex', 'node']
    }
  }}).use('gallery-history-lite', function (Y) {

    // Y.HistoryLite is now available to your code.

  });
</script>

History Lite doesn’t require any initialization, and the API consists of the add() and get() methods and the global history-lite:change event. Yep, that’s really the entire API!

Subscribe to the history-lite:change event to be notified when the history state changes. This occurs whenever a history parameter is added, modified, or removed. This example just logs stuff to the console to demonstrate how things work, but typically this is where you would implement any logic necessary to change the state of your application:

Y.on('history-lite:change', function (e) {
  // Properties on e.changed represent new or changed history parameters.
  Y.each(e.changed, function (value, name) {
    console.log(name + ' changed to "' + value + '"');
  });

  // Properties on e.removed represent history parameters that have been
  // removed.
  Y.each(e.removed, function (value, name) {
    console.log(name + ' was removed');
  });

  // The get() method returns the current value of the specified history
  // parameter. If you call get() without specifying a parameter name,
  // it'll return an object containing all current history parameters and
  // their values.
  console.log('current value of foo is ' + Y.HistoryLite.get('foo'));
});

In addition to listening for the history-lite:change event, it’s also a good idea to call get() when the page loads in order to restore state from a bookmarked or copied/pasted URL.

Use the add() method to add new entries to the browser history. Each call to add() will modify the document’s location hash, thus triggering the history-lite:change event:

// The add() method accepts an object containing key/value pairs of
// history parameter names and values. Each call to add() creates a new
// browser history entry.
Y.HistoryLite.add({foo: 'bar', baz: 'quux'});

// The add() method will also accept a query string.
Y.HistoryLite.add('foo=kittens&bar=puppies');

// A null or undefined value causes that parameter to be removed from
// the history state.
Y.HistoryLite.add({foo: null, baz: 'monkeys'});

Whenever you want your application to perform a state-changing action, use add() to trigger a change event and then perform the actual state change in the event handler (or in code called from the event handler). This enforces code modularity while also ensuring that state changes are explicitly tied to history events.

Supported Browsers

• Firefox 2+
• Google Chrome (all versions)
• Internet Explorer 8+
• Opera 9+
• Safari 3+
• Mobile Safari (all versions)

IE6 and IE7 are partially supported in that state changes and back/forward navigation within a single pageview will work, and bookmarked URLs will restore state. However, after navigating away from a page and then returning using the back/forward buttons, previous Ajax history from within that page will be lost.

Sanitize 1.1.0 is now available. The biggest change in this release is a migration from Hpricot to Nokogiri, contributed by Adam Hooper. In addition, a new :output config setting allows you to specify whether you want Sanitize to output XHTML (the default) or HTML4, and Peter Cooper contributed a fix for a bug in which Sanitize would incorrectly strip a whitelisted URL if a path segment contained a colon.

To install or upgrade Sanitize via RubyGems, run:

gem install sanitize

The following badly edited paragraph from an article at Telegraph.co.uk raises some serious questions about what my iPhone is doing when I’m not looking:

Blackberries, iPods, mobile phones, plams TVs, navigation systems, and air defence missiles all use a sprinkling of rare earth metals. They are used to filter viruses and bacteria from water, and cleaning up Sarin gas and VX nerve agents.

It also raises other questions, like “what’s a plams TV?” and “did anyone even read that last sentence before publishing this article?”

Oh yeah, and there’s some other stuff about China hoarding the world’s supply of vitally important rare earth metals and leaving everyone else to fend for themselves, but if the article was researched with as much care as it was edited, it’s probably safe to assume it’s mostly wrong.

I’ve reviewed three different desktop backup applications on wonko.com over the years: Carbonite, Mozy, and CrashPlan. I stopped using Carbonite because it was too basic and too expensive. I stopped using Mozy because I lost hundreds of gigs of data due to a hard drive failure and Mozy’s horrendously broken restore process made it impossible to restore many of my backed up files. I still use CrashPlan, which I love and which has reliably saved my ass several times.

My backup software reviews are among the most commented-on posts on this blog. People find them in searches and can’t resist adding their thoughts. These posts still get several new comments each week. Since my blog has become a repository of comments, both positive and negative, on backup software, I thought I’d tally up the totals.

To produce the graph below, I perused all the comments on this site that were attached to one of my backup software reviews or which contained the name of one or more of the aforementioned backup applications. I excluded my own comments and comments from users who clearly hadn’t actually used the software in question. This graph is a tally of all the positive and negative comments that remained for each application.

The totals are as follows:

Carbonite: 1 positive, 3 negative
CrashPlan: 7 positive, 1 negative
Mozy: 10 positive, 88 negative

I’m not sure the totals for Carbonite and CrashPlan are even statistically relevant, but it’s clear that people hate Mozy (or at least that people who search for Mozy and find this blog hate it).

Update: I’ve updated the totals and the graph to reflect the comments on this post as of 2009-08-14 17:53 PDT.

After quite a while without updates, I’ve finally released version 2.0.0 of LazyLoad.

LazyLoad is a tiny (only 1,541 bytes minified), dependency-free JavaScript library that makes it super easy to load external JavaScript and (new in this version) CSS files on demand. It’s ideal for quickly and unobtrusively loading large external scripts and stylesheets either lazily after the rest of the page has finished loading or on demand as needed.

In addition to CSS support, this version of LazyLoad also adds support for parallel loading of multiple resources in browsers that support it. To load multiple resources in parallel, simply pass an array of URLs in a single LazyLoad call.

Downloads

• lazyload.js (full source)
• lazyload-min.js (minified source)
• Archive: tgz | zip

Usage

Using LazyLoad is simple. Just call the appropriate method — css() to load CSS, js() to load JavaScript — and pass in a URL or array of URLs to load. You can also provide a callback function if you’d like to be notified when the resources have finished loading, as well as an argument to pass to the callback and a scope in which to execute the callback.

// Load a single JavaScript file and execute a callback when it finishes loading.
LazyLoad.js('http://example.com/foo.js', function () {
  alert('foo.js has been loaded');
});

// Load multiple JS files and execute a callback when they've all finished.
LazyLoad.js(['foo.js', 'bar.js', 'baz.js'], function () {
  alert('all files have been loaded');
});

// Load a CSS file and pass an argument to the callback function.
LazyLoad.css('foo.css', function (arg) {
  alert(arg);
}, 'foo.css has been loaded');

// Load a CSS file and execute the callback in a different scope.
LazyLoad.css('foo.css', function () {
  alert(this.foo); // displays 'bar'
}, null, {foo: 'bar'});

Supported Browsers

• Firefox 2+
• Google Chrome (all versions)
• Internet Explorer 6+
• Opera 9+
• Safari 3+
• Mobile Safari (all versions)

Other browsers may work, but haven’t been tested. It’s a safe bet that anything based on a recent version of Gecko or WebKit will probably work.

Caveats

All browsers support parallel loading of CSS. However, only Firefox and Opera currently support parallel script loading while preserving execution order. To ensure that scripts are always executed in the correct order, LazyLoad will load all scripts sequentially in browsers other than Firefox and Opera. Hopefully other browsers will improve their parallel script loading behavior soon.

Sadly, Firefox, Safari, and Google Chrome don’t provide any indication when a CSS file has finished loading. In these browsers, CSS load callbacks will execute after a short delay, but there’s no way to automatically guarantee that the CSS has finished loading before the callback is executed. Luckily, there’s a fairly painless manual workaround that you can use to detect when CSS has finished loading, but it’s not possible for LazyLoad to do it for you.

Yesterday marked the end of the seven full business days Chase said it would take them to respond to my claim, but I hadn’t heard a thing from them, so I called them this morning. They said a refund check was mailed today. Assuming they’re telling the truth, it looks like I won’t have to go through the hassle of disputing the ACH transfer with my bank.

Hopefully this will be the last time I ever have to deal with Chase.

Earlier this month I paid off a car loan I had through Chase. You may remember that I’ve had a few problems with Chase before, so I was happy to finally be finished with them. Unfortunately Chase was not finished with me.

According to Chase’s website, my loan was paid off in full on July 6th and the account was closed on the 8th. On July 9th, I received a letter from Chase notifying me that the account had been “fully satisfied”, along with a small overpayment refund check.

On July 21st, 13 days after my account was supposedly closed and 12 days after Chase had informed me in writing that the loan was fully satisfied, Chase withdrew a payment of $687.10 from my checking account (which is at another bank).

I noticed the withdrawal late Thursday night and immediately filed a transfer inquiry via Chase’s website telling them to refund the erroneous charge. Friday morning I received a response saying that the payment was not erroneous and had been submitted according to my instructions. I was told to call a 1-800 number to request a refund.

I called the number immediately, waded through the usual onerous phone menus, and eventually reached an operator only to discover that I had been given the number for Chase’s mortgage division, not the auto finance division. The operator gave me another number, which turned out to be the credit card division. Finally, after realizing Chase couldn’t be trusted even to get their own phone numbers right, I found the correct number on the website and reached a human being.

It was clear as soon as I explained the situation that this was not an uncommon occurrence. The representative I spoke to told me that Chase had withdrawn the payment because I had not deactivated my automatic loan payments after paying off the loan. I pointed out that the automatic payment authorization I had given authorized Chase to withdraw payments “for the life of the loan”, and that since I had paid off the loan and Chase had informed me the account was closed, I expected the “life of the loan” to be complete. I’ve paid off three other auto loans through various banks over the years, and this has always been the case.

She countered that Chase’s interpretation of “for the life of the loan” is actually “for the original terms of the loan”. Since it was a 72-month loan and I had paid it off in 13 months, Chase would continue withdrawing payments for the full 72 months unless I manually canceled the automatic payments.

“So, if you keep deducting money from a customer’s account when there’s nothing for that money to actually pay for, where does the money go?” I asked her.

“It goes into a holding account until the customer calls and asks for a refund,” she replied.

I pointed out that that’s exactly what I was doing, and she said that I needed to fax an explanation and a copy of my bank statement showing the withdrawal to Chase’s research department, which would “investigate my claim”.

“I’m not making a claim,” I told her. “I’m telling you to return the money that you stole from my bank account without authorization. That’s a fact, not a claim.”

She launched into another scripted explanation of the meaning of “for the life of the loan” and how it’s the customer’s responsibility to cancel the automatic payments.

“So you’re saying that because Chase is too cheap to develop working software, it’s Chase’s policy to hold customers’ money hostage until the customer proves, to Chase’s satisfaction, that their money is rightfully theirs?”

“No, you just need to call and ask for a refund.”

“I just did that and you told me I have to file a ‘claim’ with the research department so that they can ‘investigate’.”

“Well…yes…”

I gave up on the conversation, got the fax number for the research department, faxed them the required information, and have naturally heard nothing back. My money remains in limbo and, according to the woman I spoke to, may remain in limbo for seven business days before the research department concludes their “investigation”, if in fact they even received my fax in the first place.

If I don’t hear from Chase within the promised seven business days, I plan to contact my bank and dispute the withdrawal as fraudulent.

Update (2009-08-05): Chase says the check's in the mail.

This post was originally published on Techyard, an internal Yahoo! site. I’m republishing it here (lightly edited) since it’s relevant to this blog’s audience, and since it explains what I’ve been working on for the last few months that’s been keeping me from blogging.

One of the primary goals behind the design of Yahoo! Search Pad was to create a simple structured document editor that was fast enough and intuitive enough that it would be a viable replacement for the desktop apps (primarily text editors and, to a limited extent, Microsoft Word) that many people use to keep notes while doing research online.

To that end, it was important that Search Pad be as responsive as a desktop app while coexisting seamlessly with the web-based Search experience. It was also a strict design requirement that the user not have to install any browser addons or external apps in order to use Search Pad; it had to work perfectly and effortlessly in any A-grade browser.

Since a Search Pad document is really just a collection of notes, our original approach was to store the document in server-based session storage while it was being edited, with changes (new notes, deleted notes, updated notes, etc.) persisted to the server instantly via Ajax. Unfortunately, there were several major issues with this Ajax-heavy approach:

1. Note changes occur very frequently in typical Search Pad usage, which meant we were firing off a lot of Ajax requests. This put a substantial load on our frontend servers.
2. The frequent Ajax requests made the app feel very…well…Web-ish. It wasn’t slow, but it certainly wasn’t as responsive as a desktop app.
3. Users had a tendency to work with their Search Pad documents in several tabs or browser windows at once, which created consistency issues since the document state was stored on the server and the multiple tabs/windows couldn’t be reliably kept in sync without significant complexity.
4. Due to the stateless nature of HTTP and the fact that two nearly simultaneous Ajax requests might be dispatched to two completely different frontend servers and, indeed, might even be handled out of order, we were faced with the possibility of having to avoid asynchronous requests entirely in order to prevent race conditions and data loss

It quickly became apparent that these technical issues and the user frustration that resulted were simply not going to be acceptable, so we began working on an alternative: using client-side browser storage to store the active document entirely on the user’s machine during editing. This would eliminate the need for frequent Ajax requests and drastically simplify the server-side architecture while also making the app feel more responsive.

There was only one problem: not all A-grade browsers support HTML5 Storage yet. And of those that do support it, not all of them support all of it; since it’s not yet a finalized specification, there are implementation differences. Many web apps make use of Flash storage, Yahoo! BrowserPlus, or Google Gears to smooth out these differences, but since Search Pad could not require any browser plugins, those were all off the table.

Fortunately, while not all A-grade browsers support HTML5 Storage, all of them except Opera do at least support some form of usable client-side storage better than cookies. Since Opera accounts for only a tiny fraction of Yahoo! Search pageviews, we made the decision to go ahead and create a simple JavaScript storage abstraction library that would allow us to support all the major browsers including IE6 and 7. We’re hoping Opera will add support for HTML5 storage soon.

Here are the different storage layers our library uses in order to provide HTML5-like key/value storage on all supported browsers:

• Firefox 3.5, Safari 4, IE8: HTML5 localStorage; these modern browsers all support the core localStorage functionality defined in the HTML5 draft.
• Firefox 2.x and 3.0: Gecko globalStorage, a very early implementation similar to HTML5’s localStorage.
• Safari 3.1 & 3.2: HTML5 Database Storage, because Safari 3.1 and 3.2 don’t support HTML5 localStorage.
• IE6, IE7: userData persistence, a rarely used IE feature for associating string data with an element on a web page and persisting it between pageviews.
• Google Chrome: Gears Database API, which is built into Chrome and thus doesn’t require a separate install. Surprisingly, Chrome doesn’t yet natively support any form of HTML5 Storage.

We’ve found that using client-side storage rather than making frequent Ajax requests makes Search Pad feel incredibly responsive, even on ancient browsers like IE6, while also decreasing the load on our frontend servers. In addition, being able to persist relatively complex data on the client between pageviews has opened up exciting new possibilities.

The YUI team and Mint.com’s Matt Snider are currently working on a client-side storage utility similar to (but more powerful than) the one we created for Search Pad. It’s slated for inclusion in YUI 2.8.0, which is currently scheduled for a Fall ’09 release.