[R] R on the iPhone/iPad? Not so much....a GPL violation

[Marc Schwartz]

Ken,

See comments inline.

On Jun 1, 2010, at 2:25 PM, Ken Williams wrote:

> Hi Marc,
> 
> I want to debate a couple points from your post:
> 
>> 1. Distribution of GPL covered applications is not permissible via the App
> 
>> Store due to the Apple Terms of Service language, which infringes upon
> rights
>> granted under the GPL.
>> 
>> 'Nuff said.
> 
> I'm not sure I agree with this, but there's so much wiggle room in
> interpreting what the GPL means that there would probably be no way to
> decide without a courtroom & judge, so I'll leave this part alone. =)  I
> also haven't yet read your other post where you discuss this.


Please do, including the links therein. It's not my interpretation, it is the FSF's action and Apple's response to that action, which sets at least an operational precedence, if not one that could also affect any future litigation pertaining to GPL'd apps in the App Store. That all just took place within the past week or so, which is what prompted my initial post on the matter, since it would be relevant to any R offering via that channel.


>> 3.3.1    Applications may only use Documented APIs in the manner
> prescribed by
>> Apple and must not use or call any private APIs.
> 
> I believe that language only refers to *Apple's* APIs.  In other words, they
> don't want you to call hidden functions that aren't supposed to be exposed
> to developers.  If it meant no use of any APIs private to the developer, it
> would rule out pretty much every application in existence, considering that
> a call from one function to any other is an API call.


I am not in disagreement on that point. The key issue to date has been the lack of a compatible FORTRAN compiler, at least off the shelf, based upon what I can tell. Arguably, that is at least a notable deterrent to use FORTRAN on the iPhone for now.

There are other programming language tools for current iPhone development, but nothing for FORTRAN that I can find.

I can find no references to anyone building iPhone apps using FORTRAN (even in part) and the few queries that I can find that even mention an interest in doing so, reference the same issues that I have. Some have referenced f2c, but it is not clear to me that such an approach would work for R, not to mention the development overhead and the extensive testing of any conversion of critical functionality.

That all changes with the new language in 4.x.


>> However, the beta release of the 4.x version of the iPhone SDK has the
>> following language in the same section:
>> 
>> 3.3.1 ˜ Applications may only use Documented APIs in the manner prescribed
> by
>> Apple and must not use or call any private APIs. Applications must be
>> originally written in Objective-C, C, C++, or JavaScript as executed by
> the
>> iPhone OS WebKit engine, and only code written in C, C++, and Objective-C
> may
>> compile and directly link against the Documented APIs (e.g., Applications
> that
>> link to Documented APIs through an intermediary translation or
> compatibility
>> layer or tool are prohibited).
> 
> Here again I believe the "private" API language refers to
> unsanctioned-but-exposed pieces of Apple's platform that you're not supposed
> to touch.  The language restrictions I interpret to mean that if you call
> their Official API hooks, you must do it from one of the Official Languages.
> 
> However, FORTRAN code will never call Apple's API hooks, it just does its
> little matrixy/FFT/etc. stuff and returns the results.  In the call stack,
> FORTRAN is always a dead end.  It doesn't call Apple's APIs, and it doesn't
> call a translation layer that calls Apple's APIs.  So again, R may be in the
> clear here, under this interpretation.
> 
> Note that Java & Flash applications, under this interpretation, are *NOT* in
> the clear, because they do call GUI APIs (among others).


The key wording change relevant to R (and of course for other iPhone developers and tool providers) in 4.x is:

"Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine"

Ignore the other wording pertaining to API's and other layers for the time being.

The app must be written natively in one of those four languages. There appears to be no interpretation that I can find that differentiates a scenario where a library of low level functions, written in a language such as FORTRAN, may be called from a higher level language such as those listed above.

Unless there is some subtlety in differentiating the abstraction layers within which the application is executed on the iPhone, I see no recourse here.

Note that the entities that provide iPhone cross-compilation/framework tools (eg. MonoTouch, Titanium, unity3D, Rhodes, etc.) which convert other code directly to native iPhone apps are also trying to figure out where they stand. Similarly, folks who develop natively in other languages are also having headaches over the new SDK wording.

There is even a question relevant to cross-compilation tools that take another language and convert it to, for example, Obj-C, as an intermediate step, before subsequent compilation to an iPhone native binary.

So the message that everyone is coming away with is, if you want to develop for the iPhone, write your code using one of these four languages, period. No doubt, some folks will test the boundaries and we will get more definitive answers in time.

Is it possible that the SDK language will change before 4.x is released as a stable OS/SDK? Sure, but that does not seem likely.


>> 3.3.2    An Application may not itself install or launch other executable
> code
>> by any means, including without limitation through the use of a plug-in
>> architecture, calling other frameworks, other APIs or otherwise. No
>> interpreted code may be downloaded or used in an Application except for
> code
>> that is interpreted and run by Apple's Documented APIs and built-in
>> interpreter(s).
> 
> I think this indeed pretty effectively rules out installation of packages
> from CRAN, which is a bummer - unless those modules are downloaded &
> installed through the app store.  Not sure if that would even work though,
> since they're not apps.


As I note, between 3.3.2 and 3.3.3, any add-on functionality, such as CRAN packages, would be problematic any way you read it.


> As for the "interpreted code" stuff, there's so much murkiness about what
> constitutes interpreted code that I don't know if this is a deal-breaker or
> not.  At one extreme, it could prohibit pressing buttons in an app and then
> "interpreting" those presses as commands for the app to "do something."  At
> the other extreme,  Somewhere in the middle, it would seem to cover language
> translation apps.  The notion of "interpreted" is just not very
> well-defined.  For instance, most people think of Perl as an interpreted
> language, but it compiles to bytecode before executing just like Java (it
> just doesn't typically save it to a bytecode file).


I would say that, beyond the SDK language parsing issues relevant to interpreters, given that Apple rejected BasicMatrix and that there are no other programming language interpreters in the App Store, these are pretty goods sign that R would not pass Apple's review under these parameters. I take a fairly pragmatic approach there.


> Finally, I do agree with the general tone implied in your post - it is a
> major major hassle that Apple's overlords control the distribution channel
> for software on non-jailbroken iDevices.  I don't like it at all, for the
> exact reason that people like you & me & the rest of the world now have to
> sit around speculating whether our helpful apps will pass muster with the
> cabal.


As I noted in my closing comments in my second post, if one has a desire to make R's functionality available on smartphones (iPhone, Android, etc.) or iPad-class devices, then a client/server approach may be the most efficient means to do so. That approach also avails you of more powerful computing platforms than the client side mobile devices have, at least at present, which will also limit aspects of portable functionality.

Regards,

Marc