VoIP call transfer?
Paul McMillan
Paul at SemiCubic.com
Mon Apr 2 21:29:38 CEST 2007
Adrian, thanks for an insider's viewpoint.
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...
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.
For anyone who hasn't looked at it, it can be found here:
http://www.skype.com/company/legal/terms/api.html
The areas I feel are objectionable:
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.
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.
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.
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.
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.
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.
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...
Anyway, sorry for the long and slightly off-topic post...
-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070402/50439986/attachment.htm
More information about the community
mailing list