How to sell an framework with license and how to restrict it by limited users

Question

if i want to put an framework library to sale then how can i put license to it so that it cannot be transferable for iOS/iPhone.

I got few ideas:

1. I can implement an web service then i thought that can be access in offline.
2. It can be given for limited persons but if the app went on the live how can we handle.

any info will be helpful. Regards.

Answer 1

For purposes of this answer, I'll skip over the parts about how to make a framework. There are many posts out there to explain that part.

The business logic of licensing a framework is much more difficult than the actual implementation. You should answer a few questions for yourself first:

1. What is the license model? Per User? Per Application? Per Developer?
2. Who am I targeting with this framework?
3. Is my license limit a hard limit (App stops working if exceeded) or a soft limit (App keeps working, but I find out so I can charge more money)?
4. How much money am I willing to spend to enforce honesty? How much extra money do I need to make to justify my expenses to enforce this?

If you can build your license model per application, you will have the easiest time enforcing your license. Each app can require an unlock code, which is specific to the app bundle name. If the bundle name doesn't match, the key doesn't work, and your license is enforced.

Licensing per developer is a bit tricker. Generally, you'll have to rely upon the honesty of the people purchasing your app. I'm not aware of any good mechanisms for enforcing per developer licenses.

Licensing per user, as your question seemed to be targeted, has a much broader range of mechanisms that you can utilize. The most basic is to enforce the parameters within your contract. Most contracts have monthly or quarterly reporting standards. This places the burden upon your client to keep you up to date when they add new clients. If you target your framework for professional developers, this is probably an accurate enough mechanism.

If you are targeting entry-level developers, that will very likely drop off the map, you have to use stricter mechanisms if you want to enforce your license. They will all require a web service to manage your licenses.

Your code will need to reach back to a web service and provide an installation identifier, such as [UIDevice -identifierForVendor], as well as the Bundle Identifier. This will give you an accurate count of how many installations of your library are out there and who is using the.

At this point, you have a decision to make about how to enforce your license. If you have a hard limit on users, which I do NOT suggest, you can refuse to unlock your library if the licensed number of users for the app bundle has been exceeded. If you have a soft limit, which I also do NOT suggest, you allow everyone to always unlock and then go after the app vender for exceeding their licensed user count, or potentially not having a license at all.

What is generally an appropriate method is to use a combination of hard and soft limits. The app must report to the web service at least once every 14 days, which allows for offline use. If the library has not reported in within that window, it stops working. The web service makes a decision about whether to unlock the library based solely off the app Bundle Identifier. If the license for a specific bundle exceeds the number of seats, you notify them and give them a window (maybe 90 days) to purchase more licenses. If they decline, you block that Bundle Identifier. Then your customer can either remove your framework from their bundle or negotiate a new license.

The down side to all this all cost money and development time. In most cases, the money you could earn by licensing your code exceeds the amount of work it would take to build and maintain such a system. The maintenance and upkeep cost for the backend are nearly the same if you have 1 user or 1,000,000 users. Be sure you have enough users to justify the effort and expense before going down this path.