R help - May 2010 - R on the iPhone/iPad? Not so much....a GPL violation

Hi all,

There have been posts in the past about R being made available for the iPhone
and perhaps more logically now, on the iPad. My recollection is that the hurdle
discussed in the past was primarily a lack of access to a CLI on the
iPhone's variant of OSX, compelling the development of a GUI interface for R
specifically for these devices. R itself, can be successfully compiled with the
iPhone development tools.

Well, now there is another, clearly more profound reason.

The FSF has recently communicated with Apple on the presence of a GPL
application (GNU Go) in the iTunes store because the iTunes TOS infringes upon
the GPL. Apple, given a choice, elected to remove the application, rather than
amending their TOS.

The FSF also informed the developers of the iPhone port of GNU Go that their
distribution is in violation of the GPL. R Core and any others considering an
iPhone/iPad port of R, if you are not already aware, take note...

More information is here:

  http://www.fsf.org/news/2010-05-app-store-compliance/

with an update here:

 
http://www.fsf.org/news/blogs/licensing/more-about-the-app-store-gpl-enforcement

So, until Apple amends their TOS agreement, it looks like there will be no GPL
apps available for the iPhone/iPad, since the only way to make applications
available for these platforms is via the iTunes store (unless you unlock the
device). Hence, no R for these devices in the foreseeable future.

BTW, I am posting this as an FYI, not as a catalyst for a discussion on the
political aspects of this situation. So please, let's not go there...  :-)

Regards,

Marc Schwartz

Android FTW?

On Sat, May 29, 2010 at 11:12 AM, Marc Schwartz <marc_schwartz at me.com>
wrote:
> Hi all,
>
> There have been posts in the past about R being made available for the
iPhone and perhaps more logically now, on the iPad. My recollection is that the
hurdle discussed in the past was primarily a lack of access to a CLI on the
iPhone's variant of OSX, compelling the development of a GUI interface for R
specifically for these devices. R itself, can be successfully compiled with the
iPhone development tools.
>
> Well, now there is another, clearly more profound reason.
>
> The FSF has recently communicated with Apple on the presence of a GPL
application (GNU Go) in the iTunes store because the iTunes TOS infringes upon
the GPL. Apple, given a choice, elected to remove the application, rather than
amending their TOS.
>
> The FSF also informed the developers of the iPhone port of GNU Go that
their distribution is in violation of the GPL. R Core and any others considering
an iPhone/iPad port of R, if you are not already aware, take note...
>
> More information is here:
>
> ?http://www.fsf.org/news/2010-05-app-store-compliance/
>
> with an update here:
>
>
?http://www.fsf.org/news/blogs/licensing/more-about-the-app-store-gpl-enforcement
>
> So, until Apple amends their TOS agreement, it looks like there will be no
GPL apps available for the iPhone/iPad, since the only way to make applications
available for these platforms is via the iTunes store (unless you unlock the
device). Hence, no R for these devices in the foreseeable future.
>
> BTW, I am posting this as an FYI, not as a catalyst for a discussion on the
political aspects of this situation. So please, let's not go there... ?:-)
>
> Regards,
>
> Marc Schwartz
>
> ______________________________________________
> R-help at 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.
>

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

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

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.

 -Ken

	[[alternative HTML version deleted]]