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.

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.

   9. Amendment; Communication. Apple reserves the right, at its
   discretion, to modify this Agreement, including any rules and
   policies at any time.

   7. Google Takedowns
   ...other terms of service as may be updated by Google from time to
   time in its sole discretion;

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.


Announcement of court ruling:

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.

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

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to