with the users api your users cannot be transferred, they are google users who can use your application, it isnt openid, you cant chuck this on another computer

with the users api your users cannot be transferred, they are google users who can use your application, it isnt openid, you cant chuck this on another computer and have remote authentication. I wonder, though -- what if you used something like a remote REST interface to do authentication, passing MD5'ed or SHA'ed passwords as one of the arguments, and then based auth on that? Google wouldn't like it, but technically it appears to be within the scope of the TOS. Very, very good point, though... users and data are basically the only things that matter for this type of application. I did find one of your other points spurious, though: their query language is even google specific. Oh for crying out loud -- if you can't write a Perl one-liner to convert every instance of GQL to SQL with bind variables, or if you don't already use placeholders in any instance of raw SQL in your own code, you've got worse problems than that. This is the least of the problems IMHO. Something has occurred to me regarding NumPy, SciPy, R, etc. Since it's Google's CPU time, it's not my problem if a loop or matrix calculation is inefficient. I'm going to deploy some grad students to stress test their TOS... :-)