Understanding The BlackBerry App World license models

Question

http://supportforums.blackberry.com/t5/BlackBerry-App-World-Development/The-BlackBerry-App-World-license-models/ta-p/445717

I don't understand the license models that app world provides. I want to release a paid version of my app but I do not have a http server. So I guess I can use a single or pool license model. But what exactly are these license models, do I need to write some code into my app to verify keys? Or is this simply some basic security for downloading from app world?

It seems like there is no actual license check in the app? So as soon as a user copies the app from the device they can upload it to some pirate website as it will install on any device?

I am writing an app for the playbook for use in the android player.

Answer 1

In my opinion, the whole licensing thing would not make much sense without license checks in the app. But from the reading of the linked document and from this post in the blackberry forum I think you have to implement a license check on your own. They seem to work similar to old-school PC license checks where you have to enter a serial. And the app uses an algorithm (and/or a webservice) to check the key.

But the appworld injects that serial into the downloaded file. So at least you don't have to ask the user.

---

How I understand those license models:

• Static license model
  • No license checks necessary.
• Single license model
  • You check for a single static key that is the same for all users. It's very easy to distribute it with the pirated app. You can't change the key later because you would lock out users who bought your app.
    Although blackberry must have implemented a way to get a new key for legitimate customers. Maybe appworld injects a new key when they download an update. If this is the case it would be possible to change the key in an update.
• Pool license model
  • You create a list of keys with a algorithm only known to you. App checks against that key. It's easy to distribute a pirated key. But in an update you can black list those specific keys. Someone could crack your key generating algorithm and you would have a problem, because any change in that locks out user who bought the app.
    For extra security check the key against your web service at launch. If it's already blacklisted tell the app.
  • You create a list of total random keys and at first launch you verify the key with a webservice you provide. If there is no internet connection and your app doesn't need internet you should allow a grace period. Sometimes users are on a plane if they launch your app for the first time.
• Dynamic license model
  • Use user provided data to generate a key. As far as I know you can use the users blackberry pin and customer email address, probably more. Same process as the random key license pool. Check with your own webservice.

But I don't have experience with this. So I just make educated guesses. But I think it makes sense this way.

Answer 2

The existing license models are primarily for the BlackBerry phones.

For the PlayBook, there is limited support, unless you want to make your user jump through hoops to do things like manually copy/paste the key from App World into your app when they first run it. PlayBook users are not familiar with these things yet, and I know of few apps which actually make use of the feature.

There is no programmatic way for apps to retrieve their key from App World automatically. If you use the dynamic model, you do have to provide the server yourself, though there are apparently third-party license servers you can hire for the purpose.

And yes, the current scheme is such that it's pretty easy for apps to be copied, and many have been. RIM has promised some major improvements in this whole area, though it appears the changes will arrive in 2.0.1 and not as part of the major 2.0 update later this month.

Personally, I'd wait until we see what has changed in 2.0.1 before spending much time on this. The relevant changes have been promised for (ballpark) a month after 2.0 is out, which is why I assume it will be in 2.0.1, but that is just a guess.