I am working on mobile location SDK product, which we currently are distributing for each interested client privately in a very controlled way. Each mobile build is tailored to a specific client needs. Ideally we want to put more generic SDK on a company`s webpage that anyone could register, download it and trial it out obtaining trial keys generating more test data for us in a process as well.
The problem is as the location is concerned we have many algorithms and stuff that SDK is based on implemented on mobile client, and we are worried that someone might back-engineer it if we start allowing anyone to download and use it.
So on one side we could keep mobile SDK product distribution super controlled and be on a more safe side so to speak giving the final thing for integration only to trusted clients but unless we put it in a more accessible place, to my mind, we will be worse off in a long term of attracting more customers as well as getting more rapid test data from more people.
I would like to hear some suggestions and stories of other people having developed or developing an SDK and dealing with similar situations and your experiences from that.
If I correctly understand your situation your SDK contains some proprietary algorithms and at the same time the SDK cannot be used without server component that you tightly control. So unless you are making over a billion in annual revenues I wouldn't worry about it at all. Just make sure your IP right are legally protected, restrict access to your source code and only distribute binaries.
I think fear of reverse engineering is exaggerated in today's world. It is very expensive and only companies with well established business in underdeveloped countries can benefit from it.
Also keep in mind that for companies that can afford it may be cheaper to buy your business with all the IP rights than go for the trouble.
As for the rest, there are always be people who either maliciously or out of curiosity will want to tinker with your code. But this is highly unlikely that they will be able to build successful business around it.
There is also danger that your existing customers will want to reverse engineer . But as long as you provide continuous development, bug fixing and support for your code, they will happily pay you for the license if it saves them money. So, as long as you don't drop the ball on your end and you have nothing to worry about.
You also need to evaluate how much these concerns can hurt you and how much you benefit from making your SDK publically available. In my experience benefits almost always prevail.
This is a complex issue I've seen employers and clients deal with before (I worked for Sun for 11 years in Java tools, and of course Sun's approach to the Java SDK is fairly well-known - and worked with consulting clients who had various levels of concern around their SDKs and software).
Regarding reverse engineering - this is an argument I've made *against* using code obfuscators and the like: Measures that make code harder to reverse engineer will not stop someone determined to do it - if the resources of, say, a government or large corporation are thrown at it - if you lock someone like me in a room and say "don't come out until you've decompiled it and turned it into human-readable code", it will get reverse-engineered. So those kinds of measures deter casual "Hmm, I wonder how this works internally" tinkerers, and them only - and those are not the people you're actually worried about.
And the thing with this is, in most software businesses, your competitors are going to be too convinced of their own superiority to think it's worth their time to reverse engineer your work - they don't actually care. Unless you have competitors whose work you have considered reverse-engineering, probably the situation is similar for them. People spend a lot of money trying to protect themselves from this sort of thing, which, in 99.999% of the cases, was never going to happen anyway.
In general, for this sort of thing, the thing you have to rely on is the protections the legal system offers - that if someone uses your intellectual property, you can sue them. That does mean you'll have to keep an eye on competitors' products, and have a good lawyer, but hopefully you're doing those things anyway. And naturally, you should (or should have already) patent what you can, because that affords more protection than trying to prove someone reverse engineered your product and didn't come up with a similar solution on their own.
Really it's going to boil down to a cost/benefit analysis: If the value you get out of having more people use it is greater than the risk posed by someone reverse engineering it (which, as I mentioned, you have legal recourse in the case of), then you know what you need to do.
You can certainly take measures to ensure every binary that's download is independently identifiable (though that identifying information will probably not show up in someone's reverse-engineered version of it). But the bottom line is, you could spend a lot on protecting against this sort of thing, but you're probably better off getting it into more peoples' hands and relying on the legal system (with your diligence) to handle the issues you're concerned about. But do the cost/benefit analysis to be sure.
One thing that was helpful to Sun was to build a strong brand around the Java trademark, and vigorously protect that trademark. That way, customers wanted "Java" and any look-alike could not use that word without infringing the trademark, unless they paid (a lot) for a license and passed a compatibility test kit.
The trademark thing works regardless - if in customers' minds, your product is the "name brand", it lets you prevent competitors from even using the name in reference to their own products. It only works if you can gain a lot of market- and mind- share quickly, but if you can, it works well.
And it also, if you want to do what Sun did, provides a way to embrace copycats while profiting from them. If you're a competitor, would you rather take the legal risk of reverse engineering something, or paying the competitor for a license? They're going to do a cost/benefit analysis too, and the legal risk from reverse engineering is substantial in most countries. So if you actually offer a way to license the trademark (while ensuring the product will not harm the brand by requiring stringent compatibility testing), you can co-opt your competitors instead. I have no idea what your SDK is, so I have no idea if that can work for you, but it might be worth thinking about.