Catching my attention this week was a recent post on the Deeplinks blog of the Electronic Frontier Foundation (EFF), which sounded an alarm about the one-sided nature of Apple’s license agreement for the software development kit (SDK) for iPhone apps. The EFF can reliably be counted on to frame issues of electronic rights in a manner most benefitting the user community and this perspective is usually very helpful in understanding related issues. While Apple’s SDK license is certainly written favorably to Apple, whether this should be viewed as particularly unfair or not is probably in the eyes of the beholder. You can read the post here: http://www.eff.org/deeplinks/2010/03/iphone-developer-program-license-agreement-all.
I think the more interesting aspect in this commentary is the implication that apps developers should be surprised by any of these revelations of the license terms that they presumably voluntarily agreed to when they clicked their acceptance to them. Granted, it is all too common to glide through the fine print packed into online terms, and maybe momentarily pause before clicking acceptance. We’ve all done it, including this writer, simply because the consensus view (which also happens to be true enough in most situations) is that the risks posed by agreeing to the expected “plain vanilla” terms of the clickwrap are almost always never greater than the benefits to be obtained by agreeing to the terms. Certainly in the consumer context this is very often the case (even with the risks of buried “opt ins” to ad server programs, among other annoyances). Much of the time the same can be said of clickwraps in the commercial context.
The difficulty then is to know what exceptions justify taking a harder look at the details of clickwrap terms before taking the “I Accept” plunge. Unfortunately, there are no objective rules here because these agreements are not uniform and too many variables are almost always at play from both the licensor and licensee perspectives. So, what to do? My rule of thumb is that if the clickwrap involves your use of or access to something (whether it be an application or otherwise) that is critical to the ongoing stability or continued operation of some key business activity of yours and the object of the clickwrap will be used on a regular basis in the business, then you are well advised to have a hard look at the clickwrap to make sure it can be comfortably adhered to, and, if not, to see if the proponent of the clickwrap has an alternative means of allowing access to the desired application or thing. This goes back to the fundamental risk calculus related to assessing the potential consequences if one is wrong about a key assumption and, if so, whether your business would thereby be placed in significant jeopardy. In addition, my general approach is almost always to at least skim such agreements before clicking acceptance to make sure that nothing obviously problematic jumps off the screen.
So, if you’re with a software development organization planning to participate in the apps ecosystem for Apple’s iPhone or Google’s Android (or, really, any other mobile devices) as a key component of your business plan, then getting comfortable with (or at least being aware of) the scope and details of the applicable SDK license terms is something that should be dealt with at the outset rather than on the back end once your wagon is hitched to that star.