First, why do you care if they're GPL, or more generally a "copyleft" license? As long as they're under a OSD-compliant or "free software" license, they should suit the mentioned purpose of standardizing across open-source OS distributions, and the fact that someone can make a proprietary derivative doesn't really seem to matter to that end.

Second, right on the front pages so conveniently linked by MartinK...
3 minutes of poking at the FSO site turned up nothing definitive (I'd guess license varies by package), but there is a Licensing proposal in the wiki.

Good thing someone happened by with a web browser and enough time to click through those links, or I guess you'd still be wondering...

The content on that page is a bit ancient (written back in 2007 and not updated since that day apart from general wiki gardening). See */COPYING under the cornucopia tree - summary: a mix of GPLv2 and LGPLv2.1.

Benson, you poor fool. I'm not worried that someone takes open-source and makes a closed-source derivative in this particular case, especially since that would imply that there IS an open-source base they forked off of. No. I worry because there is open and free source like GPL, and then there's open but a little less freer CDDL, for example. It might be handy to know how tight the chains are held on their proprietary or not-so-proprietary code. We saw how wonderfully CDDL worked for the ZFS and the related lawsuits. I don't see how simply being OSD-compliant should be enough for me to prostrate myself at the alter of open-source software, especially with the likes of even Microsoft, Oracle and others buzzing around trying to find ways to cleverly call something open while slipping in a poison pill if you do your own thing in the open. Quite the opposite from the assumption you posed, in fact. :P With Nokia's track record so far and now with their new Microsoft marriage, I wouldn't put it past them to do something like that. I admit that it would be better than fully closed-source, but it's not much better.

Ah good. So at least ofono is GPLv2. I'd be paranoid about using something with an unclear license like FSO, then.

Indeed! I'm glad you decided to participate in the conversation instead of trying to deflect it elsewhere so it wouldn't be a talking point. Right?

Hey! Look at that! I guess my asking DID bring about some productive results--you learned something too, Benson. Hey! Everybody wins when questions are asked!

Also: You're welcome.

Not to sound like a whiner, but there are some small issues with both FSO and ofono, that make them less likely to become adopted as standard:

FSO tries to integrate too much, and has too many deps (vala for one).
Everyone has their idea about the "correct" way of storing data, contacts etc. Has there ever been a standard PIM of any sort?

Can someone tell me what purpose ofono has to depend on dbus?
dbus is big and bulky, which makes it a very high level lib.
String parsing interfaces are a big no-no on most embedded platforms since they waste memory and time, and how is it better than just using a shell interface?

Vala is a build-time dependency (EDIT: You can also choose to ship the C files that it generates from the Vala files, too). Though, as a result of using Vala (with its default GLib profile), it does have a runtime dependency on GLib (part of the LSB Desktop standards, like QtCore IIRC) like all of the GTK+ applications on Maemo (including things such as the Phone application and even the non-GUI apps such as the location daemon which seems to be the program handling the AGPS stuff).

It helps external applications stay aware of events? CSD, the phone control daemon on your N900, seems to make extensive use of it; look at http://maemo.org/packages/view/csd-base/ and http://maemo.org/packages/view/csd-call/ for example.

In any case, D-Bus is a freedesktop.org standard.

I'm no programmer but, hell, what have I to lose by posting?

Regarding contacts storing standard, do you see anything wrong with VCard files?

It might be slower or less efficient but, at the very least, importing and exporting vcard should be pretty standard. (I mean individual contacts as well as multiple contacts or ALL contacts in one export/import.. shouldn't be too much to ask, I would think.)

I'm not particularly fond of some parts of GTK+ & co since many of the libs and tools are too bloated for embedded use, and many of them depend on each other for no reason what so ever.
It may be fine for n900 and similar platforms with huge amounts of memory, (once we get rid of MMC and maybe have all that 32G as pure, directly accessible nand chips)
But, memory drives up cost of the appliance and sinks performance.

I believe the largest part of the phone market needs a root system measured in a few M not G.
Look at openWRT project, it's easy to configure, comes out tiny, and they developed it out of a need for a better router distro. Now every mfg and their mom is using it in at least a few of the higher end routers since it saves them money and users get a better product. The only real competition is from vxworks, (fits in 0.5M, openWRT needs like 2-4M) which might not last long since vxworks (on routers) is becoming infamous for some pretty major stability issues (although cred is due for such a small tcp stack)

Also, yeah, vcard is about the only standard that ever came out of the PIM world (ical doesn't count yet), and I don't believe there's anything wrong with using it as the main storage mechanism. A directory with all vcards, one contact per file should also work fine, since most people don't store more than a few thousand contacts anyway. (that's assuming a good filesystem, not a stupid one like fat32)
This is demonstrated quite well by rolo.
Git is also a good demonstration of how you can use filesystem features to ignore optimising your application data store, and often the end result is just as fast, more portable and still useful after many years. ie. if something does translate well to files, you should use files, since filesystems get better all the time.
Afaik people have also invented some ways of syncing vcards with other directories.
But... Vcard is extremely verbose, and, it's difficult handle all the extensions by other apps.

It'd be interesting to see what the consequences are of using something like unison to keep 2 Vcard directories in sync instead of parsing the files. I can't immediately see a problem with that if the application only touches the file when you actually edit the contact.
*If you've edited the same contact on both ends, there's never a straightforward way of solving the conflict anyways.

To summarise; I don't think we're done with PIM by a longshot, and it'd be interesting to see people experiment with the bottom layers of PIM instead of making fancy UIs that nobody will use after a year. Who knows, maybe, just maybe, we might get a standard out of it.

Also the freedesktop.org people are bad people.
(don't tell them I said that