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.
Ouch.
The Workaround
You can pretty much guess how the next few days went.
*Rip* out lots of code.
*Re-test* everything.
*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 Moral(s)
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?
10 comments ↓
I’m sure this honestly caused you a LOT of pain.
Also, god knows our industry could use a LOT of slimming down of our license language.
Personally my company only requires that you do not say we wrote the software if you changed something, and that’s only there to make us not get sued by you writing malware or causing security issues for 3rd parties, other then that, for anything non-binding on us, anything goes.
However, as a person who writes components for people for a living, I understand their need to find a way to make money off their product.
I’m personally mystified why you can’t distribute your product as source with their product as a binary (unless you’re passing in a sort of activation code in source or something). Is there a technical/business reason here?
@Michael – They indicated a business reason:
“Our license allows royalty free distribution…since we do not collect royalties, what we sell is the developer license.”
However, what I *thought* they were selling was the 4-figure license to their royalty-free version. But apparently their intent is to get a large chunk of money up-front for the royalty-free version *and* on the back-end for developer licenses. I mistakenly thought that with the high price up-front there was no back-end. Oops…
As an example: we offer a royalty-free version of DotNetInvoice, but once you’ve paid for it you’re royalty free – you don’t have to pay us again later for developer licenses.
The reason the license is like this is because you could theoretically repackage there dll in your own dll and then give it to other developers for FREE, thereby getting around there licensing. Or worse, rebrand it as a new product and resell it.
When I worked for a component company about 30% of our customers tried to do this exact thing. The reason is that we charged per developer license fees. At a company with 5 developers, they only wanted to pay for 1 or 2 developers when they really need to pay for 5.
If you sell components, you need to protect yourself from people abusing your licensing. Developers, especially, will try to get around it anyway they can.
@Sean – I understand the issue with wrapping a DLL, but they actually address that particular issue using other language in their EULA that specifies you cannot re-package and re-sell their product as your own if it’s substantially the same. We also have this verbiage in our license to protect against it. I don’t see why they would need that restriction AND not allow us to distribute our app’s source code.
Certainly a component vendor needs to protect themselves from license abuse, but there’s a huge difference between paying for 2 developer licenses and having 5 developers use it, and not allowing someone to use your royalty-free, compiled DLL if they also provide their application’s source code. The two are unrelated from my view.
[...] How Third-Party Licensing Can Ruin Your Launch | Software by Rob [...]
Hi Rob,
Have you considered just adapting code from, for example, the ActiveMerchant libraries? They support many gateways, and so should provide you with many more than 4 supported gateway. Since it’s written in Ruby, it’s fairly straightforward to read even if you’re not a Ruby coder, and so should be quite easy to adapt to your product.
Just a thought..
Rob, why aren’t you telling us the name of the company?
In the free software world, there’s a very neat thing: standard licences. If I see “MIT”, “LGPL”, or “BSD”, that’s enough for me to know what I can do and what I can’t; I don’t need to go through the whole text (which I wouldn’t understand anyway). And if I do have a problem understanding the licence, since it’s well-known, I’ll always find someone who knows the answer.
It would be neat to create less free, but still standard, licence texts.
Then again, sellers probably don’t want you to understand the licence. In this case, those people sold you something you can’t use, and that you wouldn’t have bought had you read the licence beforehand.
Yeah, please tell us the name of the company so that we can be careful if we ever do business with them.
> please tell us the name of the company
I believe it’d be pointless. Countless companies do the same.
The point is: before you start using a library, read the license, and make sure you understand it.
Leave a Comment