Some time ago, I came across ID Selector from JanRain, one of a few important companies in the identity space. They have a little javascripty/css thingy that you can put on your site to help users choose from a list of popular OpenID providers and then type in their username. It’s neat and it sure beats typing in URLs.

One thing that you get to do as the founder of a venture funded startup is sign contacts. Woo, fun! Every time I sign up for something online now, I can’t help but read The Fine Print. So it was with great dismay that I read the TOS for ID Selector (see below for some delicious excerpts). The punchline is this: I can’t think of a better way to discourage people from using this cute little snip of javascript that any competent programmer could put together without material effort.

These terms of service, dear reader, are stupid because they are in nobody’s best interest. Site operators should have freedom to adjust the behavior of the widget code as necessary. JanRain should be focused on OpenID adoption, not trying to control their rights for the UI component.

Consistent behavior of the ID Selector across websites is important to ensure that users get what they expect on each usage. If you want an example of a model that works reasonably well this regard, look no further than the feed icons and the guidelines for their use that Mozilla put forth. Open. Easy. Flexible.

The identity space is moving slowly enough without unnecessary impediments like this.

But I don’t like to whine without proposing some solutions, so here’s where I’m going to stop and wait to see what happens:

1. JanRain - please change your TOS to relax these unnecessary restrictions
2. Also: release a standalone version of the ID Selector under some kind of an open license (or dual license) so sites that don’t want to have your code loaded in at runtime don’t have to
3. If JanRain won’t do #2, I’m hereby offering on behalf of StyleFeeder, Inc. to fund someone to create a standalone ID Selector that will be released under better terms. Contact me if you want to be that person.

Some fun excerpts from the ID Selector TOS. No, I am not kidding.

3. Ownership rights. The IDSelector is owned by us and our licensors. The IDSelector is protected by copyright and other intellectual property laws and treaties. We and our licensors reserve all rights not specifically granted to you. You may not reverse engineer, decompile, or disassemble any aspect of IDSelector . You may not modify, adapt, or create derivative works from the IDSelector . Do not remove proprietary notices. Do not help any one else to do any of the things prohibited in this paragraph.

[...]

6. Your responsibilities. You must use the IDSelector web site to obtain an IDSelector tool and/or code located at idselector.com. You may not copy code from another web site to use the IDSelector.

[...]

7. Your rights to use the IDSelector . We offer you the following rights to use IDSelector provided that you continue to comply with the terms of this agreement. You may not remove, distort or alter any element of the IDSelector (including the HTML and JavaScript code).

if you feel compelled to comment, please try to think of something interesting to say. youtube needs remarks like “awesome song” and “this video sucks” like it needs another shaky, blurry, garbled & distorted, 27-second camera-phone clip of Feist performing 1234 in [YOUR TOWN HERE]. thank you.

Don’t make the cryptographers cry. Especially not Ben.

How to scale « François Schiettecatte’s Blog
It not about the language, it is about the architecture.

Nearly: good algorithms and proper caching are also part of the picture.  Sure, caching is part of good architecture, but it makes such a difference that it’s worth calling it out separately.

(This should really be a much longer post…)