Mobile LC Apps Downloading Stacks After installation

Sat Aug 12 15:34:05 EDT 2017

Mark Waddingham wrote:

 > Okay so the thread from which this post came has some glaringly large
 > and obvious incorrect statements in it so I think it wise I correct
 > them.

Great post. Thanks.

My apologies if anything I wrote was construed as misrepresenting your 
opinion.  Not my intention.  Perhaps I misinterpreted the meaning of 
"fine" here in your post from May in the thread about similar 
downloading policies on Android:

     If LCB FFI is not used, then everything is fine. If it is used,
     then it does open the door to being able to download non-native
     executable (LCB VM) code to be downloaded and extend the API
     access of an app.
<http://lists.runrev.com/pipermail/use-livecode/2017-May/237421.html>

The following reflects only my own opinions; I am neither an attorney 
nor a representative of any company other than my own:

In actionable terms, this discussion, like so many others in life, may 
be boiled down to four words:

    Don't be a jerk.

No OS vendor wants to approve an app for distribution through their 
platform and have it later morph into something else.

Downloading "executable code" is probably the least of concerns for most 
developers.  Most OS vendors provide a long list of reasons they may 
remove your app and/or ban you from their distribution outlets, 
including content they deem objectionable, simply being one of a 
category they consider already overpopulated, being in their view too 
easily replicable in a web page, or just not looking good.

Moreover, in addition to the explicit reasons they list, they also 
provide a catch-all for a potentially infinite variety of reasons not 
listed.

iOS:
    9. Amendment; Communication. Apple reserves the right, at its
    discretion, to modify this Agreement, including any rules and
    policies at any time.
<https://developer.apple.com/programs/terms/apple_developer_agreement.pdf>

Android:
    7. Google Takedowns
    ...other terms of service as may be updated by Google from time to
    time in its sole discretion;
<https://play.google.com/about/developer-distribution-agreement.html>

These rules are vague, but not arbitrary.  All of them, including the 
"at its sole discretion" clauses, are there to protect interests of the 
company and/or their customers.

We can explore "executable code" as long as we find the discussion 
enjoyable (I'll even indulge in a bit of that below), but the bottom 
line is that we don't want to build a reputation for ourselves as 
developers, or for LiveCode as a platform, as being a gang of rogue 
miscreants hellbent on testing the boundaries of acceptability.  That 
would be jerkish.  Don't be a jerk.

Beyond "executable code", we want to try to adhere to all aspects of app 
safety and quality the distribution outlet vendors ask for.  I think 
Mark's opening and closing comments sum this up well:

 > First of all being able to submit apps to the App Stores which exist
 > today is critically important to our ecosystem - those App Stores come
 > with rules about what is allowed and what is not - the players
 > involved here have demonstrated that they can and will change those
 > rules without consultation and also have budgets larger than you can
 > imagine so, no, you will not win a fight with them so I strongly
 > suggest not trying in the first place. (Also, remember these are
 > *their* gardens - they are not public - they are free to do what
 > they want and see fit!).
 >
 >  From my perspective, there are numerous things we could do
 > technically to the engine in order to completely prevent any Apps
 > in our ecosystem violating the critical rules which seem to cause
 > a lot of confusion. I'd rather not do this as it would be a very
 > large blunt instrument based on a very strict interpretation of
 > said rules which would mean a lot of you would have to rewrite a
 > fair bit of code (e.g. We completely remove the ability to compile
 > code at runtime if the engine is running in the context of one of
 > those stores - no 'do' or variants, no ability to create objects
 > with any code attached etc).
...
 > Like other things in life, if you have to drill down too far in terms
 > of asking 'is it okay if I do this', then it probably isn't. On the
 > other hand, 'better to ask forgiveness than permission' - there are
 > *real* people behind App Store review processes, the above are
 > policies/guidelines. As long as you can demonstrate that what you are
 > doing is in keeping with the rules, and you have good reason to do
 > what you are doing, then you aren't hugely likely to encounter a
 > problem.

Earnestness goes a long way in building trust.  Make an earnest effort 
to deliver a high-quality user experience that's useful and enjoyable, 
and your chances of meeting with app removal will drop significantly.

Those chances of removal will never be completely eliminated. Even if 
you don't download "executable code" and reasonably comply with the 
other stated terms, the "at its sole discretion" clause leaves open the 
possibility of removal and/or banning for reasons you cannot know in 
advance.  Cases of useful, well-designed apps that conform to stated 
policies being removed are rare, but we've all read enough news stories 
about them to know that it happens.

But thankfully, with the exception of iOS SDK TOS v4 Section 3.3.2 
(later rescinded though never apologized for), most rules in most app 
stores make reasonable sense and can be anticipated by developers.

In short, don't be a jerk. :)

Jerks hurt not only themselves and their own company, but it might only 
take a few to build a bad reputation for LC as platform, which would 
then hurt all of us.

Make great apps, do so with earnestness, and your chances of avoiding 
removal are high.

--=================================================================--

Some semi-random thoughts on "executable code":

Mark wrote:
 > So, first question - is script 'executable code'? Yes. Script is code
 > (they are essentially synonyms in our 'world'); Script is executable -
 > it is executable by the LiveCode engine. Let's be clear about this -
 > one can 'hypothesise' about the boundary between code and data but it
 > is pointless. Data is code if it can be executed and *is* executed -
 > i.e. cause a physical processor to execute instructions which is
 > parameterized by that data. (e.g. 'Machine code' is data until it is
 > put into an executable page and called - so even as data it is code,
 > if it is executed at some point).
 >
 > Second question - do stackfiles contain executable code? Only if you
 > put data in them which could be considered to be executable - script
 > is obviously covered here. Whether that script be set as the script
 > properties of buttons, or as strings which you then set as a script on
 > an existing object, or execute with 'do'. The means by which a script
 > is executed, or could be executed, is immaterial. If your app takes
 > data from a stackfile and causes the engine to execute steps
 > parameterized by that data, then your stackfile contains executable
 > code.

I believe both of those comments are very valuable, first defining 
"executable code" in a broad sense of anything that triggers execution 
in the CPU, and then bringing it home in this LiveCode context to 
discuss some of the breadth of ways things may be considered "executable".

They key question with regard to app stores is:

     Is thing you want to download the sort of "executable code"
     the OS vendor cares about?

Some things that may be considered "executable code" seem obvious, 
others maybe less so.

Consider fonts:

In the olden days computers rendered fonts from bitmaps, and in the 1988 
a US court rules that no copyright protection could be afforded them 
since their designs are derivative of common shapes and thus primarily 
utilitarian.

But in 1992 the US Copyright Office revisited its 1988 decision, and 
determined that the latest digital outline fonts in fact had elements 
that could be protected as software, i.e. "executable code". Since that 
time, the Office has accepted registration of copyright for vector 
fonts, such as PostScript Type 1, TrueType, and OpenType format files 
under the category of Software Programs.

Summary:
<https://en.wikipedia.org/wiki/Intellectual_property_protection_of_typefaces>

Announcement of court ruling:
<https://www.copyright.gov/history/mls/ML-443.pdf>

Consider also spreadsheets:

If you write a formula in C or Pascal, it's executable code.  If you 
write that same formula in an interpreted language like Python or 
LiveCode, it's executable code, even if the context of execution is 
limited to a specific interpreter app.  So if you write that formula in 
an interpreted language and that interpreter happens to be a spreadsheet 
or other app that allow end-user calculation and/or automation, are the 
instructions you typed any less executable?

Consider visual programming languages:

Is "executable code" limited specifically to typing?  What if you use 
visual means of authoring the instructions that an interpreter will use 
to execute statements in a CPU?  Are software programs made through 
point-and-click tools not software programs?  To what degree does the 
specific set of input gestures and resulting symbols used to create 
"executable code" determine whether it is or is not "executable code"? 
How could arranging sequences of text glyphs by pressing buttons on a 
keyboard necessarily be "code" but arranging sequences of other symbols 
like boxes and triangles by pressing buttons on a mouse not be?

Consider vector graphics:

Vectors graphics are sets of instructions for rendering shapes and 
images.  Just as fonts are "software programs" written for PostScript or 
TrueType interpreters, vector graphics are written for rendering 
interpreters like SVG, EPS, and others.  Vector graphic instructions are 
often referred to as "op codes", but just because the symbols are often 
shorter, their scope more limited, and that they're most commonly 
produced through visual means rather than typing, are they any less a 
form of code?

Consider stack files, or many other non-bitmap data formats:

Even without typed scripts, a stack file is akin to a vector image, a 
collection of sequences of op codes which tell the interpreting engine 
how to render the objects on screen.   They would seem to fit the 
general definition of sequences of symbols designed to affect the flow 
of execution through an interpreting engine every bit as much as fonts 
are instructions for those rendering interpreters.

Consider ebooks:

Modern ebooks often support a wide range of interactivity, allowing a 
non-linear traversal of the work which responds to unique user-generated 
events to determine execution paths.  Are interactive ebooks and other 
interactive multimedia documents "executable code"?

Consider game levels:

See "ebooks".

And for iOS, consider the "teaching" exclusion from the prohibition on 
downloading "code":

     2.5.2 Apps should be self-contained in their bundles, and may
     not read or write data outside the designated container area,
     nor may they download, install, or execute code, including
     other apps. Apps designed to teach, develop, or test executable
     code may, in limited circumstances, download code provided that
     such code is not used for other purposes. Such apps must make
     the source code provided by the Application completely viewable
     and editable by the user.
<https://developer.apple.com/app-store/review/guidelines/#content-based-reader-apps>

What exactly constitutes "teach, develop, or test", and what 
specifically are the "limited circumstances" allowed?  Can we produce 
apps that allow end-user automation by editing scripts?  Can they share 
those scripts with their friends?

Given the scope of authoring and execution options available in modern 
computing, and the philosophical nature of legal interpretation, the 
definition of "executable code" is not well defined by any OS vendor, 
nor should we expect it to be.

By leaving such rules vague, OS vendors allow for a broad range o 
earnest, reasonable use-cases from developers adding value to their 
platform, while protecting themselves and/or their customers from 
adverse possibilities they can't anticipate.

I believe that if we do a reasonable job of anticipating and 
accommodating the interests of an app store owners and their customers, 
the likelihood of any particular practice causing removal of your app is 
greatly diminished.

You might even be allowed to download fonts. :)

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com