I think the royalty model makes more sense because what the customer pays is proportionate to the value of the software to him – i.e. the more he sells of his product, the more he pays. However, most customers do not want to keep track of shipments and royalties. Hence, even among royalty companies, royalty buyouts are common. With the royalty-free method, we obviously cannot sell one license to a customer to use forever. We would soon be out of business. Hence, our competitors and we limit the license to one developed product.

Defining one product is difficult. If there are two versions, one with an industrial hardened case and the other with a normal case, and everything else is identical, are there two products or one? If some versions have more inputs, but everything else is identical, is there just one product? I think you can see that defining what is one product leads to a lot of negotiating. I had one prospect argue with me that their refrigeration and heating units were all one product because they all moved heat from one place to another! What do you do if there is single “platform” used in diverse products such as parking systems and data acquisition systems? Many large companies like to do this to keep costs down. What do you do if your products are part of a technology used in diverse moderate-cost products of which only 10 or 20 are made per year?

We offer the one product royalty-free license as well as other licenses. About 2 years ago, I decided to introduce a 50,000-unit production limit on our least expensive one product license. Most true embedded systems have lifetime productions of less than 50,000 units, so this is no problem for them. Products with greater than 50,000 lifetime productions tend to be consumer or quasi-consumer products and I think they should pay more. Most people agree with this. There is a scale of percentage increases for higher limits, up to 50% increase for no limit. Some people have not liked this plan, but generally, it has been accepted well. I find that it allows me to be more liberal on the one-product definition. Many of our competitors deal with this problem by sharpening the one product definition when they find out that large production quantities are involved. Needless to say, they don’t make many friends this way.

When one product does not fit, then customers often want to negotiate license buyouts so they can develop many products with one license. I would prefer not to do this, because it is very hard to have a stable cash flow if you must start every sale from scratch. However, the customer is always right. Hence, we offer multi-product licenses. However, as with the single product license we cannot sell one license forever after to each customer or we will soon be out of business. Hence, we and other RTOS vendors limit multi-product licenses to one processor. However, this too can be tricky to define. Is it the same processor if it just has more memory? What if it has an additional peripheral? One processor is not good enough for many customers – they want to use an ARM7 for low-end products and an ARM9 for high-end products.

We have addressed this range of requirements with a range of licenses: Product Line (2:1), Product Family (3:1), and site license (4:1). Each, in succession, is more liberal. For example, the product line is limited to one processor; the product family allows two processors; and the site license allows 3 processors. This is a new licensing plan and it is too early to tell how well it will work. I like it because it provides a smooth range of prices to customers and precise definitions of each license.