Apple Claims Mogenerator's Methods

http://rentzsch.tumblr.com/post/82453434093/apple-claims-mogenerators-methods

by chmars • 12 years ago

176 87 12 years ago

rentzsch.tumblr.com

archagon2• 12 years ago

That sucks (but it's also a little funny, I have to admit). Here's an idea: instead of excluding Apple from the license altogether, why not insert a clause to specifically prohibit putting any of the class methods on Apple's non-public selector list?

leoc• 12 years ago

Add specified damages for doing so (be bold! be creative!), and mandate your choice of legal venue (obviously somewhere that the loser usually pays both parties' legal costs, and where it's relatively easy to get lawyers to work on contingency).

bonyt• 12 years ago

In the US, anyway, liquidated damages clauses like this in a contract (licenses are contracts) are only enforced if they are a reasonable estimate of the damages expected for a breach when the actual damages would be hard to calculate. Penalty damages are not enforced.

http://blogs.findlaw.com/law_and_life/2013/05/what-are-liqui...

jjmanton• 12 years ago

I'm not an expert on licensing, but couldn't Apple continue using the current version of mogenerator? A license change would only prevent them from taking latest.

archagon2• 12 years ago

Right, but that would mean that mogenator could change the names of the class methods (or add additional ones) without having to worry that Apple would adopt them in a later update and thus render the whole exercise moot.

lordmatty• 12 years ago

Good thought, but Apple is the gatekeeper here - not sure changing your license will help. What if they continue to use the methods without using Mogenerator (they could easily write their own categories to implement the methods for example)?

lukegb• 12 years ago

That's not the point - the point is to stop them from updating to a new version and blacklisting the new method names. They already have a license that allows them to use the existing code.

pdpi• 12 years ago

Idea is that the next version of mogenerator uses new method names, and that version says "Apple can't use this". Apple has no motivation to change the method names they use to match the new mogenerator if they're not using it, so nobody else is affected.

twic2• 12 years ago

How about putting some distinctive string in the generated method name? Like:

  [MyEntity insertMyEntityInManagedObjectContext:moc];

Yes, it's redundant and crappy. But it's not a disaster and it should avoid the great stamping boot of Apple.

LeoNatan25• 12 years ago

When Apple upgrades their code, they'll have the same "distinctive string" and the cycle continues. Or do you suggest people go in potentially tens or hundreds of classes and change manually the methods and their use?

kennywinker5• 12 years ago

If the entity name is part of the method name, it'll be different so long as you don't overlap entity names with Apple.

It'd be a lot of work for devs to change code that calls those methods, but not so much it's not a possible solution. I'm optimistic someone inside Apple will address this issue on their end, but if that fails this sounds like a possible workable solution.

andymoe• 12 years ago

How about we open a radar? Is there one yet? The engineers who read those are not entirely unreasonable... just really busy.

comex• 12 years ago

Or have the build system check if the SDK name ends in ".internal" and change the name and/or complain if so.

Seriously, adding licensing requirements is silly when most likely the engineers responsible just need to know what's going on.

mwfunk3• 12 years ago

comex's second comment pretty much sums up the whole situation. It's bizarre that anyone even has other ideas at this point.

Alphasite_• 12 years ago

It feels like the only unreasonable party is the author.

Gigablah2• 12 years ago

It feels like shoddy work by Apple engineers, actually. Seriously, making use of an open source library and breaking it (indirectly) for everyone else in the process?

seivan• 12 years ago

I use Mogenerator to just generate the entities. Not actually use the methods.

badman_ting• 12 years ago

I don't see what's so bad about excluding Apple in the license. I mean, they're not really playing nice here. Perhaps unintentionally so, but if that's how they want to carry it then they can write their own thing for the Photo framework.

mwfunk3• 12 years ago

Please explain how they're not being nice here.

kennywinker5• 12 years ago

Effectively banning a commonly used tool from the app store because they use it internally. It's a bit of an "I'm taking your ball and going home" kind of a situation.

andyzweb• 12 years ago

it might be worth looking at using a different kind of license: https://www.gnu.org/copyleft/gpl.html comes to mind.

tfinniga• 12 years ago

That would stop apple from using it.

Would probably stop most current users as well.

tonyarnold5• 12 years ago

mouth fart noise if you use GPL for your code on OS X/iOS, nobody will use it due to earlier issues with submitting GPL apps to the App Stores. Friends don't let friends GPL.

eurleif6• 12 years ago

Unfortunately, licensing restrictions like that would make it incompatible with the GPL. One way around that would be dual licensing: allow people to use either the special MIT-but-no-Apple license, or the GPL. Presumably Apple wouldn't touch the GPL option.

lnanek22• 12 years ago

Why do you think the GPL matters? This is MIT licensed and the GPL is incompatible with the app store anyway, so no one can use it. See the removal of VLC.

eurleif6• 12 years ago

the GPL is incompatible with the app store anyway

This project works on OS X, not just iOS.

kennywinker5• 12 years ago

How about a license that was "MIT, unless you're Apple in which case it's GPL"? Wouldn't that be compatible with the GPL? You would be effectively barring Apple from using it, as they won't use GPL code inside `PhotoLibraryServices.framework`.

eurleif6• 12 years ago

IANAL, but I don't think that would be GPL compatible. You're only explicitly allowing Apple to use it under the GPL, not other parties. And even though "unless you're Apple in which case it's the GPL" involves the GPL, it's still a licensing restriction which is not included in the GPL.

teacup504• 12 years ago

Who cares?

The GPL's compatibility clauses are a pain for everyone, and in return the GPL provides nothing to anyone not already using it.

Maybe we should intentionally poison-pill our open source licenses to be GPLv3-incompatible; after all, the GPL is designed to actively leverage network effects to establish monopoly control over how the rest of us share code.

Responding with the same tactics seems fair.

AlexMax• 12 years ago

Responding with the same tactics seems fair.

So you are going to combat the network effects that would establish monopoly control over how people share code by...trying to establish monopoly control over how people share code? Doesn't that seem a wee bit hypocritical to you?

mattyohe• 12 years ago

Eh, while Apple is using it, we have yet to have a rejection due to this. I'll hold my complaints until Apple actually rejects apps.

icambron• 12 years ago

Warnings are problematic enough: https://github.com/magicalpanda/MagicalRecord/commit/723827e...

tonyarnold5• 12 years ago

I decided to roll that commit back — I'm hopeful Apple's going to whitelist the APIs early next week (and honestly, it's an otherwise unnecessary API change).

coldtea3• 12 years ago

Just above you: "miweiss: I've had an app rejected from the selector search the article mentions."

mtford• 12 years ago

Has anyone actually been rejected for this yet? How do we know there isn't a whitelist already? We're submitting in a weeks time - with mogen - so I guess there is only one way to find out...

tonyarnold5• 12 years ago

Nobody is being rejected for this issue — Apple seems to be ignoring it as overzealousness from the validator. It's just a validation warning, but you'd be amazed how upset some developers get about it.

We've had numerous issues filed about it on the MagicalRecord issue tracker (which is what prompted me to hassle Wolf about it in the first place).

stefan_kendall3• 12 years ago

Change the license, exclude apple, and send them a CnD if they use the library going forward.

It's probably faster and more reliable to do this than file a radar.

gress7• 12 years ago

But then it would be the author being hostile and destructive, when this is clearly an accident.

mwfunk3• 12 years ago

I don't understand, what's the problem exactly? Is this against Mogenerator's license (it doesn't appear so)? The article described a hypothetical scenario in which an app using Mogenerator might get incorrectly rejected for using private methods, but there wasn't any evidence that this has or will happen, or if it did happen that it would be anything other than an easily corrected mistake. I must be missing something.

miweiss• 12 years ago

I've had an app rejected from the selector search the article mentions. As the article says though, I'm sure it's within apple's power to ignore them, especially if lots of existing apps use it.

robterrell• 12 years ago

Actually rejected because your app had a MOGenerator selector? Details, please. That adds a lot of information to this story.

paulgb• 12 years ago

I'm not an Objective-C developer but it looks like modgenerator is a code generation tool that (among other things) generates helper methods. Apple used this in one of their own frameworks, which is completely within the license, but the helper methods ended up on a blacklist for apps submitted to the app store. Using APIs on the blacklist apparently won't guarantee that an app gets rejected (if I've learned anything from HN it's that iOS App Store rejections are notoriously inconsistent).

The author of this article (and modgenerator) is (perhaps facetiously) considering changing the license so that Apple can't use it in order that they generate other accessors which are not blacklisted.

(Again, this is all my non-Objective-C-developer understanding, so corrections are appreciated)

nwp90• 12 years ago

Why not just add a means of invoking it such that it generates "special" method names when used by Apple, and (if necessary) use the license to require that they use them?

numair2• 12 years ago

This is a real nuisance, but the author seems to be going about it in the wrong way (which is confusing, because the author is a super-long-time NeXT/Obj-C developer who probably has contacts at Apple to help resolve the issue). I'm subscribed to all of the relevant Apple mailing lists for Cocoa/Obj-C and yet the first I've heard about this issue is through a blog linked on Hacker News; why? Why not have a friendly conversation about Apple regarding their use of open source Obj-C code, and the problems it creates with their method blacklist? The fact that Apple is using mogenerator is a good thing, isn't it?

It seems that an interim solution would be to patch mogenerator to generate a different name/prefix for these methods, with the name set via an option flag or something. If the author would rather wage a religious war with Apple over this, well, time to fork... (And if someone creates such a solution, it'd be great if you could post a link here!)

(Retzsch probably has good reasons, based on past interactions, on why he's going about things this way, but we've got to be pragmatic here.)

EDIT: Since it seems that people aren't familiar with them, here is a link to Apple's mailing lists. Browse the archives and you'll see that Apple engineers do, in fact, read and reply to things on there.

https://lists.apple.com/mailman/listinfo

mikeash5• 12 years ago

Contacts with the app review team are scarce, and they can be obstinate even if you do manage to find somebody to talk to. That whole area is straight out of Kafka.

numair2• 12 years ago

There's the (relatively) micro-scale issue of individual apps being rejected, and the macro-scale issue of Apple utilizing open source projects and putting their methods in their list of private, disallowed method names. This seems like the exact sort of macro-scale issue for which Apple maintains mailing lists viewed by actual engineers.

I just don't see how publicly attacking Apple over this is going to lead to any sort of positive situation, especially for the author and his relationship with people at Apple. Mogenerator is super-useful, but if it's going to be the centerpiece of some sort of political statement regarding Apple's policies, developers such as myself are going to have to look elsewhere to get their work done.

EDIT: I'm sure you already know about these mailing lists...? https://lists.apple.com/mailman/listinfo ... The fact that you guys want to publicly attack Apple over this, while staking your entire careers on developing for Apple's platforms, is insanity. A course on politics is in order.

lnanek22• 12 years ago

You claim otherwise, but it is generally not possible to have a meaningful discussion about why your app is rejected. Even when you do the person you are communicating with is not an engineer, just someone going through a checklist. As someone with some iOS apps out there, my only chance to communicate with an engineer is to go to wwdc.

coob2• 12 years ago

Or raising a DTS issue, of which you get 2 per year as part of your iOS developer account and can buy more.

Gigablah2• 12 years ago

Even if he has contacts at Apple who can resolve the situation for him, according to his tweet (linked at the bottom of the article) he lost an entire afternoon addressing it. I imagine he's really annoyed.

gress7• 12 years ago

He won't be the first person to lose an afternoon dealing with a vendor's bug.

alayne• 12 years ago

This issue makes more sense if you just read the Github thread: https://github.com/magicalpanda/MagicalRecord/pull/74

chrisdevereux4• 12 years ago

So if Apple have a private class with a method called 'invalidate' and I also have a method called 'invalidate', I go on the naugty list?

That sounds crazy. Wouldn't it make sense to keep a list of private classes rather than private selectors?

pornel2• 12 years ago

In Objective-C selectors are not really tied to classes. The runtime doesn't care about classes — it can send any selector to any object.

Cocoa even creates subclasses at runtime and changes classes of existing object instances. It's pretty much as dynamic as JavaScript.

chrisdevereux4• 12 years ago

Sure, but to access a private class, I'd typically need to message the class to obtain an instance. I could obsfucate my access of the class, but equally I could obsfucate obtaining the selector.

The fact that selectors aren't tied to classes is exactly the reason this is so insane, as the example above (and the OP's) show!

Apple Claims Mogenerator's Methods

Related Stories