So, I get home after a long day’s work. Read the mail, and there it is, a letter (in the posh-looking envelopes that mean ‘bad news’) from Wells Fargo. I have a ‘toys’ account at Wells Fargo, I put $200 in it each month, and I can spend from it as I want. In this case, I’d purchased $9.99 worth of music from iTunes...

So, because that took the balance to a negative amount, Wells Fargo decided to allow the purchase (why?) and then debit my account by $35. Thirty-freaking-five dollars to send a form letter. An automated form letter that cost them the price of a stamp. It’s worse than that... there’s a $5/day fee as long as it stays overdrawn, it took 3 days for the letter to get to me, and it’ll take 3 days for funds to get there from my ‘real’ account. That’s another $30...

Well, I’ve had enough of it. I’ve had enough of being charged stupid amounts of money (almost 10x the amount I actually went over-drawn in fact) - I’d far rather the invoice just went unpaid. I’m far more likely to actually do something about an unpaid bill, after all...

So, with Wells Fargo having pissed me off once too often, what recourse do I have ? Well, it turns out I have my mortgage with Wells Fargo - with about $1,000,000 left to pay off in interest over the years. That money will now be going elsewhere.

Well done, Wells Fargo. Having ripped me off to the tune of $65, I’m now going to take over a million dollars away from you. Good piece of business, that...



update (13th August) :
Having just checked my bank account, it seems someone paid attention to my letter, and the various charges (they’d added up to $165 by this time) have been refunded back into my account. Well done Wells Fargo. Thanks for listening. I guess you get to keep my mortgage cash after all...

I'm really getting tired of this...

Over at Aristotle Pagaltzis' blog he takes John Gruber to task for not understanding the GPL. Unfortunately it's Aristotle who has his argument confused.

As mentioned before all you have to do is distribute the source code. I've looked in the developer agreement, and there's nothing about what you have to do with the source code - it's all to do with the "Application" (a defined technical term that does not include the source code). A simple analogy to bread and flour ought to be sufficient to show that the source code is separate from the application itself...

So, here's what you do to fully and freely distribute open-source code.

• 
  
• Set up a website or get a project on one of the many project-hosting sites
  
• Place a tarball of your source code on that site and link to it so people can download it
  
• That's it
  

Now the person wanting to download and play with your source-code can do so to their hearts content. If they want to run it, they can (free of any payment to Apple) do so in the simulator contained within the SDK that anyone can download from Apple's site.

If they want to run it on the phone itself, they'll need to pay (once) $99 to Apple to obtain the right-to-licence certificate-generation option. Now they can generate an ad-hoc certificate (as I mentioned in the previous post) and load the program they've just downloaded onto their own phone.

So, to go over the freedoms that this gives you, in Aristotle's own terms:

• 
  
• The freedom to run the program for any purpose (freedom 0) check
  
• The freedom to study how the program works, and adapt it to your own needs (freedom 1) check
  
• The freedom to redistribute copies to help your neighbour (freedom 2) check
  
• The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3) check
  

... looks as though John Gruber understands freedom better than Aristotle does...

The FSF have just gone on a bit of a rant about how locked-up and closed-source the iphone is, which caused a fair amount of commentary and meta-commentary, but the problem is that the basic tenet of the FSF's screed is just not true. The very first point they "make" is:

"iPhone completely blocks free software. Developers must pay a tax to Apple, who becomes the sole authority over what can and can't be on everyone's phones."

Now I have recently got my personal iphone development environment set up. I downloaded the 'accelerometer' example source as a DMG from Apple (this app graphs the accelerometer in real-time) - there's nothing special about this source code, I just wanted something a *little* more complex than 'hello world'. Any other source-code distribution would have illustrated my point just as well.

So, I went through the various certificate-signing things, and created development, distribution, and ad-hoc certificates. I compiled the code and dragged my ad-hoc certificate and the application onto itunes, then synced with my phone.

The result is that I have some-random-program (in this case the accelerometer app) whose source-code I downloaded from the internet installed and running on my iphone. I did without jailbreaking, or doing anything non-official according to Apple. I need the ad-hoc certificate at *compile-time*, which authorises my iPhone to be able to run the app, but if you're distributing open-source code, that's just fine and peachy - any recipient will want to compile it themselves anyway.

So, here's the choices if you want to code open-source stuff:

• 
  
• Generate an ad-hoc certificate for a set of phones (max 100) and deliver the certificate along with the app (binary and source). You can distribute binaries like this for an identified set of phones.
  
• Distribute your source code. Developers can compile their own version of the app and install onto their own phone using their own ad-hoc certificates
  
• Distribute the source-code on your website as above, and the binary via the app-store (for free).
  

The *only* barrier to #2, #3 is the cost of the developer program, ($99) which isn't much of a barrier. If $99 is truly out of your reach, you probably ought not be fixating on luxury items like the iphone - and in any case you can still download, compile, and run the code in the simulator. This is open-source in every aspect, and my respect for the FSF has gone down as a result of their campaign. It reminds me of Greenpeace, who don't really give a damn about whether Apple *are* green, they only care funding themselves and Apple are a high-profile target name.

I've been playing around with SQLite for some time now, and one of the things I thought I'd try out was a client-server version of the database - so here it is. It's a pretty basic implementation, but there was some chatter on the sqlite mailing list, so I thought I'd package it up and release it.

I originally wrote a lot of this in Objective C, with proper classes and methods. In an attempt to make it a bit more portable for those who haven't seen the light, I stepped down to using Foundation and plain-old-C, well apart from the demo client code anyway. ObjC is *so* much nicer than C I had to use it there :) You can get FoundationLite from Apple's website, and that should be all you need to compile against this source-code.

This is an earlier version of the code I used in a work project, so it has less functionality than the one I have at work, but I may start to fold some of that back in. I guess, as long as I re-implement rather than copy, I'm probably ok. Work are using a whole slew of my code anyway, so I reckon we're even on that score :)

The source is freeware - do with it as you please. If you'd like to credit me somewhere, I certainly wouldn't say no, but that's not necessary.

Run the server with 'sqld -I' to initalise a database in /opt/db, then do 'sqlc -u root -p sqld -d sqld' to connect to the server from a different terminal (there's -h server-hostname as well, if you want to connect via TCP). There's an auth table (initially set up as user=root, password=sqld, database=sqld) and a 'create database' pseudo-command to create new databases (which are just files in the install-dir (/opt/db by default).

This version doesn't have 'show tables', 'desc tablename' etc. The authorisation stuff does work, or at least it should. It doesn't have the change-management feature either (where different connections are notified asynchronously that cols X,Y,Z have changed in rows A,B,C in table T. I'll probably get around to putting those things back in. I think I had server-side plugins working as well - so pseudo-commands could be implemented ung loadable plugins.

It's all based around a simple packet-library concept which abstracts the network-transport. It looks a bit ugly in plain-old-C, but it does work reasonably well. Example packet dump from the server which corresponds to a client-connection trying to authenticate against the server (the three fields are 'username', 'password' and 'database')...