Protect your application's IP (on Dynamic CRM or any other platform)

One of the biggest feature requests that I have heard from ISVs, over and over, is the ability to protect their Intellectual Properties (IP). For example, Dynamics CRM ISVs typically implement the custom business logic of their application as a callout managed library(dll) that plugs into CRM execution pipeline. These dlls are part of the ISV solution and should be protected against reverse engineering and illegal copying. Often these solutions are sent to customers for evaluation and after a period, customers may decide not to make a final purchase or stop renewing the ISV license.

The problem is that although ISVs are legally protected by their End-User Licensing Agreement (EULA) against such cases, in practice, most ISVs are not wealthy enough to bring a litigation case against every such customer. So what is the solution? Shouldn't we have a software solution to this problem instead of relying on legal documents?

Here is one possible solution: Microsoft Software Licensing and Protection Services (SLPS). SLPS uses a selective .NET code transformation technology that help ISVs protect their IP with a higher level of protection. There are already some other solutions out there but I highly encourage you to check out SLPs and see how different it is. One caveat is that CRM solutions have more than just dlls. They have xml files that contain customization and client side scripts. What about those non-.NET files? Technically SLPS will not help there a lot and since CRM platform reads and processes these xml files, one place to put a gate would be in the CRM platform itself…..

I’d love to hear your thoughts, especially from the folks who have tried SLPS with Dynamics CRM. Did you manage to get it to work? what was your experience?

Currently rated 2.0 by 1 people

  • Currently 2/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Related posts

Comments

October 17. 2007 04:35

Gravatar

And then there is also the JavaScript for OnLoad, OnSave and OnChange events, which can become quite extensive. Not much can be done about that, either (unless you push most of its functionality off to Web services, but in a lot of cases that's non-optimal). Since we develop for CRM in-house we don't worry about this very much. We have had one vendor build an add-on for us in CRM and they used an obfuscator to keep their DLL's MSIL safe from Reflector. I know, I checked :-). But it was while we were having a problem with it and I was trying to do some problem determination, I swear! :-)

Jim

October 17. 2007 13:08

Gravatar

Thanks for your comment Jim. I have some ideas about a method that 'may' allow you to protect your client side code....no promises since it is still in a very very early thinking stage but I will post something as soon as I have something....

Arash

October 25. 2007 06:55

Gravatar

I'd love to hear about a method for protecting client side code. So would many others, as the heart of most of my customizations lie in client side coding and the isv.config file.

Michael Dodd

November 26. 2007 07:52

Gravatar

Check out my latest blog post on using managed code for client side logic.

Arash

February 22. 2009 11:53

Gravatar

its great method to protect client side code..thanks for sharing..

piyush

March 6. 2009 04:35

Gravatar

I gone through this method.It is really working.Now i am able to protect my IP application.thanks for sharing SLPS. Regards...

Short Jokes

March 18. 2009 07:25

Gravatar

Thank you for another great article. Where else could anyone get that kind of information in such a perfect way of presentation.

life quotations

Comments are closed