>>>>>>Yes, I agree that "subscription" is correct term. I am just not sure if it can apply to my application since it is not web-based. If it were web-based it would be easier. I am still thinking if this is correct and legal approach.
>>>>>
>>>>>I don't see how web-based has anything to do with this term.
>>>>>
>>>>>Doug
>>>>
>>>>I meant that if the app was web-based on my server turning the subscription on or off would be easier. And I think it is more common to do it that way. For example, www.ariba.com do it that way with their application. They sell license and then charge for subscription. If a customer does not pay, the application cannot be used.
>>>
>>>There are two ways to enforce this. One is to let the application do a subscription check online, you have a webservice where you can control the subscriptions based on the licenses or IP address of the clients. If the client must be able to work without an internet connection you can provide a certain time range that the program does not need to check before locking up.
>>>
>>>Second option is what we use frequently in accounting packages, since they must have a periodic closing function, to let the user type in a closing code. The closing code is only provided when the client has an active subscription. This model requires more maintenance, but it depends how many clients you have or if you have distributors that take care of the subscriptions.
>>>
>>>From a legal aspect you need to be careful, because the locking of the entire application could be doubtful. I have seen cases where the judge decided for the client, even though he is not paying, the existing "Data" is the property of the client. So if you lock the application in such a way that the client cannot get to his existing data, that could be a problem.
>>
>>I agree with you that the legal aspect of this approach is very questionable. And could misfire. One thing that kept customers paying annual support (not annual license) was that VFP data gets corrupted (sooner or later) and they needed my support in fixing corruptions. And of course, fixing bugs and new features. Recently I changed the application to work with SQL Server database. SQL Server is much more robust, in terms of data corruption. So I decided, for now, to leave it up to customers if they want to buy the support or not. The application will continue working in either case.
>
>We have a slightly different approach. For customized software (so if there is any code that is done specifically for the client) they have to continue with the "Maintenance Contract". As long as they pay the yearly fee, we provide the service they need, and we ensure that employees are trained and we keep the source code and we make free quotes and react in a certain guaranteed time to any support calls. Sometimes we also include a certain amount of hours to a favorable price if it is a very maintenance intensive application and we guarantee support outside of office hours. The client is able to cancel the contract, but then all of the above will not be provided anymore. Sometimes clients have a problem seeing the value in having people trained and knowledgeable in your office, and believe after 5 years of using the software and not having a contract, they can just ring up and ask for a change in the program or having an explanation of a feature that we don't even remember anymore how it worked. But who says we still have the source code around and have people in the house that are able to work with that code, or that we still work with Windows applications at all, so we explain all these details in our contract.
>
>For off the shelve software that needs regular adjustments, we charge for what we call "Yearly Upgrade Fee". Like Payroll software, Tax software etc that needs constant changes because the underlying laws change each year. The client is able to cancel the contract, but they will not be able to upgrade the next year. If they skip a year and want to do the upgrade we let them pay for the missed years as well, or discuss it per case.
>
>For off the shelve software that does not need any upgrades at all, that depends on the situation and what the client wants. If they can run the software and feel confident they never need any help or upgrades, they are not obligated to any contract. But we cannot give guarantee that we can help them in the future with any support.

I have a very similar approach with my software, I sell "Annual Maintenance and Support Contract." And I am not obligated to provide any support to customers who don't buy it. Even though I still answer their questions if they call. By the way, one of a very "old" customers is in Aruba (La Cabana). What I do is never increase annual support fee as long as the customer buys it every year (uninterrupted). Actually La Cabana has been taking advantage of this clause and pay less than 1/2 of what many other customers pay.
Thank you for your input.