Skype Protocol Plugin

Mark Doliner mark at
Tue Apr 28 03:27:18 EDT 2009

Sorry, this email is going to be long, but I'm hoping that helps keep
the responses succinct. :-)

Eion Robb has written a Skype API protocol plugin for libpurple (the
library that powers Pidgin and Finch) [1].  It's been brought up on
this mailing list a few times in the past, but I don't feel like we
came to a strong consensus on whether we believe this protocol plugin
is in violation of our GPL license, and I think it's important that we
do so.  Here's my best summary of the potential problems:

1. Does the plugin link with Skype?  If so it would be in violation of
libpurple's license because Skype is not licensed with a
GPL-compatible license.  There are two parts to this issue:

a) Does the plugin link to Skype in the traditional sense?  The
Makefile does not build against or include any Skype libraries and
from what I can tell no Skype code is loaded into the process at build
time or at run time.  The plugin uses different mechanisms to
communicate with Skype depending on the platform: wm_copydata messages
on Windows, D-Bus or X11 on Linux, and some sort of asynchronous
delegate functions on OS-X?  It's not clear to me if the use of any of
these constitute "linking."

b) Is the communication between the plugin and Skype intimate enough
to be considered one program?  The GPL FAQ includes this statement:
"If the two programs are combined so that they become effectively two
parts of one program, then you can't treat them as two separate
programs. So the GPL has to cover the whole thing" (also see [2]).  My
understanding is that the Skype API is a fairly high level protocol.
It includes commands like:
   CHAT CREATE YourSkypeName
   CHATMESSAGE #MySkypeName/$YourSkypeName;012345679012345 "Hello, world!"
These commands are pretty generic.  It wouldn't be hard for someone to
replace Skype with another program that spoke the same protocol.  In
other words, the plugin could easily be decoupled from Skype, which
means the two pieces should not be considered one program.

2. Skype places a bunch of restrictions on the use of the Skype API
(like accepting Skype's EULA) [3].  It is obviously not acceptable to
place these restrictions on libpurple because they are not compatible
with the GPL.  But the plugin doesn't use any source code from Skype.
Does the use of the Skype API actually impose those restrictions on
the software?  It seems like those restrictions would be placed on the
user of the software.  But this is not clear to me.

Eion also has this to add:
* I reversed-engineered the Skype.Framework library that used to be
the only way to communicate with Skype, so that I didn't break the GPL
by linking with a closed-source Framework
* I do not use the Skype API website for my reference material as
there have been issues regarding documentation and the GPL when it
came to the Oscar protocol (as a rough example), and instead painfully
watch communication between Skype and other clients (Miranda/Trillian)
to see how they work as well as examining the source code of other
clients (mainly Miranda and Skype4Py/Skype4Java).
* I am in the process of building a server so that Skype does not need
to be required to be running on the client machine to use the Skype
API.  This should help settle the critics of the prpl.  An XMPP
transport plugin would help me make a Skype XMPP server as an
alternative, making the protocol further accessible by the open-source
* I asked the Free Software Foundation on their point of view on the
topic, since they're the only free lawyer I know and since they wrote
the GPL.  Their reply is here [4] and seems to agree with both [Mark]
and I that the Skype prpl does not technically violate the GPL

The way I see it is that it is no different to someone working out how
any other protocol works; watching data between client and server (in
this case the server being the running Skype program), sending test
messages to server etc."

Whew, lot of information there.  I'm not sure what role, if any, IM
Freedom, Inc[5] should play.  We could certainly try asking for an
opinion from our lawyers, but they are just volunteers and I hate to
ask them to do unneeded work.

Here's what I think we're going to decide, if you agree feel free to
just +1 and we can keep this discussion short:
* Strictly speaking the plugin is legally OK (although only a court
could have the final say).
* The plugin violates the "spirit" of our license, because it's
basically a way for people to utilize proprietary code from our

Also, I'll be out of town starting like, now, through May 5th or 6th.
I'll have limited access to email, but other than that I'll be more
usless than usual.  rekkanoryo is our other Summer of Code admin, so
please talk to him if we need to make any changes or anything.



More information about the Devel mailing list