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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
