What types of restrictions are in place to keep me from modifying built in types in .NET?

Question

If there are types that I want to modify to meet the project requirements, what type of restrictions are there for this?

By modifying I mean:

1. Finding the type you are interested that is closest to what you need.
2. Using the reflector to disassemble it.
3. Modifying it based on your own spec.
4. Using the new type (in another namespace) in your application.
5. Release your app as commercial or open source.

Is it totally OK to do this?

Answer 1

That is not OK. The code you extracted using Reflector is copyrighted by Microsoft and some portions may even be patented. Either way, you cannot redistribute someone else's code as your own without explicit permission.

What you can do is re-create your own implementation from scratch. Describing what a class, object, or pattern does is not copyrighted (though it could feasibly, but not usually, be patented). You can describe what a string class, for example, should do, and write your own from scratch which also does that.

Legal implications aside, I am having trouble imagining a scenario where this would be a good idea from a technical perspective. If you step back and re-frame your problem in terms of the original thing you need to accomplish, you can probably come up with a much better solution. Or better yet, post that problem on Stackoverflow and get a lot more brains on it.

Answer 2

No, very definitely not. Even if you can do it, it would violate the .NET framework licence. Whether you'd actually be in legal hot water would depend on your country probably, but you'd definitely want to consult a lawyer.

If you're intending on copying the functionality into a new type, then you'd probably have to bring in a load of other internal types and potentially other oddities. Just how much Microsoft code do you want to have to copy? Then you've got problems if the original type is updated in a new release, etc...

Just don't do it - ask a separate question for how to work around whatever deficiency you've run into, but don't start taking the framework code and putting a modified version into your own code base.

---

EDIT: I originally thought Joan was talking about modifying the code, rebuilding, and then replacing the BCL class in the framework. Here were my thoughts on that idea...

It's a really bad idea for technical reasons though:

• You wouldn't be able to sign the assembly properly again, meaning that at best you could only run apps under full trust (which I don't think checks assembly signatures).
• How would you deploy your new type? You'd quite possibly have to deploy it "over the top" of the real one, which would affect anyone else using .NET.

BCL types just aren't designed to be replaced like this.

Answer 3

Not a lawyer but I'm going to say the answer is almost certainly No. Disassembling a closed source project and re-releasing it sounds wrong. Before doing this you must look at the licensing restrictions on the original binary. But then again, not a lawyer.

A better way to approach this would be to look at projects which distribute their source freely. For example Mono. They clone much of the BCL and distribute the source as well. It is perfectly legal to redistribute their source according to the license rules they use. I won't speak to the conditions on the redistrubition of their source (not familiar with them) but I'm sure someone else on this thread is.

Answer 4

Using Reflector to look at the BCL source code is technically already breaking the license agreement. I know everybody (myself included) does it, but you're already on shaky ground by point 2.

You can get around this by viewing the original source code, but this is licensed under the Microsoft Reference Source license which does not permit using the source code in modified form.

So no, this is not OK, I'm afraid.