tags:

views:

486

answers:

7

BCL

Specifically, am I breaking the EULA by doing this?

+2  A: 

Yes absolutely you can. You can also setup VS2008 to debug the BCL. I can't imagine it being a problem considering Microsoft provides tools like ildasm which let you see the IL code.

Micah
+13  A: 

Why bother using reflector? Just look at the original source code!

After more research, I found that the .NET Framework falls under the same EULA as the operating system on which it is installed, with a couple of additional terms which you can find by running the following command and choosing the right one for your language (1033 is in English).

where /R "%WINDIR%\Microsoft.NET" eula*.*

So as Microsoft operating system EULA's explicitly state that to "decompile or disassemble" is not permitted, and looking at code in Reflector could be considered to fall under this, it appears that technically it is not legal to look at the .NET Framework source code via Reflector. Even though you can look at the original code... an interesting paradox.

Greg Beech
It should be noted that any clauses restricting decompilation / disassembly / reverse-engineering may not be enforceable, depending on the jurisdiction. Some countries have explicit provisions in their laws on the subject to allow decompilation for interoperability purposes, for example.
Pavel Minaev
+1  A: 

The question is why you aren't using http://referencesource.microsoft.com/ instead; it's much easier to access the BCL source code that way, if you're good with their licence agreement.

Chris Jester-Young
+1  A: 

The larger question is... Can a legal document prevent you from looking at a series of bytes that are stored on a disk you own, and assigning meaning to them? It's doubtful that any court would find such a document enforceable.

(This is a somewhat different question from the matter of distributing that information afterwards).

James Curran
+2  A: 

Why bother using reflector? Just look at the original source code!

You should mention the caveats of looking at the source code, though. As Frans Bouma writes: Don't look at the sourcecode of .NET licensed under the 'Reference license'. He cites several risks, all related to the implied acquisition of un-free knowledge which might pose problems when writing own software. The most serious legal risk is probably related to involuntary patent infringements. Also, you're specifically forbidden to contribute to certain other projects, such as ReactOS (and probably Mono), after having looked at similar source code. This might in the future also include the .NET source.

Konrad Rudolph
So then this is a comment. Not an answer. Why not leave it as comment to the question where it might be found?
Geoffrey Chetwood
Hmm, let me think. Perhaps because it's too long?! I can't see anything wrong with posting this as an own answer, since it's actually also related to the question, and is a useful information, IMHO. For the record, I *did* write this as a comment first and changed it when the comment became too long
Konrad Rudolph
A: 

Depending on how reckless/knowledgeable about licenses and IP law you are, you may think it's OK to use Reflector regardless of the .NET Framework EULA because you may believe that the prohibition against reverse engineering is unenforceable (this is my belief, but what do I know?).

Here's what the Reference Source Code Center (RSCC) Blog has to say about Reflector:

The Difference between RSCC and .NET Reflector

.NET Reflector enables you to easily view, navigate, and search through the class hierarchies of .NET assemblies even if you don't have the code for them. With it, you can decompile and analyze .NET assemblies in C#, Visual Basic and IL.

Reference Source Code Center and it's integration inside Visual Studio 2008 enables a rich debug scenario for developers building applications on top of the Microsoft platforms. With it, you have fast and easy access to Microsoft’s platform source code.

What are the most important differences between RSCC and .NET Reflector?

  • RSCC can only display the sources of the .NET Framework that we currently support, .NET Reflector can enables you to see the reflected code of any .NET assembly

  • RSCC enables you to debug and step into the source code from inside Visual Studio

  • Both tools let you look at the .NET Framework source code in C#, but here's the difference in information you get as a developer: [examples elided]

One reason you might not want to use the RSCC source is that the license forbids you from using it if you are "engaged in designing, developing, or testing other software, for a non-Windows operating system, that has the same or substantially the same features or functionality as the software."

So if you're involved in Mono, you won't want to use the RSCC. Depending on how careful/paranoid you are this may possibly apply even if you're nothing more than a user of Mono, as that may be covered by 'testing'. However, I think that Mono developers might also be careful not to even use somethign like Reflector (I honestly don't know what their policy is).

Michael Burr
A: 

As Greg already pointed out,

[the OS EULA explicitly states] that to "decompile or disassemble" is not permitted.

On the other hand, Microsoft's own MSDN magazine writes:

[...] what I consider to be the best use of .NET Reflector, which is to examine .NET Framework assemblies and methods. [...] By using .NET Reflector, you can see what Microsoft used when writing the ReadXml method of the DataSet, or what they did when reading data from the configuration files. .NET Reflector is also an excellent way to see the best practices for creating objects like HttpHandlers or configuration handlers because you get to see how the team at Microsoft actually built those objects in the Framework.

I'm not a lawyer, but I guess enforcing the EULA will be quite hard when they recommend you to break it...

Heinzi