The iphone and open-source (take 2)
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.
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:
... looks as though John Gruber understands freedom better than Aristotle does...
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
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 iphone and open-source
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:
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:
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.
"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.
Networked SQLite
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')...
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')...
Zune humour
So, it never occurred to me to rotate the Zune logo, but then I read 'roughlyDrafted.com' and just had to laugh. I'll let y'all decide for yourself what it spells...
I can't see Apple ever making this sort of mistake. What with the colour brown, this fiasco, I think we're getting a clear idea of how MS thinks of the Zune, and it's not pretty...