12-11-2012 03:06 PM
Received the Gold SDK terms a few minutes ago.
Section 2b) reads:
Unless You obtain written authorization from RIM executed by an officer of RIM, You acknowledge that the License does not include and You are not licensed to develop, market, rent, distribute, transfer, license, sublicense, or furnish any software applications which contain, install, invoke, interpret, or execute interpreted software other than solely to the extent interpreted software is interpreted or executed by RIM’s and/or its licensors’ interpreters (i.e. interpreters that RIM makes available natively).
What is this nonsense? Are you intending to rule out Python, Lua, Erlang, Ruby, after making it clear that you were supporting these open source efforts on the platform? If so why does RIM go to such lengths to create a developer friendly platform and then shoot itself in the face at every single opportunity?
Thanks in advance for the clarification and pointing me in the direction of some better information that might clear up my misunderstanding.
12-11-2012 03:16 PM
I cross-posted this to the more general "General Open Source Topics" forum, since some may read it and not this one.
(Please keep discussion in this thread, not the other, for simplicity. If it seems warranted at some point, a moderator could move this entire thread to the other forum.)
12-11-2012 04:28 PM
ugh - and my morning just got worse. Thanks for pointing this out.
I understand the motivation behind these rules, but i'm not sure if they realise the full impact of enforcing them.
12-11-2012 04:47 PM
12-12-2012 08:12 AM
New to BB development and was about to invest significant time but this licence issue has stopped that plan dead in it's tracks. I avoided dev'ing for that other platform specifically because of this type of constraint but assumed it wouldn't be an issue on the BB. Is this clause new? Is it likely to be dropped?
On a semi-related note I discover recently about BB blocking local network access, thus preventing running local web servers and such like. Me thinks such restrictions (this issue and the above) should be controllable by the end user. Anyone have additional info?
12-12-2012 11:50 AM
12-12-2012 01:50 PM
Legal documents usually mutate slowly and have history; I don't have a copy of the old SDK to compare against. Let me check and talk with other folks.
As Peter pointed out, we have investments in Lua, Python and other interpretive languages...
12-12-2012 11:31 PM
Thanks, any additional info appreciated. As it stands the clause 2b does appear to rule out what I am primarily interested in, which is a port of the SqueakVM to support the Squeak Smalltalk image (interpreted) to run Scratch (another interpreted language running on top of Squeak). I would also eventually like to do a custom version of Scratch that makes full use of Playbook features.
PS: One nice-to-have(/retain) feature of Squeak/Scratch would be Smalltalk updates without updating the app (think of the "image" as a document, as oppose to being the "app", if it helps).
12-12-2012 11:45 PM
I suspect it's ultimately going to be that "updates without updating the app" part which is the key to the whole thing.
There are already (if I recall correctly) clear terms in the vendor agreement for BlackBerry World which restrict executable code to that which is bundled with the app. That's why in-app payments to unlock new behavioral features in a game, for example, can't actually download the new features as an add-on, but have to deliver them with the original game install, disabled, until a digital good is purchased.
I think there is some merit to that, and it would preclude the "update without updating" scenario, without necessarily preventing the use of the interpreter in the first place.
Also, what's the point of a scripting language like Lua in a game, if not to provide the ability to drive the lower level features of the program in an interesting fashion? A game level which consists of nothing but different images, sounds, and arrangements of things is sort of boring compared to a new level which includes new *behavior*, delivered in the form of executable (but not native) code for a scripting engine.
In fact, any sufficiently sophisticated program ends up basically implementing a scripting language, to some degree. There's even an old saw about it called Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
I doubt the legal minds behind this one really understood software enough to realize they're technically excluding certain totally legitimate and conventional ways of writing complex software. The focus should be on the ways in which these useful tools (interpreters) are applied, not the mere presence of them in the app.