Adrian, thanks for an insider's viewpoint. <br><br>What you describe (a Linux/ARM gateway binary) would be an acceptable solution for many people, since it wouldn't overly burden the device with a full-blown Skype client, and would provide the connectivity to integrate Skype contacts alongside sip and other voip protocol contacts. I would probably use it myself, considering how many people I know who use Skype...
<br><br>The other thing that worries me about Skype and this device is the license for the Skype api... It's not an open source license, and it really departs quite heavily from such ideals, to the point that many OS developers would probably refuse to work on a project involving it because of the constraints and requirements it places on their heads.
<br><br>For anyone who hasn't looked at it, it can be found here:<br><a href="http://www.skype.com/company/legal/terms/api.html">http://www.skype.com/company/legal/terms/api.html</a><br><br>The areas I feel are objectionable:
<br>2.(b) Doesn't clearly define hardware device. Does an application installed on the NEO qualify? I think it's rational to argue that no, OpenMoko is a platform, users can install whatever they want, but an argument in court would point to other "hardware devices" like handsets and say that the NEO was no different, and thus subject to the additional requirements including that all developers be part of Skype's Hardare Partner Scheme.
<br><br>3.6 Potentially limits our ability to make the service useful... If we can't cache the Skype password (and I'm assuming the api won't let us do that either, I could be wrong), then we can't provide good functionality to users who are moving in and out of internet coverage. This might be different in the terms for an embedded oriented solution. Ideally, the user will never have to interact with a skype-branded interface, since our goal here is total integration.
<br><br>6. Places a great burden on developers. You become technically liable the moment a new version is released. Open source developers are very wary of even the most technical legal liability, since groups trying to kill open source projects will often seize upon said liability and base entire court cases around it. This also makes no provision for developer testing to make certain the new version doesn't break their software before deploying it.
<br><br>8. Again, this is an extremely objectionable clause for open source developers. Yes, this is standard corporate legal terminology, but an open source developer is NOT a corporation, and will not have the financial power to legally prevail in any dispute, let alone pay for the other side's expenses.
<br><br>9. Similar to the objection to 6, if the terms change overnight, any developer is legally liable from the moment the change occurs. Open source developers particularly detest licenses which are subject to change without notice, and really cannot stand the idea of agreeing in advance to any change in license agreements. These may be standard commercial wordings, but they make working on Skype an extremely risky thing for an open source developer to do, even if they do believe that Skype has the best of intentions.
<br><br>Open source licenses are stable and well understood. The Skype api license is neither, and thus presents more risk for those who are interested in working with it. Realistically, Skype is unlikely to make major changes to the API, and is unlikely to do horrible nasty things with it, but the framework is laid out so that it is POSSIBLE for them to do that, which scares developers.
<br><br>Even adding an agreement such that Skype was required to attempt to send out an email notice of changes, and provide a month under which developers could use either version of the license, and maybe the same period for the stable API would go a long way towards making it a more friendly license. Section 8 is still quite scary though...
<br><br>Anyway, sorry for the long and slightly off-topic post...<br><br>-Paul<br>