AIM SDK License Clarifications

I have seen many posts ragging us for the language we have in the AIM SDK regarding what you can and cannot do. I agree that the language is confusing and overbearing in some parts, and often the legal text sends a message that is different than what we intended.

The next version of the EULA will have many of these things remedied, but until then, let me try to clear up some of the sticky issues. (Many of these questions were submitted in an email exchange that you can see here.)

If you have more questions about the license - or are still unhappy with terms in the license - please let me know so that I can try to clarify the issue, not just for you, but for everyone who reads this blog. This is the first effort of this type at AOL and we are still learning how to do this.

Keys, Name, URL
Q: Why is AOL using keys to control access to the API? I don't want to have to come beg AOL for a key!
A: Anyone can get a key. You don't have to "apply", you just go to our webpage
and click a link. We don't vet the keys in any way, you just click and boom you have a development and deployment key. You can deploy your software, sell your software, have up to 250,000 users of your plugin/client per day - all completely for free. All we ask is that once you exceed that limit (as you start to approach 1% of our userbase, and potentially start consuming nontrivial network resources) you come discuss a business arrangement with us.

For those still unconvinced, Google is doing the exact same thing for access to the Google family of web services. It allows the network operator to know who is using the network, and prevent people from abusing the network (spam, malware, etc).

Lastly, many have asked "I don't know what to put in when for the name/URL fields when applying for a key". The name and URL are intended to allow us to help us monitor the network, by allowing us to get more information about your plugin or client. If you are still in the development phase, and don't know what to put for these fields - you can just make something up for now - you can go back and change it later.

Open Source
Q: Section 4 (viii) (about "Publicly Available Software") seems to be the subject of debate. Some think that it forbids the use of *any* open source code with theSDK, including well-understood licenses that are not "viral". The GPL is notoriously problematic, but I think others (like the MIT license) should be okay.

A: We encourage the use of open-source code with the SDK. The only prohibition is that you cannot write code with a license that would require AOL to open source the SDK. I think the GPL is the only license that has this issue (since you cannot link to closed-source libraries); LGPL, BSD, and MIT should be fine.

We will try to make this absolutely clear in the next EULA. We are very supportive of open source - we use several best-of-breed open source technologies in the AIM SDK (libexpat, zlib, NSS, and sipXtapi).

Wireless
Q: The definitions for wireless use seem very broad. I think the most
worrisome part is:
offer or enable a service or functionality not authorized in writing by AOL that utilizes a wireless telecommunication carrier's network and/or wireless services.
This seems to extend to computers using a wireless internet connection. Three cases come to mind:

• 802.11 networks operated by wireless telecommunication carriers (e.g. T-Mobile Hot Spot)
• 802.11 networks using internet access provided by a wireless telecommunication carrier (e.g. a wireless router and a DSL line)
• TDMA, CDMA, GSM, etc. networks, using a computer, not a mobile device (e.g. Verizon data service using a PCMCIA card)

A: I agree this is very poorly worded. This is only intended to apply to software running on mobile phones using TDMA/CDMA/GSM.

PCs/PDAs using 802.11 are not affected by this.

Deployment
You may not deploy or distribute your Custom Client to any third party.
Q: This appears to extend to distributions that do not include a key or (distributable parts of) the SDK itself (e.g. source code).

A: This is from the section where it discusses "Development keys". The intent is that plugins built with "development" keys (as opposed to "deployment" keys) should not be distributed to end-users in binary form (mainly since the 500-user limit will prevent your plugin from working properly for most users). If you are distributing source, you may include a "development" key in the source - we do this in the sample applications provided in the SDK.

Distribution Limitations
from a fixed HTML website located at a publicly available fixed URL
Q: Theterms "fixed HTML website" and "fixed URL" seem to potentially problematic. Many pages are dynamically generated and mirroring requires redirection.

A: This just means, you can give us a URL, that if we follow it, we can get to a site that has more information about your plugin. The "fixed" language is just a way of saying that if we go to your URL, we should not get a 404.