I attended Adobe Live yesterday. This was in two parts, an exhibition with a schedule of presentations/tutorials, and a developer day focused on Rich Internet Applications – Apollo and Flex – as well as ColdFusion 8.

I’m told that around 1800 attended, though most of these were for the main exhibition, whereas I spent almost the whole day in the developer sessions.

It was a worthwhile though low-key event and I picked up some insights into Apollo and Flex 3 as well as getting an update on ColdFusion. I’ll be reporting in more detail shortly. A couple of quick comments though.

First, this struck me as primarily a designer crowd, Flash folk interested in applications, rather than developers new to Adobe. These are just impressions so I could be wrong, but it strikes me as in interesting issue. Equally, when I went along to Microsoft’s Mix07 earlier this year my perception was that many delegates were primarily Visual Studio folk interested in web design, rather than vice versa. If I’m right, Adobe and Microsoft have inverse cultural and marketing problems here. Still, at least Adobe put on a proper developer schedule this year; it didn’t exist at last year’s London event.

Second, I found the Apollo stuff though-provoking in the light of Google’s Gears announcement as well as what Microsoft is offering with WPF. I knew that Apollo was sandboxed, but hadn’t appreciated the extent of the sandboxing. As I understand it, Apollo apps can do file i/o on the local machine, but in other respects it is locked down in a similar way to web apps running in the browser. There is no access to external libraries, OS scripting, or custom native code extensions.

That’s good from a security perspective, but it limits the extent of OS integration. So the key question: if you can’t integrate with the OS, beyond a few trivia like Start menu or Dock shortcuts, then why bother with a desktop app? Especially now that Gears has a solution to the offline problem. Maybe it is worth it just to get out of the browser window, but some at least will not see the point.

Third, I asked what if anything Adobe intends to do with Google’s open-source Gears code, but apparently I may not have the full story yet – more when I get the information.

More Google Gears Terms and Conditions madness. Gears is licensed under New BSD terms; yet before you can install the runtime you have to agree to onerous terms and conditions. Here’s clause 2:

2. Accepting the Terms

2.1 In order to use Google Gears, you must first agree to the Terms. You may not use Google Gears if you do not accept the Terms.

2.2 You can accept the Terms by:

(A) clicking to accept or agree to the Terms, where this option is made available to you by Google in the user interface for any Services; or

(B) by actually using Google Gears. In this case, you understand and agree that Google will treat your use of Google Gears as acceptance of the Terms from that point onwards.

2.3 You may not use Google Gears and may not accept the Terms if (a) you are not of legal age to form a binding contract with Google, or (b) you are a person barred from receiving the Services under the laws of the United States or other countries including the country in which you are resident or from which you use the Services.

I’m puzzled. If Gears is BSD licensed, how can Google insist that the mere act of using it binds me to these terms (which I dislike for other reasons too)? And 2.3 is bewildering: you may not use Google Gears apps if you are not an adult?

What if someone else installs Gears on your machine, and you then use a Gears-enabled app? How can terms like this possibly apply in such cases? Note that the agreement does not refer only to installing Gears, but specifically to using Gears.

By the way, you can download the source for Gears, and compile it if you can figure out how, without assenting to any such agreement.

I think Google is letting its legal team get out of hand.