Well-a well-a, what a tangled web we weave when we dabble with proprietary software.
Apple Rejects Mono
Apparently, the Unity engine – which is built on Mono – uses some API calls that Apple disapproves of, cause apps to be rejected left and right.
Here’s the story on Touch Arcade, and here’s a thread on the Unity forums about it.
Part of the problem is because the Unity engine appears to allow some naughty behavior:
Storm8, developers of iMobsters and Vampires Live were recently accused of harvesting players phone numbers using private API’s and uploading them to their servers– A gross violation of the iPhone developer SDK agreement. The Unity engine currently uses the two private API calls that Storm8 allegedly exploited to steal user data, _NSGetEnviron and exc_server.
Moonlight Marching Orders
Look for ever more of this sort of thing as Team Mono attempts to expand Mono and Moonlight. Team Mono is already getting marching orders to start pushing Moonlight harder, the first plan being a video editor.
A video editor is a beautiful infection vector for Moonlight, because:
- Moonlight itself only safe to use for direct Novell customers,
- All those nice proprietary video codecs that Novell has licensed from Microsoft are only safe for direct Novell customers as well.
So, Novell sees a great opportunity to spread Moonlight and the fruits of its Microsoft collaboration, while pretending to develop a “Linux” application.
So long as your “Linux” comes directly via Microsoft-approved Novell-only channels, of course – other Linux flavors need not apply – or redistribute.
#1 by Julian on November 16th, 2009
On the first: Am I the only one missing how this has anything to do with Mono? The fact that Mono was used here seems about as relevant as the fact that “Mono” and “iPhone” both have the letters ‘n’ and ‘o’ in them. Not to mention that to say that Unity is “built on Mono” is more than slightly inaccurate.
On the second: Would you like fries with your tinfoil hat?
#2 by Jason on November 17th, 2009
Julian,
On the first
The Unity game engine uses Mono and according the thread on the Unity forums the APIs are:
So it has something to do with Mono beyond the letters in the name.
According to Unity the scripting is built “on” Mono and Mono is used to extend Unity. Quibble with the phrasing as much as you like, Unity uses Mono extensively.
On the second
There is no question that Microsoft’s so-called “covenant” on Moonlight only applies to Linux so long as it come directly from Novell and no other Linux distribution.
Furthermore, the so-called “covenant” does not cover future versions of Moonlight or Silverlight and explictly excludes GPLv3:
Furthermore, the so-called “covenant” expires in less than two years:
My understanding of the media codecs that Moonlight/Silverlight needs is based on Miguel de Icaza’s own words:
So, you can compile yourself (but not redistribute safely under the covenant – that’s a technical solution, but not a realistic one.
Or, you can use Microsoft binary codecs with whatever restrictions Microsoft chooses to implement, which are at least:
There may be other restrictions on the codecs – there’s not much point in looking beyond the above I’d say.
HOWEVER, if you can show how a video editing solution built in Moonlight would NOT rely on some closed binary codecs, each end-user compiling code or direct distribution only from Microsoft-approved Novell, then I would be glad to follow your explanation. Personally, I don’t cotton much to the idea of Microsoft dictating what flavor of Linux I can use.
Or, as an alternative, if you could explain exactly why anyone that cares about FLOSS would think all that above Moonlight covenant garbage is even worth bothering with. What exactly is so attractive about Silverlight that people professing to place freedom as some sort of interest would even bother with something under such requirements? That’s a very interesting point to me.
In summary you can call it “tinfoil hat” if you like, but it seems to me that Novell and Mr. de Icaza continue to seek out ways to make Linux more dependant on Microsoft, rather than more independent. I think that of all possible application spaces, it is strange that Novell and Team Mono continue to “coincidentally” target such areas.
#3 by Richard on November 17th, 2009
Jason,
I think that what the Julian is trying to say is that this section of your article:
… is incorrect. Sure, it may use those calls internally. Unless it publishes them externally, it certainly does NOT “allow some naughty behavior”. Are they part of the Unity API? We don’t know.
I doubt that this sentence:
… is entirely accurate, either. The approval process is effectively a crap-shoot: there are hundreds (perhaps thousands, now?) of articles that bemoan the near-arbitrary nature of Apple’s decisions. These days, it seems just as sensible to blame the alignment of Mars and Neptune as to blame the framework you’re using…
By the way, have you heard the excellent news? Just out today, the .Net Micro Framework is being open-sourced (under Apache 2.0)! Even though I don’t do embedded system development, I’m quite excited by the thought of what the community can use it for. And Don Syme is heading towards releasing the F# PowerPack, and other parts of F#, under a permissive license — perhaps MsPL, or even BSD! Announcements like these are like early Christmas presents
.
#4 by Jason on November 17th, 2009
Richard,
This was the specific reason given by Apple for rejection, and in fact, Unity has claimed to remove any calls to those private functions in order to solve the problem. So, bringing up how arbitrary Apple might be in other cases is not relevant here – this case was not arbitrary, it was specifically given by Apple and responded to by Unity. In fact, it was the abuse of another company using similar private API calls that caused Apple to tighten its enforcement of existing rules. There is not one single thing arbitrary about the rejections. This is what a rejection from Apple looked like:
This is clearly documented in the Touch Arcade story, on the Unity Community Forums, and even the official Unity blog. Why do people insist on quibbling or flatly denying reality?
No. It appears that Unity APIs in turn called private functions – something they did not need to do, nor should have done. This certainly COULD allow naughty behavior. We know this was a part of the Unity API, because Unity admitted it was so.
In any case, I sincerly doubt there is any possible way I could summarize the news without pedantic and pointless uninformed challenges.
AAAAnyway, as for the .NET Micro Framework, yes I’ve read the news. I almost made a post about it, but I’ll put my thoughts here since you brought it up.
In the roughest terms: I like to see any project be open sourced. Each concession Microsoft makes I consider good, because it both reinforces Open Source as the preferred choice and hastens the decline of Microsoft’s influence. Both are powerful wins for users.
It’s also funny to me that Microsoft can not release the TCP/IP stack in the .NET Micro Framework because of its restrictive license, especially in the context that Microsoft used to use a BSD-licensed TCP/IP stack in its flagship Windows OS code!
It makes me ponder what would happen if Microsoft went whole hog and open-sourced the .NET Framework proper (or as much of it as they legally could). I think an open-source .NET would kill Mono, which puts Mono in a strange position, philosophically speaking.
As far as your interesting wording about “the thought of what the community can use it for”; I suspect that all depends on how you define “the community”. Outside of Novell, and maybe 1-2 steps removed, I don’t see Mono being used for much. I doubt that community will do much with .NET Micro Framework.
I’m far more interested in Go in the context of Open Source tools being championed by large corporations.
#5 by Richard on November 17th, 2009
Jason,
IMHO, it’s arbitrary, and in your opinion, it’s not. I think you could stand to talk to a few people who’ve had their apps rejected, though. You’d be surprised at the sheer frustration that comes of knowing that other apps — or ever previous versions of your OWN apps! — use X functionality, but now (because they’re “tightening” regulations, or because Venus isn’t aligned, or because Jobs’ feng shui is out-of-kilter) it’s not OK. In 3 months’ (or 2 weeks’) time, it might be OK again, or maybe it will be OK for your direct competitor, but certainly not for you. Or it will be OK as long as you change the background-color, or load exactly the same image via a plain-HTTP webpage rather than via a JSON-using request to the webpage.
But on to matters that are technical, and not subjective…
Nope. If I build a framework that calls NaughtyFunction7(), and take the GUID or string that it gives me, and correlate that with something else so that I can return “true” or “false” through my API function ICanHasCheezburger(), how could that possibly allow for any sort of naughty behaviour?
But the point is moot. Unity has removed the problem, and it’ll now be up to Apple to reject the app on other grounds (maybe the logo that is used has a flat edge, and it should be rounded — oh horror!).