Is that legal to use reflection on System classes?

[Vladimir Kouznetsov]

Hello everybody,

I was trying to find an answer searching google for: copyright laws
reflection microsoft .net
and microsoft.* in google groups for: copyright laws reflection
and for: legal reflection
but couldn't find anything helpful.

So is that legal in the US, Canada, Europe? Let's say I run into a bug in
the MS's implementation and I'm trying to come up with a workaround.
Sometimes one can figure out internal implementation details only by looking
at non-public members' declarations and probably even fix that by using
Reflection. And of course one could solve the problem in more cases if one
had a right to look at the IL function representation. The second way is
definitely a reverse engineering. What about the first one? If it's illegal
we probably cannot even expand objects of System classes in debugger. On the
other hand there are ways to hide those details from debugger and if they
are not hidden may be it's not illegal? I couldn't find a statement in the
EULA that it's not allowed to reverse engineer .Net Framework. There is such
a statement in .Net Framework SDK though. May be the reverse engineering is
disallowed by default? I know that in some countries copyright laws allow to
use reverse engineering to achieve integration with other company's
products.
Let's say I found a solution based on using reflection. What can I do with
it? Can I use it? Can I sell it? Can I tell everybody about the way of
fixing the problem just to become famous? Or I shouldn't even think about
it?
I'm not asking for a legal advise and I'm pretty sure that the solution is
not going to be supported by MS in any way because it compromises integrity
and stability of the Framework and OS blah-blah-blah-blah-blah, yada, yada,
yada.

thank you for your time,
v

 

[Mandar Samant [MSFT]]

Hi
Have a look at MS Shared Source CLI
http://www.microsoft.com/downloads/...FA-7462-47D0-8E56-8DD34C6292F0&displaylang=en

Here is the snippet from the website.
"
What can I do with the Shared Source CLI?
There is a wealth of programming language technology in the Shared Source
CLI. It is likely to be of interest to a wide audience, including:
a.. Developers interested in the internal workings of the .NET Framework
can explore this implementation of the CLI to see how garbage collection
works, JIT compilation and verification is handled, security protocols
implemented, and the organization of frameworks and virtual object systems.
b.. Teachers and researchers doing work with advanced compiler technology.
Research projects into language extensions, JIT optimizations, and modern
garbage collection all have a basis in the Shared Source CLI. Modern
compiler courses can be based on the C# or JScript languages implemented on
the CLI.
c.. People developing their own CLI implementations will find the Shared
Source CLI an indispensable guide and adjunct to the ECMA standards.

"
--

Regards
Mandar

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Vladimir Kouznetsov]

Thanks for the response Mandar. You are talking about Rotor, are you not? I
don't see how does that answer my questions though. In fact it adds to the
mess. IIRC I've seen a claim that the released Framework and Rotor
implementations are pretty close except Rotor doesn't have Windows specific
stuffs, including for example COM interop. So one could use Rotor sources
and compare them with results of applying reflection and make an intelligent
guess about a problem the implementation has. The question was is that
against the copyright law or not?

thanks,
v