Subscribe to
Posts
Comments
NSLog(); Header Image

Rogue Amoeba on the App Store Process

I like this comment from Lars the best:

The public API you are referring to is a Mac OS X API. You assert that it is alright to transfer the image provided by that API to another device and display it there. This may or may not be the case but in my opinion, you argument could be a non sequitur. Just because one system provides you the means of getting a certain bitmap does not automatically entitle you to use that bitmap somewhere else.

I think you should be allowed to use it and as a fellow developer I dislike the AppStore model as much as the next person. Nevertheless, your argument isn’t really logically sound here as far as I’m concerned.

I think Rogue Amoeba shouldn't have bothered to mention that "1.0 was approved." So you slipped one by the cops - so what? The speeding analogy Jeff mentioned applies here: just because you get away with something once doesn't mean you are granted a free pass to get away with it forever.

I think that under the letter of the law, Rogue Amoeba is/was using the images "illegally" right now. It doesn't matter how the images get on the device, to the user they're "part" of the application and the fact that they're allowed on the Mac OS X API doesn't automatically grant the right to their use on the iPhone.

That argument that an image is being accessed through a public API is similar to this one: I have a photoblog. Imagine if, using public APIs and the HTTP protocol, Rogue Amoeba were to use my images in their application? Clearly by publishing I've allowed them to be transmitted via http… but presenting the image as your own and without the context of my URL or the rest of my site would violate my rights.

All of that said, I think Apple should allow, on a case-by-case basis, the use of such images. Or drastically overhaul the approval process or ditch it altogether.

8 Responses to "Rogue Amoeba on the App Store Process"

  1. "under the letter of the law" -- what law?

    The SDK agreement doesn't specifically prohibit this. The Mac OS X APIs return an NSImage -- a structure ready to draw. If this doesn't act as permission to use the images in your applications, I don't know why they would expose the API.

    It does matter how the image gets on the device. If RA was distributing the content as part of the application, you could argue that they are hosting copyrighted material without permission. By transferring the information on demand, it acts like most websites by essentially hotlinking to the source, providing a safe harbor exception.

    If the SDK specifically said, "You cannot contain any depiction of any Apple devices," then I would agree with you. But it doesn't deal in specifics.

    And that's the problem with the SDK and approval process. It's a dice roll, and you never know what's going to happen.

    1. "The Mac OS X APIs return an NSImage"

      What the heck does this have to do with image copyright and fair use on the iPhone?

      If the app is using Apple copyrighted images _and_ fair use does not apply then it shouldn't be using them. It doesn't matter how they end up on the device.

      IANAL and I don't know if fair use applies. I would like to say yes, but I really don't know (Gruber thinks yes).

      Really they need to get a lawyer to look at the agreement, their use of icons and then sort it out legally.

  2. Erik: You're missing the point. Their emphasis isn't on the "this is an NSImage" part, their emphasis is on the "Mac OS X contains a named image that returns a depiction of your device, and contains a method to return the icon of an application, which means that to the extent that we can't ship something with that included in our iPhone application, we should be able to show it if transmitted to us by a companion application" part.

    But yes on the ditching.

  3. Jesper said on November 14, 2009:

    Erik: You're missing the point. Their emphasis isn't on the "this is an NSImage" part, their emphasis is on the "Mac OS X contains a named image that returns a depiction of your device, and contains a method to return the icon of an application, which means that to the extent that we can't ship something with that included in our iPhone application, we should be able to show it if transmitted to us by a companion application" part.

    Why have two people focused on "this is an NSImage"? I didn't use the word "NSImage" in my post at all. What's the point of saying "it's an NSImage" when the actual NSImages in question are copyrighted to Apple.

    Jesper, I think it's you has missed the point. The existence and of an API on one platform (desktop computers) doesn't grant you the right to use the results on another platform (the iPhone/iPod Touch).

    Rogue Amoeba knowingly withheld an update from their customers because they hoped "I got away with it once, so…" would apply. Apple's not blameless here either - answers could have been clearer and responses shorter, and like Jonathan I think this might fall under fair use - but the point remains that Paul and RA tried to get away with something that they knew was wrong and are now whining about it.

  4. I'll repeat this part again: "which means that to the extent that we can't ship something with that included in our iPhone application, we should be able to show it if transmitted to us by a companion application". If they can't show that, how do you propose Rogue Amoeba supposedly blacklist such images? If it's a function of their companion app sending those things, then they'd have to change *something else entirely* in order for the iPhone application to be approved.

    If you don't see how those are ridiculous terms -- and if they weren't limited by terms, how could they "try to get away with [that]" -- I can't help you.

    1. "then they'd have to change *something else entirely* in order for the iPhone application to be approved"

      If they downloaded the icons from a 3rd party server they'd need "change something else entirely" also.

      Having to change "something else entirely" is irrelevant.

      Apple is telling RA their app was denied because it used Apple images.

      How RA gets the images into the app is irrelevant. The icon fairy could slip them under the app's pillow at night for all it matters.

      Everyone talking about NSImages, or APIs, or favicons is missing the point. It's isn't about the "how" at all.

      The only thing that seems to matter is if RA can use the copyrighted images as fair use. I have no idea.

      What concerns me is that they received legalese from Apple after they were denied that doesn't seem to be in SDK agreement. It sounds like Apple has a hidden agreement that you can violate without knowing (which is obviously the case - apps can be denied for whatever reason).

      If it is deemed fair use (and only their lawyers should be able to tell them that) and if Apple still doesn't allow the app onto the appstore - then we should get our knickers in a twist.

  5. Jesper said on November 15, 2009:

    I'll repeat this part again

    That's unnecessary. I read it the first time and still disagree. So now I'll basically repeat myself, as you did:

    The API and Apple's licensing may very well allow you to use the image on a Mac. It does not on an iPhone.

    That's it.

    Why should an image that's not allowed to be shown on an iPhone magically be allowed if it's transmitted by a desktop application? (Or maybe a server application somewhere?) Why? There's nothing magical - a companion application's legal rights aren't automatically copied over to the fellow other application - and it's stupid to assume they would.

    Again, just because my server serves up my photos doesn't mean someone can embed my photos in their app without my permission. "They're being transmitted by this Apache companion application, so we get to use them too." It doesn't work that way.

    The fact that their companion app is theirs particularly means it's "under their control." Your argument that "they'd have to change *something else entirely*" falls apart by the facts of this case: they didn't change the companion app, they changed the iPhone app. I don't need to change Apache to stop sending my images out via http - anyone stealing my images needs to change their app to stop receiving them.

  6. Reminds me of the problem Delicious Library had where Amazon forced them to remove their iPhone app because it used data which Delicious Library pulled down from Amazon's servers and used without issue in the desktop app. Amazon had no problem with the data being used in a desktop app, but specifically barred its use on mobile devices. And that was that.


Trackback URI | Comments RSS

Leave a Reply

Please abide by the comment policy. Valid HTML includes: <blockquote><p>, <em>, <strong>, <ul>, <ol>, and <a href>. Please use the "Quote Me" functionality to quote comments.