Every so often someone voices out their opinion on some technical aspect of SharePoint. They are often trying to customize or otherwise create something that is not strictly out-of-the-box-functionality, and hit a brick wall while trying to figure out why something works like it works in SharePoint. A developer’s answer on these woes is to use Red Gate’s Reflector (or ReSharper Decompiler) to figure out how SharePoint’s own internal libraries have been implemented.

I’m guilty of suggesting this in my trainings since you might not have an alternative. EIther you figure out how to bypass or change something, or you don’t and move on to different projects.

Someone else on Quora has been pondering the same thing. Zero answers as of today.

The process of reverse-engineering a commercial product, if even for just a tiny bit, is widely regarded as an approved way, that conforms to the fair use of the software license. I wanted to find out if investigating any of the DLL’s from SharePoint is in fact allowed, or even disallowed. Turns out it wasn’t that trivial to find out.

Licensing, EULA and PUR

The licensing of SharePoint is not trivial and one has plenty of options to choose from. Assuming we’d be using SharePoint Server 2010, what licensing agreements am I bound to? Recalling things from pre-2010, there’s EULA – the End User License Agreement.

There’s at least one blog entry on MSDN, that says

EULA is an old term and was used for SharePoint 2003.

In place of EULA we have PUR – or Product Use Rights. You can find all the available PURs at the Volume Licensing site. For SharePoint Server 2010 it’s this one: http://www.microsoftvolumelicensing.com/userights/ProductPage.aspx?pid=80.

There’s the Universal Licensing Terms, General License Terms, Exceptions and a downloadable copy of PUR.

Universal Licensing Terms is a no-nonsense text describing the typical concepts and rights the license grants you. Nothing is said about reverse-engineering, disassembling or decompiling SharePoint. So at least it’s not universally denied. There’s one important piece here though, and it’s this:

You must obtain Microsoft’s prior written approval to disclose to a third party the results of any benchmark test of the server software or additional software that comes with it.

I wasn’t aware that if I use something like Visual Studio 2010 Load Test tool to get baseline information of my SharePoint farm, that I’m not allowed to disclose these findings to third parties, such as vendors and hosting providers. Interesting fact but not necessarily something that might cause Microsoft legal to hunt you down, if you happen to post a blog entry on your findings.

For .NET Framework-based components, there’s additional reference information at http://msdn.microsoft.com/en-us/library/ms973265.aspx – dated 2005, so I doubt it’s 100% relevant in 2012. It does however dictate what information must be revealed for any performance test results you might want to publish that are based on .NET.

Besides these, there’s nothing relevant on reverse-engineering in the Universal Licensing Terms.

General License Terms covers CALs, connector licenses and similar – nothing was found against or for reverse-engineering SharePoint bits.

Exceptions and Additional Terms sounds promising but it has nothing either.

PUR is also available, and it’s dated April 2012. It’s a huge document sitting at 144 pages. I didn’t find anything with keywords such as “disassemble”, “reverse”, “engineer”, “decompile” or variations on these. For SharePoint Server 2010 the PUR basically lists the necessary CALs, connectors and whatnot one should purchase in different scenarios. So nothing technical here.

What about Fair Use?

Wikipedia nicely describes Fair Use as

Fair use seems to be safe ground for reverse engineers, almost always using it as a defense. However, an EULA is a legally binding contract. If a user agrees to terms which are in conflict with fair use, the user has effectively waved their rights to fair use.

Let’s not forget about SharePoint Portal Server 2003’s EULA, which is still available for download. Buried in the EULA is the following

Reverse engineering, decompiling, or disas sembling the Software is prohibited, except and only to the extent that such activity is expressly permitted by applica ble law notwithstanding this limitation.

So that’s clear then. But this only applies to SPS 2003 (and WSS 2.0 I would guess), and not to SharePoint Server 2010 (and consequently, not SharePoint Foundation 2010).

I tried searching for a more relevant copy of the EULA, but it seems that PUR mentioned above is the only public version currently available.

There’s a combined MOSS 2007/SP 2010 guide to assessing SharePoint Server licensing available too. I couldn’t find the document via Microsoft’s Download Center, but it’s available through Google. Nothing new is revealed in the document, and the references listed in the end are the same sites I’ve linked to earlier.

So reverse-engineering is allowed then?

Since PUR specifically doesn’t disallow reverse-engineering, one might feel it’s allowed. I’m not a lawyer (and don’t intend to become one by reading these documents) so I can only offer my opinion.

For now I’ll continue with my practice of using any available reverse-engineer tools, if I feel it’s something that helps me to understand how something working within SharePoint. Problems arise if I decide to reuse any of that code to my own work, and distribute that as part of my deployments.

Until Microsoft further clarifies this, I feel it’s safe – and acceptable (under Fair Use) – to continue with this practice. There’s also much to be said about the licensing documentation, which is fairly challenging to find, and almost too hard to comprehend in certain scenarios. It should be less complex and easier to apply in the real world.