Product Pricing and Licensing

FAQsGetting your product pricing and licensing model right will help to significantly grow your sales. Think of the investment of your time, man power, resources and your money given to develop your software component or development tool. It is vital to price your product to allow the customer to make a return on their own investment, whilst at the same time making you money to re-invest in the product.

Q. How do I decide the price of my product?
A. Determining an appropriate price for a component is a complex process based on many factors: granularity of the logic encapsulated; uniqueness of the functionality; the number of competing products; and more. Typically there is a single license price, a team license price (4 licenses for the price of 2 or 3) and a site license price (unlimited site license for the price of 5 to 10 single licenses). Compare your product with others available in the marketplace and if you have a greater number of features raise your price above theirs. Never price your product low with the idea of making large numbers of unit sales; it simply doesn't work like that. Customers are looking for value, not 'shareware'. Please also visit our Pricing Advice Service page for additional Q&A on this topic.

Q. How do I go about licensing my product?
A. Component licensing is a twofold process: software protection and licensing terms and conditions. Software protection can be implemented in a variety of ways. There are also third-party solutions that can be purchased to accomplish this or you can build your own solution. Licensing terms and conditions are what make up the legal licensing agreement that is entered into by the publisher (you) and the customer upon purchase. These terms are best left to qualified attorneys. For more information on both areas of licensing, refer to our White Papers.

Q. Should I use a Subscription + Renewal model? Or a License + Upgrade model?
A. There are many advantages and disadvantages to consider when choosing between a Subscription + Renewal business model compared to a License + Upgrade model. One element to consider is the customer view point and the other point to consider is the likely impact on your sales revenue during the life of the product for up to 3 or 4 years. There is a detailed example of this comparing 2 products using the 2 different business models on our Pricing Advice Service page - the result may surprise you or at least make you STOP AND THINK about your business model.

Q. Should I unbundle my products to get more sales value?
A. Bundles and suites are a great idea - but only when they are used to drive up your average order value from a customer - not to drive it down. Remember your customer wants you to stay in business to be there to support him/her in the future - so make sure you strike the right balance of delivering high quality, high value software to your customers - without damaging your sales. Bundle your offerings carefully and if you think you have got it wrong - don’t be scared to go back and re-visit your product range and unbundle to get the pricing and licensing model right and unlock the full value of your product range. There is a detailed discussion of this on our Pricing Advice Service page - where we discuss how you can unlock the hidden value in your product suites or bundles and keep customers happy at the same time.

Q. Should I be charging for support?
A. You don't have to give support away for free! The industry norm is to charge between 15% and 20% of the initial license fee per annum for software support - so why aren't you charging for it? Your customers want to make sure you are there to support them - so they don't really want you to go out of business and if the service is good - they generally don't mind paying for it. Another approach is to charge per incident or per 5 incidents - but this is more difficult to manage than an annual support agreement. An example would be that a $1,000 per developer product license would have an support charge of $200. Each year the customer would pay $200 to get support, patches and minor updates - but usually not major updates. To get the major update - the customer would have to buy an upgrade license. Please also visit our Pricing Advice Service page for additional Q&A on this topic and an example of how valuable support can be to your sales revenue over a 4 year period.

Q. Should I use royalties or charge for run-time deployment?
A. Run-time royalties are not generally used in the component market. There are exceptions, of course, but depending upon functionality and granularity, most software components are deployed as run-time royalty free. Per user royalties are difficult to enforce. An alternative that is used most often with server-side components is a Deployment License. In this scenario, the developer purchases the component, builds his application, and then pays a one-time fee for deployment, or a fee per server or per processor, etc. In many cases, the developer purchases the deployment license up-front (i.e. there is no charge for the developer kit, only a tiered pricing based upon the number of users at deployment-time).

The golden rule is that if you feel you have to charge for run-time deployment - try and keep the licensing and pricing model easy to understand - the easiest being a one-time flat fee that you pay (ONCE) and never have to pay again. It is very basic approach to run-time licensing - but it has the advantage of being very easy to understand for the customer and very easy to manage and implement for you.

In some market sectors or niches run-time royalties are the norm - for example in the imaging sector or the CAD sector run-times are often charged. This is because the expertise needed to create the product is fairly unique and hence there is high-value in the trade-secrets, know how or IPR inside the software. If you have unique IPR in your product or it is very specialized - then you should consider charging royalties or for run-time deployment.

Q. What are serial numbers used for?
A. A serial number can be allocated to each order, thus enabling ComponentSource to report to you which customer has which serial number for customer support purposes.

Q. How many serial numbers do ComponentSource need?
A. Ideally we would like a pre-generated list of 500 serial numbers for each purchase option. When the list of serial numbers drops to only 100 pre-generated numbers remaining, then we would ask for a further 500 serial numbers. This ensures that we are always able to meet customer demand for products. For bestselling products these requirements increase to 1,000 serial numbers initially and we will ask for a further 1,000 when the serial numbers remaining drop to a level of 250.

Q. Why do ComponentSource want a list of serial numbers in advance?
A. The reason why ComponentSource needs the serial numbers in advance is to satisfy orders around the globe 24/7. So while you are sleeping we can still take orders for you!

Q. What is the reason for using the Escrow Service?
A. This service aims to provide developers using components in mission critical applications with the peace of mind they have longed for, knowledge that they have access to the source code if the worst happens. Such as, if the component supplier ceases to support the product or the supplier is no longer in business. ComponentSource has developed this program to encourage the adoption of components by large organizations and major corporates, some of whom are not permitted to purchase software that does not offer Escrow. Please also visit our Pricing Advice Service & our Escrow Service page for additional information.

Q. Is it mandatory that my company disclose source code?
A. No. In fact, it is generally in your best interest to offer source code only via the ComponentSource Escrow program. This protects your intellectual property while providing the customer with a measure of security for a mission critical application. If you do wish to sell a source code license at an additional price, (rather than offering Escrow), you are free to do so, but we would recommend a restricted license to use the source code. e.g. At the very least you should restrict disclosure of the source code outside the organization purchasing the source code and the use of the source code to create a commercially competitive product. Selling source code may also have ongoing support implications for you as a company, as once the customer has the source code, it may be more difficult for you to support it. Many customers do not access the source code at all and some will only look at it to review the code or learn something from your approach or architecture. However you need to be aware that if a customer makes any changes to the source code, they may still have support expectations from you and they may expect you to assist them with their issues. Please also visit our Pricing Advice Service & our Escrow Service page for additional information.

Q. What End User License Agreement (EULA) terms and conditions do ComponentSource customers agree to prior to purchasing my software?
A. Read our End User License Agreement. This acts as an umbrella set of terms allowing customers to purchase and download multiple products from different Publishers in one single order from ComponentSource. The ComponentSource EULA cross-references to your own EULA or terms and conditions that should be contained within your product. Ideally you should display your EULA to a customer for acceptance, prior to the customer running the installation process for your product.

Q. Does ComponentSource have a standard set of terms and conditions or a template that I can use to create my own Publisher End User License Agreement (EULA)?
A. No - we recommend that you find a Legal Counsel that has experience in writing software license agreements and instruct them to create a set of terms and conditions for your own organization. Ideally you should display your EULA to a customer for acceptance, prior to them running the installation process for your product.

Q. What is the ComponentSource Return Policy?
A. Please refer to our Return Policy Page.