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…

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.

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

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:

… cannot be posted to the App Store due to the usage of private API. Usage of such non-public API, as outlined in the iPhone Developer Program License Agreement section 3.3.1, is prohibited:

“3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.”

The following non-public APIs are included in your application: _NSGetEnviron
exc_server

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?

Unless it publishes them externally, it certainly does NOT “allow some naughty behavior”. Are they part of the Unity API? We don’t know.

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.

I think that what the Julian is trying to say is that this section of your article:

Part of the problem is because the Unity engine appears to allow some naughty behavior:

… 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:

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.

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

On the first

The Unity game engine uses Mono and according the thread on the Unity forums the APIs are:

used by Mono runtime to provide implementation of .NET core API method: Environment.GetEnvironmentVariable().

exc_server is also used by Mono runtime to provide gracefull NULL reference exception handling.

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.

“Intermediate Recipients” means resellers, recipients, and distributors to the extent they are authorized (directly or indirectly) by Novell or its Subsidiaries to resell, license, supply, distribute or otherwise make available Moonlight Implementations (whether the resale, licensing, supplying, making available, or distribution is on a stand-alone basis, or on an OEM basis as bundled with hardware or other software of the reseller or distributor, or otherwise, so long as it is not bundled with a Linux operating system other than Novell-branded operating system software), except for resellers, recipients, or distributors who are in the business of offering their own branded operating system software.

Furthermore, the so-called “covenant” does not cover future versions of Moonlight or Silverlight and explictly excludes GPLv3:

“Moonlight Implementation” means only those specific portions of Moonlight 1.0 or Moonlight 2 that run only as a plug-in to a browser on a Personal Computer and are not licensed under GPLv3 or a Similar License.

Furthermore, the so-called “covenant” expires in less than two years:

“Term” The term of this Agreement will commence on the Effective Date and continue through September 1, 2011, unless terminated earlier under the Agreement.

My understanding of the media codecs that Moonlight/Silverlight needs is based on Miguel de Icaza’s own words:

Today if you download Moonlight’s source code you can build it with either the ffmpeg codecs or you can let Moonlight fetch the binary Microsoft Media Pack and use Microsoft’s codecs on Linux.

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:

Microsoft will make the codecs for video and audio available to users of Moonlight from their web site. The codecs will be binary codecs, and they will only be licensed for use with Moonlight on a web browser (sorry, those are the rules for the Media codecs[1]).

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.

On the second: Would you like fries with your tinfoil hat?