One step forward, two steps back – AOL’s new „openness“

Great news! AOL finally opens it’s OSCAR protocol for developers by providing extended information through its OpenAIM program with a SDK, tutorials and all you need to build up aim compatible messengers or even bots. But is it that open? I mean, we know the difference between „open“ and „free“, don’t we? So a closer look at the license terms shows things you really don’t want to see and that are just unacceptable:

1. The „choose two from five“ rule:

„Additional Feature Requirements. Any Custom Client or Web AIM Developer Application that you distribute must include at least two of the following features or functionalities („Additional Features“) as an integral part of such distributed Developer Application:
  1. AIM Expressions. Inclusion of the capability for your users to choose and display a Buddy Icon to customize his or her user experience and provide a link to the AOL-Hosted AIM Expressions web page as documented in the AOL Additional Features document.
  2. AIM Toolbar. Inclusion of the AIM Toolbar as a user-selected option during the registration/download/installation process for the Developer Application, as applicable.
  3. AIM Start Page Launch. Inclusion of the launch of the AIM Start Page upon users. logon to your Site or to the Developer Application.
  4. Buddy Info. Inclusion of content provided by AOL that includes information about a user’s online status, including the user’s AIM profile, and AOL-supplied advertising.
  5. Advertisement. Inclusion of an AOL-provided display advertisement („Advertisement“) within your Custom Client, Site or activity window. Unless otherwise provided in a written agreement, all revenue from such Advertisement will belong to AOL.“


So let’s say you want to develop a free, non-commercial client. Your best choice’d be choosing to implement „AIM Expressions“ and „Buddy Info“. That might be okay but it might be not. And actually it should be your decision, shouldn’t it? Even more interesting: What about console clients? Yes, they are around and it might be possible they haven’t ever heard of icons. Are they disallowed by default? Aren’t you free to choose a very different style of artwork for „expression“ by dropping the standard set and developing a new one?

2. The additional „hope to be unsuccessful rule“

Okay, this might be pettifoggery, but let’s also assume your client is implemented with the mentioned
requirements, people start to download your client, so it is widely used. Fine? Uh, yes, AOL thinks so too, as they are really interested in that:

„In addition to, and not in lieu of, the above requirements, in the event that the number of simultaneous users of your Custom Client or Web AIM Developer Application reaches a peak level of 100,000 at any time (as defined by AOL and provided at you must either: (i) within ninety (90) calendar days also include an Advertisement within your Custom Client, on your Site or the primary activity window of your Open AIM Developer Application, and discontinue any version of the Custom Client or Site/Activity Window that does not include an Advertisement; or (ii) within fifteen (15) calendar days, contact AOL at the following address: [email protected] and reach agreement on alternative arrangements satisfactory to AOL.“

So what is this about? If your application is a success, make it commercial in a way. Free software is for a niche, big market shares are for winners? Be afraid of having 100.000 peak users? Stop distributing uncommercial clients if having success?

So, really thank you, AOL, for moving towars openness. But the way you define „open“ is not the way we mean it. It is not even „free beer“ you are giving away, it’s a glass of free beer with a big refund sticker on it. But you already showed that you know what is all about: Just a couple of weeks ago information about a xmpp/jabber aol/aim test server leaked and you might have noticed how enthusiastic people were. Stick to it, be brave! Other big companies already use it by default.

Think about companies forcing developers to implement similar „features“ into mail applications just because they transport mail to a specific domain, with a specific mime type or whatever. You would not like it? We don’t either. Make your protocol open and free. Your users are users – not customers, developers not employees.