We launched version 2.5 of DotNetInvoice (my asp.net billing product) about 2 weeks ago. This release is a milestone because for the first ever we have a C# version (in addition to our standard VB.NET version).
The programming language is important because we provide the source code with every purchase…which created one heck of a mess for us a few weeks back.
How it All Started
About 3 months ago I contacted a company that provides a component for integrating with over 60 credit card payment gateways. Since traditionally we’ve supported two gateways, this would be a big win for DotNetInvoice.
I contacted the company and it turns out they have a royalty-free version that allows you to “freely distribute your own Applications that use [the component] as a runtime component without payment to [company].”
The up-front fee was hefty, but this was too good to be true!
So we contacted the company and worked out a deal. Within a week we were slogging through code and wiring up gateways like crazy.
The component was great – easy to use and well documented. After about 60 hours the integration was complete, the necessary API parameters were added to our database for all gateways (which took a bit of research), and we had a bunch of tests under our belt.
Fast forward 2 months to launch day (in the meantime we implemented a number of other features).
Picture the scene:
Our final package is prepared and we’re ready to throw the switch in the next few hours. Jeremy (co-owner of DotNetInvoice) is doing some final testing on our demo server and runs into a problem. The demo site is crashing because of a missing license file.
License file? We’d been running in our development environments for two months without any problems.
~Rob navigates frantically to the vendor’s website~
“Let’s see…license file…blah…blah…blah…refer to end user license agreement for details…wait, WHAT?!”
The Sound of Me Blowing a Gasket
You may freely distribute your own Applications that use Licensed Software as a runtime component without payment to [the company], if and only if … the Applications … are in compiled, executable form.
Wait, did I read that right?
I think it said that even if you’ve purchased a royalty-free version of their application, which comes as a compiled DLL, your application also has to be compiled. Uh oh…
Surely that can’t be right…does it matter whether my application is compiled? Should it matter?
So we postponed the launch and contacted the vendor.
We asked if we could move forward as-is. Ummm…no.
We suggested that we compile our own DLL that contains the code we use to make calls into their DLL, then call our DLL from our un-compiled application. No go.
We asked if we had any options aside from compiling our entire application and not releasing source code (this, of course, was out of the question)…and yes, there was one option!
If everyone who purchases DotNetInvoice also purchases a development license to the vendor’s software (you know, the royalty-free version), we would be in compliance.
The only problem is that a single development license for their software is more expensive than our entire product.
You can pretty much guess how the next few days went.
*Rip* out lots of code.
*Launch* 5 days late.
We ended up launching with support for four credit card gateways – two more than we used to, but a heck of a lot less than we’d hoped.
Luckily, even with this blow to our egos version 2.5 is out the door and was greeted with much fanfare – it turns out people really wanted a C# version. (If you create invoices and want to save time and get paid faster by accepting payments online, check out the new features in version 2.5)
The obvious message is that royalty-free doesn’t always mean royalty-free. Sometimes it means “royalty-free unless you distribute your source code (even though you’re not distributing ours).”
Another obvious lesson is to read your licensing agreements carefully. I’d like to point out that I’m not a complete moron – although the license text is painfully obvious in the above quote, I had to edit heavily to get it that way. In the real agreement the key points are separated by a lot more legal gobbledygook and this statement was not nearly this obvious on the first read.
I should also note that I did look through the license before we began development, and asked some clarifying questions of the vendor before we moved forward with development…but it took an extensive read-through of the license to really pick up the problem.
You would think after my last licensing debacle I would have learned.
But there’s one more lesson here, and it’s for software companies (including Micropreneurs): don’t have a license agreement that screws your customers. If you advertise a product as “royalty-free,” mean what you say; don’t hide things in a license agreement just because no one reads them. Although the onus is on the customer, it’s still a bad deal.
Ultimately this vendor is 100% legally correct. But I lost 60 hours of development time and they lost a sale and a fan (I was going to rave about them on this blog). In addition, I will be suspect of their licensing in the future and will do what I can to avoid their products.
In the long run I wonder which of us lost more from this experience?