Apple Claims Mogenerator's Methods

[archagon]

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]

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).

[jjmanton]

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.

[numair]

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

[lnanek2]

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.

[Gigablah]

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.

[mikeash]

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.

[andymoe]

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

[comex]

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.

[Alphasite_]

It feels like the only unreasonable party is the author.

[eurleif]

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.

[lnanek2]

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.

[kennywinker]

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`.

[teacup50]

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.

[chrisdevereux]

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?

[pornel]

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.

[mtford]

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...

[tonyarnold]

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).

[mattyohe]

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]

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

[coldtea]

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

[alayne]

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

[nwp90]

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?

[twic]

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]

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?

[badman_ting]

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.

[mwfunk]

Please explain how they're not being nice here.

[seivan]

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

[mwfunk]

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.

[paulgb]

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)

[miweiss]

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.

[stefan_kendall3]

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.

[gress]

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

[andyzweb]

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

[tfinniga]

That would stop apple from using it.

Would probably stop most current users as well.

[tonyarnold]

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.

[lordmatty]

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)?

[pdpi]

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.

[lukegb]

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.