Posted on by

You agree not to install, use or run the SDK on any non-Apple- branded computer, or to enable others to do so. You may not and You agree not to, or to enable others to, copy (except as expressly permitted under this Agreement), decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, decrypt, or create derivative works of the SDK or any services provided by the SDK, or any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable law, or to the extent as may be permitted by licensing terms governing use of open-sourced components or sample code included with the SDK). You agree not to exploit any services provided by the SDK in any unauthorized way whatsoever, including but not limited to, by trespass or burdening network capacity. Any attempt to do so is a violation of the rights of Apple and its licensors of the SDK or services provided by the SDK. If You breach any of the foregoing restrictions, You may be subject to prosecution and damages.

But what is meant by “SDK”? In typical Apple-y fashion, this definition is as broad as humanly possible:

“SDK” (Software Development Kit) means the Documentation, software (source code and object code), applications, sample code, simulator, tools, libraries, APIs, data, files, and materials provided by Apple for use by You in connection with Your Application development, and includes any Updates that may be provided by Apple to You pursuant to this Agreement.

BUT CAN APPLE TELL WHICH APPS ARE FLASH?

Yes, and so can you. Some of this may have changed since the early apps were released, and I should note that my knowledge of assembly language consists of “being poor at 6510 assembler in the 1980s”, but if you peer inside the app bundles, it’s fairly easy to detect their heritage. Come along with me now, on a magical journey that I like to call…

“A TOUR OF AN IPHONE FLASH APP”

First of all, if you’ve synched your iPhone with your Mac, you will find copies of all your apps in the following directory:

{username}/Music/iTunes/iTunes Media/Mobile Applications/

Each app is stored as a file ending in “.ipa”, but an .ipa file is really just a zip archive. If you copy the file and change its file extension to “.zip”, you can unzip it by double-clicking on it.

Inside the resulting folder, you will see a “Payload” folder, which contains the app bundle — an iPhone executable file ending in “.app”. Finally, if you right-click (or ctrl-click) on this .app file and choose “Show Package Contents”, you can see what’s inside the app. This will include files for the icons, the splash screen, and so on, as well as a large file with a plain gray icon and no file extension, usually with the same name as the application. In this example, you can see the contents of the “South Park Avatar” app, as released to the iTunes store last fall:

Inside an iPhone Flash app bundle

So far, this is all fairly normal; every iPhone app looks more or less like this. The interesting part is inside that hefty 9.6 MB binary file, which presumably includes the entire Flash projector. If you view it in a hex editor, it’s mostly gibberish, but as a blind guess at how to detect a Flash projector, let’s search it for the word “flash”:

An iPhone Flash app, viewed in a hex editor

It’s safe to say that it wouldn’t be hard for Apple to add Flash-projector-detection to the long list of things they currently scan for (private API calls, etc.) during an iTunes submission.

To be clear, this is no big deal in itself. It’s presumably equally easy to spot a Unity3D-authored app, for example, and every authoring tool has a unique signature of some kind. There’s no reason to believe that Apple wants to force everyone to author in XCode — there are currently a lot of apps in the store made with 3rd-party SDKs, including some of the top-selling games of all time, and none of this is discouraged by Apple’s developer agreements. The problem, assuming there is one, will be entirely on the Windows side.

IS THERE LEGAL RISK TO FLASH DEVELOPERS?

I would say “no”. Here we insert the obligatory disclaimer — I Am Not A Lawyer, At All — but it really doesn’t seem plausible that Apple would pursue “prosecution and damages” against thousands of Flash developers for a relatively minor violation of their agreement. The violation would presumably occur when using Apple-issued signing certificates and provisioning profiles on a Windows machine; again, this assumes Apple’s definition of “SDK”.

I’m guessing that the worst case here would be Flash apps getting yanked from the store, and even that is difficult to imagine (albeit somewhat less difficult these days!) Personally, I would go for it, but then my current net worth consists largely of a 1998 Honda Civic.

IS THERE LEGAL RISK TO ADOBE?

Here I would say “potentially, yes.” Barring a technology-sharing agreement that I don’t know about, in this context Adobe is just another iPhone developer like you and me. We obviously won’t know how Flash will work until the public release later this year, but at some level Flash CS5 will have to implement the Apple code-signing utility on Windows, thus distributing a competing method of compiling Apple certificates and device provisioning profiles into a signed binary. It seems like this crosses over much more clearly into unauthorized uses of the “SDK”, although here it may depend on what specific code is open-sourced, and on which licenses are involved.

However, even if I’m right, the two possible outcomes seem to be: (i) Apple does nothing, or (ii) Apple files an injunction against the release of Creative Suite 5. In the first case, a very interesting precedent is set. And in the second case, what’s the worst that can happen? It’s not like the EULA Police are going to kick down the door and haul Shantanu Narayen away in zipcuffs. Presumably some software would be recalled, and the iPhone authoring extensions would be removed, but at the same time Adobe could score what sounds like a serious PR victory against Apple.

In short, this is a gutsy move on Adobe’s part, and we’re all very curious to see to how it turns out for them, but I like to think that I’d do the same thing in their place, where by “their place” I mean “having immediate access to a very large stack of lawyers and money”.

(Full disclosure: you should definitely buy our Corona SDK today, and thereby help me to become wealthier. We’re in direct competition with Flash for the iPhone SDK space, except that ours is available now for just $99 and people have been shipping apps under it since last year, and I’m going to go ahead and guess that Adobe will ship sometime around late June, based on our experience with CS4.)

Update: This is interesting — my amateur legal theory may be sound, according to lawyers quoted by Information Week:

Mark Methenitis, an attorney with the Dallas, Texas-based Vernon Law Group, who recently spoke about iPhone developer agreements at the Game Developers Conference in San Francisco, says that Kirchhoff’s interpretation is a fair one.

“It does seem plausible, given Apple’s and Adobe’s not too pleasant history,” he said in a phone interview.

Jason H. Fisher, an attorney at law firm Buchalter Nemer in Los Angeles, echoed that view. “It would be a technical violation of the Apple SDK to [generate and sign an iPhone binary] on a Windows machine,” he said.


Posted by . Thanks for reading...

24 Responses to “Does Flash CS5 for Windows Violate the iPhone Developer Agreement?”

  1. Paulius Uza, InRuntime Ltd.

    CS5 does not include or use any part of Apple’s SDK, documentation or tools. In CS5 applications are compiled from Actionscript 3 directly to iPhone’s native .ipa file format omitting the need of using XCode, iPhone SDK or owning a Mac for that matter.

    So far there’s no real threat to applications compiled with Adobe FPI or Adobe CS5 itself.

    Reply
  2. Evan

    Hi, Paulius. In case I wasn’t clear, I REALLY HOPE ADOBE GETS AWAY WITH THIS! It would immediately change the industry and be a big victory for everyone, because it would then be OK for everyone to release Windows iPhone-signing tools. It’s no secret that most software developers are Windows-based and would prefer not to buy additional computers just to build iPhone apps.

    But to clarify, the “native .ipa file format” is just a .zip file containing a signed .app bundle, and it’s the process of signing that app bundle that poses the interesting legal problems. Just as on the Mac side, the digital signing process will require Apple-issued developer certificates and device provisioning profiles, both downloaded from the Apple developer site, which are covered by the Developer Agreement that I quoted above, and are clearly “data, files and materials provided by Apple”, and therefore part of what Apple considers their “SDK”. (Note that the iPhone is a closed device, and unless it’s jailbroken, it won’t run unsigned code — there’s no magical way to get around this signing process.)

    So the textual violation is clear enough — but the real question is whether Apple’s contract language is ENFORCEABLE. It might not be! Big corporations are always writing broad software licensing terms that can’t be fully enforced, just to scare competitors.

    The only way to tell for sure is to boldly release a product and back it up with a potential legal fight to settle the issue. We’re a startup, so obviously we aren’t willing to budget that kind of cost, but if Adobe is willing to throw expensive lawyers at the problem, then more power to them. Everybody wins!

    Reply
  3. Andrew Morton

    So, in your opinion, is less dangerous to include a runtime like LUA than an attached projector like Flash? Keep in mind, that the situation with “Package for iPhone” feature of Flash CS5 is slightly different than what happen on desktop when you package the SWF file together with Player; on the iPhone the player is somewhat half-compiled and is attached to a llvm compiled version of the AS3 code originally compiled on the file. Adobe has already said that it will not be possible to load external SWFs containing code (or better, it will be possible to load the assets but not the code), so in this regard they are perfectly complaint.

    Not sure why you are writing this, but sounds a lot like a cheap shot on your ex-colleagues (especially your disclaimer); if you feel in danger because your product is in direct competition with this particular feature of Flash CS5, you can change/enhance it in a way that allow developers to perform operations not available on the compiled iPhone app.

    Reply
  4. Evan

    Hi, Andrew. The disclaimer was supposed to be a humorously over-the-top sales pitch; we’ll actually be in different market segments than Flash. Also, we hang out with Adobe people all the time, we’re not in any kind of spat with them. (I think Adobe Marketing may be glossing over some issues, but that’s every engineer’s complaint about marketing.)

    I think the interesting argument is whether Apple can nail Adobe on a technicality over the Windows build process itself: Apple claims that both the app-signing procedure and the digital certificates issued by Apple are part of their “SDK” and therefore subject to the Mac-only restriction. This was just armchair legal theorizing on my part, until InformationWeek phoned a couple of lawyers who said that I’m probably right; apparently there’s a legal precedent involving Blizzard/WoW (see http://www.informationweek.com/news/software/linux/showArticle.jhtml?articleID=224000202 ).

    That’s intriguing, but it really just puts the ball in Apple’s court. Would they rather sell a few more Macs to developers, or more iPhones to everybody else by encouraging the maximum possible amount of app development? One theory about Apple is that they care more about selling iPhones than Macs these days, since the iPhone hardware profit margin is insanely high; this may be Adobe’s working assumption. On the other hand, Jobs seems to take some things personally, and we don’t know whether a Windows-based iPhone toolchain is one of those things.

    But the best case is that Apple decides to quietly stand down. Which, like I said, would be awesome, because it enlarges the market for everybody.

    Reply
  5. Scott Janousek

    Possible outcomes as I see them:

    1. Ignore (most likely)
    2. Flash CS5 only has iPhone Packager for Mac, not Windows (possible)
    3. Apple plays real hardball with all the nitty gritty legal details of the agreement, causing Adobe much pain and frustration with deploying Flash CS5 as they originally planned (not likely).

    Reply
  6. Evan

    Hi, Scott. Agreed — I would also bet on scenario #1 (ignore, even if in violation).

    But I’m much happier to test that theory using Adobe’s money rather than Ansca’s :)

    Reply
  7. Guilhem Ensuque

    Hi all, coming late to the party with my 2 grains of salt …

    In short, I think your story has a heavy dose of FUD in it.

    If my understanding is correct, developers don’t need to agree to the iPhone SDK Agreement to get digital certificates and provisioning profiles, and the codesign utility is open source. Adobe (and others) have just ported it to Windows. And it’s legally clean.

    Maybe you could get your or Information Week’s lawyers to chew on my long explanations below ?

    Also remember that Apple are total masters of their own ecosystem, so if they want to block Flash-created apps (or any apps created with 3rd-party SDKs for that matter), then they can do so at the flick of a switch without notice. So the legal stuff doesn’t really matter …

    So far they haven’t done so (and I guess will never do) since the more apps there are in the App Store and the more people buy and download them to their iphones, then the less likely they are to switch to another phone when their operator contract expires.

    Remember Apple makes most of their money by selling hardware. Apps and music are just a minute proportion of their revenue and just here top create stickyness with end-users.

    /Guilhem

    Here is the long version of why Adobe (and others) are clean from a legal standpoint.

    A bit of background first:

    To become an iPhone developer, one must abide to 3 legal agreements:

    1- Apple Registered Developer Agreement: with this, you get access to the generic developer portal. No provision in this agreement restricts you to using Mac as a dev host.

    2- iPhone Developer Program License Agreement: with this you get access to the iPhone-specific developer portal. If you agree to pay USD99 / year you then get the ability to generate developer certificates and provisioning profiles on your Mac or PC from the browser.

    There is one “touchy” sentence in clause 2.6 of this agreement (“No other permitted uses clause”):

    “You agree not to install, use or run the SDK on any non-Apple-branded computer”
    But that’s just the SDK (see also point 3 below) and does not cover the provisioning profiles and certificates covered by the broader “Apple Software” definition in the preamble of the agreement.

    3- iPhone SDK Agreement : this is the one referred to in this blog article. It restricts the usage of Apple’s xCode toolset for iPhone (“SDK”) to Macs only. Fair enough. You still can get your digital certificates and provisioning profile with no restriction from step 2 above.

    Now for the code signing part …

    The code signing utility for both MacOS and iPhoneOS is called “codesign”.

    codesign is included in xCode, so if you ever download xCode, then you are bound by its Agreement (see 3 above)

    Your post seems to imply that Adobe have had to somehow reverse engineer the “Apple Software” (provisioning profiles/certificates) or “SDK” (xCode) to get code signing to work on Windows.

    And indeed there is a clause in agreement #2 forbidding that.

    The wording of that clause is (I have shortened the legal wording):
    “You may not (…) decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, decrypt, or create derivative works of the Apple Software (…) (except (…) to the extent as may be permitted by licensing terms governing use of open-sourced components …).”

    It just happens that there is an open source version of codesign made available as part of the Darwin project:
    http://www.opensource.apple.com/source/libsecurity_codesigning/libsecurity_codesigning-36924/

    The opensource version of codesign is covered by the Apple Public Source License (APSL):
    http://www.opensource.apple.com/source/libsecurity_codesigning/libsecurity_codesigning-36924/

    And the opensource version of codesign is compatible with the App Store certification infrastructure …

    In my opinion (disclaimer: I am not a lawyer), nothing then restricts from making a port of the opensource version of codesign to Windows and then using the digital certificates and provisioning profiles acquired through step 2 above on Windows. :)

    Just to be on the safe side, I bet that Adobe has taken some clean-room precautions to make sure that their devs who ported codesign on Windows never actually approached the iPhone SDK, not even with a 10-foot pole.

    Note also that other mobile applications tools providers are currently providing .ipa signing on Windows, or are planning to do so in the near future (like us at OpenPlug – http://developer.openplug.com).

    We’ll then just wait for Adobe to release CS5 and kindly ask them for the source code as per the APSL, it will save us some work ;)

    Reply
  8. Evan

    Hello, Guilhem. It is sort of impolite to accuse me of FUD while using our comments to plug your own product! (Just kidding :)

    Seriously, best wishes for Openplug, it looks like a cool product. Like you say, we all benefit if Adobe wins this one.

    The bottom line is in step 2 of your argument. Apple DOES seem to consider the “digital certificates and provisioning profile” as part of their “SDK”, even though they aren’t part of the literal SDK download as you or I would use that word. I’m not defending Apple here, and we don’t know yet whether their view is enforceable. (I actually think this originated as anti-Hackintosh language, but who knows.)

    P.S., since I wrote the original post, Adobe finally announced a CS5 preview for April 12 and a ship date sometime in May, so we’ll know a lot more in about 8 weeks!

    Reply
  9. Jay Jagpal

    as far as I can see it’s also in the best interest of Apple to let you use Adobe products to develop your app.

    Firstly, xCode is shipped with all macs. Therefore a nominal profit is made by developing the IDE.
    If someone else has gone and done all the hard work to build one that works, why would Apple say no?

    Anybody with CS5 will want to have a go. I’m a Flash developer, I want a go. Therefore I need to buy myself an iPhone.

    Those with the older iPhones will upgrade.

    Then of course – all of use need a Developer Connection – £50 for the year. Multiply that by everyone ‘just having a go’

    More Apps – More stuff to advertise, More stuff to look at – More people buying – More money made in the App store.

    There definitely going to let it happen – because as soon as I get CS5, I’m handing over £400 to Apple.

    Reply
  10. Lane

    I don’t think Apple could afford to ignore the issue because if Apple does it opens the flood gates to very (very) serious issues because it sets a serious precedent. Ignoring this violation of it’s developer agreement would basically void any legal precedent that might help Apple against any current and/or future violations and give tacit approval to any violation of any similar agreements.

    In other words, if Adobe breaking their developer agreement is OK, then Apple would have a hard time defending against a copy of the iPhone OS running on the Andriod, or Dell selling an Inspiron with Mac OS X instead of Windows.

    Like the author, I’m no lawyer but this seems like a very dangerous thing for Apple to ignore.

    Reply
  11. Guilhem Ensuque

    Hi Evan

    Thanks for letting my lengthy comment through :) and apologies if I upset you.

    I don’t want to bore your readers with legal nitty-gritty, but I have to disagree on your interpretation of the “SDK” definition covering certificates and provisioning profiles.

    Here is a copy / paste of some of the Definitions in the “1.2 Definitions” clause in the IPhone Developer Program License Agreement:

    “”Apple Software” collectively means: (a) the SDK, (b) the iPhone OS, and (c) the Provisioning Profiles, and includes any Updates to any of the foregoing that may be provided to You by Apple.”

    “”Provisioning Profiles” means the provisioning profiles provided by Apple for use by You in connection with Your Application development and testing, and limited distribution of Your Applications for use on Registered Devices.”

    “”SDK” (Software Development Kit) means the Documentation, software (source code and object code), applications, sample code, simulator, tools, libraries, APIs, data, files, and materials provided by Apple for use by You in connection with Your Application development, and includes any Updates that may be provided by Apple to You pursuant to this Agreement.”

    To me, the fact that these Apple definitions make it clear that “SDK” and “Provisioning Profiles” are two distinct things.

    Then, clause “2.6 No Other Permitted Uses” states verbatim:
    “You agree not to install, use or run the SDK on any non-Apple-branded computer, not to install, use or run the iPhone OS and Provisioning Profiles on or in connection with devices other than iPhone OS Products, or to enable others to do so.”

    It’s clear to me that the Mac-only restriction applies *only* to the SDK, not the Provisioning Profiles.

    Finally there is a clause “5. Digital Signing of Applications; Restrictions on Certificates” that says nothing about signing being restricted to Apple-only computers.

    That’s why I think Adobe and others are clean.

    Anyway, time will tell… lets’ see what happens on April 12th

    Reply
  12. Evan

    No worries, Guilhem! It looks like WordPress auto-approves previous commenters, so now you can post here in realtime :)

    Reply
  13. Alessandro

    Ciao Evan,

    long time and great work on Corona.
    My opinion is simple, it’s about math.
    If Apple projections on hardware outcome the apps sale margins, they will enforce the T&C otherwise they do not care!
    In other words, if Apple think that more developers will create content on Apple hardware then they will enforce the legal agreements, otherwise they will allow Windows based developed apps.

    Alessandro

    Reply
  14. Evan

    Hi, Alessandro! Long time no see!

    I think your opinion here is correct. (And I’ll email you, we should catch up!)

    Reply
  15. Lee G

    Point 5 in the iPhone Developer Agreement is speaking to the distribution of certificates. Adobe is not providing their certificate, as a Flash iPhone Developer you MUST still get your own, personal certificates from Adobe.

    This debate is just a fluffy plug for your product. =) Its amazing what people will do to get attention nowadays. While I don’t think it is necessarily the way I would do it, I would imagine it has been fairly effective for you.

    Cheers,
    Lee

    Reply
  16. Evan

    Right, it’s the personal certificates that ARE the problem, if there is one.

    However, see Guihem’s comments above for an interesting counter-argument. I also noticed that Openplug has just announced iPhone app-signing on Windows: http://bit.ly/amad8J . Everybody into the pool!!

    Reply
  17. tof

    As far as I can see, the SDK must run on a “Apple-branded computer”, it says nothing about the OS. So it should be fine to run it on an Imac under Windows 7 (using bootcamp) ?

    Reply
  18. Guilhem Ensuque

    @Evan:
    Just a precision since you mentioned it: we have not announced app *signing* on Windows in our beta4 version, but only app *building* for test & development purposes.
    For signing and distribution, you will still need to use a Mac, or wait for our next release ;)

    Reply
  19. Guilhem Ensuque

    Ok so today apple changed the wording of the iPhone developer program license agreement coinciding with the announcement of iPhone OS 4.0, and we have our answers… the whole discussion above was moot: apple is now banning all apps not originally coded in objective C, C or C++ or JavaScript executed by apple’s safari own webkit engine.

    Clearly Adobe CS5 is now violating Aple’s terms… but not for the reasons we discussed. Funny twist of life.

    As for others like Ansca’s Corona or OpenPlug, well … I need to call a lawyer :)

    Reply
  20. michaelvk

    In other words, if Apple think that more developers will create content on Apple hardware then they will enforce the legal agreements, otherwise they will allow Windows based developed apps.

    Reply

Leave a Reply

  • (Will Not Be Published)