I have developed a portable C++ software library. I would like to discuss how to license that software (license models). Consider that the library price would be < 5.000 EUR and that it can be used for mass market products (but not only). What I want to do is to license the software for commercial purpose. So, basically, I want to:
I know that I should consult a lawyer, but before that I would like to know your personal experiences.
First, is it reasonable to license software for a single product named XYZ (so that if you want to use it for another product, you must buy another license)? Or it is better to license the software for an infinite number of products? Clearly, in the first case, the prices for X would be different (a license for a single product should cost less then a license for an infinite number of products). But the royalties? Should Y be set to a different quantity?
Second: what to do with library updates? Should I make the updates freely available to a licensee or should an update (that contains major updates, not only just bugfixes) be considered as a new product to be licensed again?
Another question is: where can I find resources that on the web on software licensing (what are the most common models, what are the best practices and so on)?
Another question is: where can i find resources that on the web on software licensing (what are the most common modalities, what are the best practices and so on)?This is a good question unfortunately the resources on the web fall into 2 main categories:
You can get some good information from Whitepapers and some good information from forums. But you really have to have either [a] a great BS detector or [b] lots of experience using/creating licensing to be able to tell the good info from the garbage (to put it nicely).
That being said, I'm finishing writing a free eBook on building, buying, and using licensing. It's currently in a "near final draft" form (lacking illustrations and a pretty layout), but if you email me I can send you a draft (email me at [email protected] ).
You're probably thinking "What qualifies Wyatt to write a book about licensing?" The answer is that I'm founder of the company that makes LimeLM an online-activation (a.k.a. hardware-locked) licensing solution for Windows, Mac, and Linux. The ebook that I'm writing isn't some thinly veiled whitepaper selling LimeLM. It's an attempt at curing the huge amount of ignorance about licensing that exists.
We'll have the free ebook available on our site in a few months, but like I said if you want a draft copy to look over just email me.
Types of licensing
The types licensing fall into 3 general groups:
Quick aside: the point of licensing isn't to stop crackers from cracking your software. The point of licensing is to increase your revenue by preventing casual piracy (using serials over and over again). There is real money to be made by stopping casual piracy.
1. Serial only licensing
"Serial" licensing is where you have a product key like "ABCD-EFGH-IJKL-MNOP-..." and that's it. A user or company can use the product key over and over and there's nothing you can do about it.
For almost every case I recommend avoid "serial only licensing" -- use hardware-locked licensing instead. Hardware-locked licensing like online activation gives your absolute control over how your software is used and you can truly increase your revenue by preventing casual piracy.
However you mentioned the one case where "serial only licensing" is the only good choice: when you're making a software component that's used by developers within their own apps.
As I mentioned above, this is the best type of licensing for 99% percent of the cases. There are lots of types of hardware-locked licensing but the most popular variation is "online activation" (like Windows Activation or MS Office activation). The Reader's Digest version of proper online activation is:
The last 2 point are huge topics and it takes a lot of work to get it right but, as I said, it's the condensed version. I can explain them in-depth if you want.
This is a huge category. An awful lot of 3rd party licensing is snake oil. Things like "anti-debuggers", "in memory encryption", and other nonsense sound like good ideas, but in practice they hurt your bottom line.
I can go into this in depth if you want. But this answer is becoming War & Peace, so I'll just leave that perfunctory note for now.
First, is reasonable to license a software for a single product named XYZ (so that if you want to use it for another product, you must buy another license)? Or it is better to license the software for an infinite number of products? Clearly, in the first case, the prices for X would be different (a license for a single product should cost less then a license for an infinite number of products). But the royalties? Should Y be set to a different quantity?This is a huge question. Like I said above, in your case you should use "serial only" licensing (because you're making a developer component). This means the only way you have to enforce your agreements is by taking their word for it.
I know that's not the answer you want. Sorry. The licensing options for developer components are truly limited.
Gain Y% royalties on the net income of a given product.That's a tough sell. It's easier to sell a very expensive product that's royalty free than to sell a cheap product with royalties. Tracking & collecting royalties will be a huge pain in the ass for you & your customers. I can guarantee you that any company that sees that your product has royalties complicating it will first think "can we build this in-house?". And unless your product has some secret sauce, they will almost always answer "yes, we can build this in-house".
If I were you I would think twice about the royalty model.
Second: what to do with library updates? Should i make the updates freely available to a licensee or should an update (that contains major updates, not only just bugfixes) be considered as a new product to be licensed again?If I were you I would ask this as a separate question on this site. You'll probably get better answers to it.
My advice: never ever offer "free updates forever". Serious buyers will run away from companies that make such a declaration. You're basically declaring "We'll support this product for about 2 years and then we'll realize we made a huge mistake and either (a) stop supporting it or (b) go back on our promise and have paid upgrade."
Short answer: just do paid upgrades from the start. It's better for your bottom line and knowledgeable customers will take you seriously.
I prefer a license for a one time initial fee plus annual maintenance for a specific set of features. Price the license for a defined usage (number of machines, users, transactions, etc). Clients should get bug fixes and enhancements for those features as long as they pay the annual maintenance. When you expand the product to a new set of features, that would be an additional initial and annual maintenance fee.
The result is a long term business model that's cash flow positive. Otherwise, you're promising something you can't actually provide and your customers will know it. The upfront fee should make you some profit or at least break even from the upfront development, if you hit your sales targets. The maintenance fees should more than cover your operating expenses going forward. This way, if a customer stops paying the maintenance fees, your business is still sustainable.
I know one area where royalties do seem a good choice - 3d engine licensing (which basically is a library + tools), with the most famous example:
http://www.udk.com/licensing You should take a look at their scheme and decide how it applies to your market (you didn't mention what it is).
They want 99$ upfront (some kind of dummy fee really, to pay for bandwith perhaps?) and 25% royalties on all revenue over 50 000$ generated by all your products which use their technology. This is a great plan as the revenue threshold is just about the level where there may be some real income (revenue minus development costs) and it is abstract enough to lure more people into learning their technology. They deliberately filter out those developers who earn less because it would be realistically difficult to get those royalties out of them. And your license restrictions are worth something only if you can enforce them in practice (hence Wyatt's answer, although from another angle).
As to the lawyer part - no, I don't think you need a lawyer at this stage. You can anylyze existing licensing schemes and EULAs of similar products. They do seem daunting but there is nothing you can't understand. Probably your final EULA will consist from parts of other EULAs with only small modifications (mine does).
The part to remember is still that license restrictions are worth something only if you have a good chance of enforcing them, via technical or other means. If you can't enforce something from the majority of users of your library, then perhaps it's better to act generous and give it up.