Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
New Contributor
shawn_butler
Posts: 6
Registered: ‎04-09-2010
My Device: Bold 9700

New SDK Terms regarding interpreted code

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.

Developer
peter9477
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10

Re: New SDK Terms regarding interpreted code

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


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Contributor
danielatgrayfin
Posts: 22
Registered: ‎08-10-2012
My Device: Playbook

Re: New SDK Terms regarding interpreted code

ugh - and my morning just got worse. Thanks for pointing this out. 

 

Sounds similar to something apple tried  a year or two ago (but then back-tracked i believe). Rules like this also have serious consequences for game developers, where use of scripting laguages is common. eg. Lua is very popular, and Unity game code is scripted in javascript and/or C#.

 

I understand the motivation behind these rules, but i'm not sure if they realise the full impact of enforcing them.

 

Ugh (again)

Developer
peter9477
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10

Re: New SDK Terms regarding interpreted code

Given that Lua's even in the BlackBerry github (https://github.com/blackberry/Lua) one has to think there's going to be some nuances to this that aren't obvious from the wording of the new SDK License Agreement...

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
New Contributor
fracker
Posts: 6
Registered: ‎12-12-2012
My Device: playbook 64G

Re: New SDK Terms regarding interpreted code

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?

Developer
peter9477
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10

Re: New SDK Terms regarding interpreted code

Please start a new thread for the "BB blocking local network access" issue. Also maybe expand on that in the new thread since, as written, it means little. (Which device or OS are you talking about, where did you "discover" this if it was some published material, etc.)

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Retired
epelegrillopart
Posts: 99
Registered: ‎10-03-2009
My Device: Not Specified

Re: New SDK Terms regarding interpreted code

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

New Contributor
fracker
Posts: 6
Registered: ‎12-12-2012
My Device: playbook 64G

Re: New SDK Terms regarding interpreted code

On further checking I may have mistaken the blocking of side-loading of PB app's for more general blocking. Apologies.
New Contributor
fracker
Posts: 6
Registered: ‎12-12-2012
My Device: playbook 64G

Re: New SDK Terms regarding interpreted code

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

Developer
peter9477
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10

Re: New SDK Terms regarding interpreted code

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.

That said, are there any web pages left on the planet which don't include JavaScript that gets delivered to the client? So any app which includes a WebView that is ever used to load remote content is quite possibly doing just what is excluded by those terms.

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.


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!