Jon Rose has just posted a great article on InfoQ about the Top 10 Adobe Flex Misconceptions. Let me know what you think about this list and my responses.
InfoQ: Top 10 Adobe Flex Misconceptions
This entry was posted in Flex. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
6 Comments
I read that earlier today. Interesting. The company I work for may be adding Flex to its list of available techs. I’ll keep this handy just in case. Thanks James.
The list and responses seem fine, though it doesn’t cover my #1 problem with Flex and AIR: the SDK license terms. Using the Flex 2.0.1 SDK license for the purposes of quoting, in 2.1.3 Restrictions, we find:
“(b) Development Restrictions. Licensee agrees that Licensee will not use the SDK Components to create, develop or use any program, software or service which (1) contains any viruses, Trojan horses, worms, time bombs, cancelbots or other computer programming routines that are intended to damage, detrimentally interfere with, surreptitiously intercept or expropriate any system, data or personal information; (2) when used in the manner in which it is intended, violates any material law, statute, ordinance or regulation (including without limitation the laws and regulations governing export control, unfair competition, antidiscrimination or false advertising); or (3) interferes with the operability of other Adobe or third-party programs or software.”
My general philosophy on software licenses is that if *I* can think of how Adobe’s attorneys can use their license against me, then Adobe’s attorneys can think of the same thing. In this case, part (2) is just plain indefensible. One can’t possibly know every law, statue, ordinance, and regulation in all jurisdictions around the world (from nations to villages) for all of recorded history (since there’s no temporal or geographic scope to the clause). Applications one might build using Flex might well violate some law somewhere — a Flex chat client that allows people to choose their own nicknames might violate the law in Sudan if it doesn’t prevent people from choosing the nickname “Mohammad” (witness the recent teddy bear incident). But regardless of whether there is an actual incident that triggers, say, a fatwa against a Flex developer, Adobe can yank the right to develop Flex applications, just because the law exists. Heck, Adobe can probably revoke the Flex license from any developer at any time, as I’ll bet there was some law in some community somewhere sometime that barred the creation of “graven images” (based upon a literal interpretation of Exodus 20:4 (KJV)), which might well apply to Flash-based GUIs.
Weasel clauses like this one are why I inspect software licenses closely. In this case, the current revision of the Flex and AIR SDK licenses don’t pass my smell test. Someday perhaps Adobe will muzzle their attorneys and ditch the weasel clauses. Until then, AsWing or Laszlo or kin will have to be my solution for component-based Flash development. That sucks, as Flex and AIR look really slick.
If somebody knows a way to develop Flex or AIR applications without the Adobe SDKs, I’d be very interested, as that’s another way to get around the license issue.
Hi, James.
I was curious to see you mention osflash.org as an alternative to Adobe simply lifting the restrictions on the existing (and published, though caveat reader due to tainting concerns) specification on the Flash format and bytecodes. Is that meant to indicate that Adobe recommends osflash.org as a source of information on the format, and that they consider the documentation effort there to be legitimate and permissible? Given Adobe’s history of pursuing criminal charges against people who built tools to work with “protected” file formats — I refer to Sklyarov here — I think that such a statement would be of great reassurance to myself and others who have contributed to open source Flash tools.
I must say that I also think it’s somewhat disingenuous, to borrow the term from your colleague Mike Chambers, for you to say that you’ve released the core of Flash Player in Tamarin, without even acknowledging the enormous amount of technology and behaviour that’s still hidden away inside the Flash VM itself.
“I was curious to see you mention osflash.org as an alternative to Adobe simply lifting the restrictions on the existing (and published, though caveat reader due to tainting concerns) specification on the Flash format and bytecodes.”
Really? I was astonished, simply astonished that you were curious…. ;-)
“Is that meant to indicate that Adobe recommends osflash.org as a source of information on the format, and that they consider the documentation effort there to be legitimate and permissible?”
It’s sort of hard to ask an individual within a group of people to speak for the entire group. I know that leaders within Adobe regularly speak very well of osflash.org, and I’ve known and trusted many of the contributors there for many years, but I don’t know of any official Adobe document about various individual materials on the site. (If you’re concerned about something in particular, then I’m not a lawyer and cannot advise, sorry.)
jd/adobe
Hi Mike,
I’ll have to echo JD’s response.
-James
JD: Well, yes, I was curious because I’ve heard reports from colleagues of Adobe representatives saying things like “I think we’re going to sue [osflash.org]” at conferences, and I was hoping that James’ barely-implicit endorsement of their work would be a sign that they (and I) are safe from such plans. The DMCA and licenses on various installers would indicate to me that Adobe does not approve of people determining how their technology works, and it would seem to be poor form for someone like James to recommending such a site without his having some confidence that use of the materials is not going to lead to legal problems for developers.
James: I echo to you my response to JD. :)
Mike