Hi all, Thanks to an offlist e-mail from Thomas (Lumley), I have spent the past few days getting a bit more edumacated on additional restrictions on the opportunity for R to appear on the iPhone/iPad. These in fact go well beyond the GPL issue that I raised in my initial post, which in and of itself, is not trivial by any means. I now know, or at least think I know, more about these issues than I probably wanted, but I also want to present a better picture of the situation.
Note that I am not a lawyer and am not intending to represent my findings from a legal perspective. I am reporting them here using a common sense approach from my own reading of the relevant Apple iPhone SDK language, as well as being based upon specific examples and discussions that I located on the web. So, in summary, here are the key issues. I will follow each with some additional details below, but note that all such restrictions would need to be removed or otherwise overcome, before R could in fact appear on these two platforms, at least through Apple approved means in the App Store. 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. 2. The use of FORTRAN is precluded (explicitly from SDK version 4.x forward) Version 3.x of the iPhone SDK has the following language: 3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Apple of course does not offer a FORTRAN compiler, as those who build R from source on OSX, as I do, are keenly aware. Thanks to Simon, we have one to use for OSX, but one is not officially available for the iPhone/iPad in the SDK. Note that there is an important distinction here. The ability to build R versus the ability to have the resultant application pass Apple's review to be able to appear in the App Store. The above language has also been interpreted to apply to Java/Flash, precluding those environments from appearing on the iPhone/iPad. 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). Thus, in fact, one can only use Objective-C, C, C++ or JavaScript to develop applications for the iPhone/iPad. No FORTRAN, upon which of course, R is dependent. The above language has also been interpreted to further reinforce restrictions specifically on Java/Flash. 3. The implementation of programming language interpreters, of which R is one, is precluded. The following language appears in version 3.x of the iPhone SDK: 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). The above language has been (pardon the pun) interpreted to restrict the implementation of programming language interpreters on these devices. Some sites I found have narrowly focused on the "No interpreted code may be downloaded" part of the language as an "out" of sorts. However, upon review, they seem to ignore the "or used" wording, which would seem to be independent of the action of downloading. If the language was "and used", then one could envision the use of locally stored or entered code, but this is not the case. In either case, of course, R would not be one of Apple's "built-in" interpreters. I found two interesting examples of how Apple has either approved or rejected applications that can be considered interpreters. It is not clear where Apple drew the line between these two, such that it might enable one to better differentiate the reasoning and therefore design an app that would pass muster with them. Thus, one complication may be Apple's lack of internal consistency in making decisions on allowing or disallowing apps in the App Store. The first is an application which was intended to be a BASIC interpreter on the iPhone and which was apparently rejected by Apple under the name BasicMatrix: http://smartcalc.coollittlethings.com/?p=3 After the author substantially restricted the functionality of the application to being an "enhanced calculator" under the name "SmartCalc", Apple approved the application. However, a contrarian example is "Frotz" which is a game type of an application currently available at no cost in the App Store for both the iPhone and the iPad. It is in fact an interpreter of so-called "Z code" (http://en.wikipedia.org/wiki/Z-machine) to create interactive fiction adventures. The web page for the app is: http://code.google.com/p/iphonefrotz/wiki/FrotzMain The app was initially accepted by Apple. A later version however was rejected, because the updated version could download new game files (Z code files) via the internet. Once the author removed the download functionality, Apple accepted the updated version of the app. Frotz is also a GPL'd application, so its longevity in the App Store is logically in question and I sent an e-mail to the author to be sure that he was aware of the FSF's recent actions. The additional implications for R here, vis-a-vis Frotz, would be the ability to download, install and use CRAN packages. I will touch on this issue again below. 4. The implementation of anything resembling the CRAN network, to facilitate add-on packages for R, would be highly problematic for multiple reasons. The following language appears in version 3.x of the iPhone SDK 3.3.3 Without Apple’s prior written approval, an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store. For those who have an iPhone/iPad and are familiar with so-called "In App" purchases, this refers to the mechanism approved by Apple to provide add-on functionality to already installed applications. The notion of In App purchases is somewhat misleading, as in fact the activity may involve no actual direct monetary cost to download the additional component(s). Thus, arguably between the SDK language, which would preclude a CRAN type network unless approved by Apple, combined with the relevant language I reference from 3.3.2 above, there would be substantive restrictions on the ability of a "default" R installation from being able to download and utilize add-on R packages. Further, since one cannot compile programs on the iPhone/iPad, there would have to be some means to pre-compile any add-on packages for R on these two platforms, similar to what is done for Windows and OSX presently on CRAN to create package binaries. Further, packages that use FORTRAN, tcl/tk, Java, Perl or other such libraries would of course, also be problematic, both from a functional and where appropriate, a GPL perspective. Even if one got by some of those issues and pre-compiled add-on packages were to be made available via some distribution process, the entire process of R package installation, updating and management would have to be re-written specifically for these platforms. Thus, there would be a meaningful amount of development work that some group of folks would have to undertake. That all being said, it is clear that a remote client/server implementation of R would be possible, as long as the client-side R GUI application on the iPhone/iPad meets Apple's requirements. Anyone using the WolframAlpha app ($1.99 U.S.) on the iPhone or iPad (I do on the former) will understand this model. See http://products.wolframalpha.com/iphone/ and http://products.wolframalpha.com/ipad/index.html for more information. Somebody just has to be willing to fund the backend server farm to provide the service. :-) Needless to say, a fully browser based client/server implementation would also work and be cross-platform, provided that the input/output web pages are appropriately scaled for the mobile displays. WA also provides a free alternative to their dedicated apps via a mobile site at http://m.wolframalpha.com/ as an example. Similar considerations here, as above, for the backend server platform would be applicable. The key advantage of the dedicated app is a more efficient keyboard layout providing easier access to special character sets, rather than scrolling through them using the default keyboard. I hope that the above is helpful to folks. Needless to say, I do not present the above as being the definitive reference, but it seems to be at least a logical interpretation of the current situation. Regards, Marc schwartz ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
