我的具体问题是,我这样做是否违反了最终用户许可协议?
为什么要使用反射器?只需查看原始源代码!
经过更多研究,我发现.NET Framework受到与其安装的操作系统相同的最终用户许可协议的约束,但还有一些额外条款,您可以通过运行以下命令并选择适合您语言的正确选项(1033是英语)找到这些条款。
where /R "%WINDIR%\Microsoft.NET" eula*.*
由于微软操作系统的最终用户许可协议明确规定“反编译或反汇编”是不允许的,而通过Reflector查看代码可能被认为属于这一范畴,因此从技术上讲,通过Reflector查看.NET Framework源代码是不合法的。尽管可以查看原始代码... 这是一个有趣的悖论。
是的,你完全可以。你还可以设置VS2008来调试BCL。考虑到Microsoft提供了像ildasm这样的工具,让你可以看到IL代码,我不认为这会成为一个问题。
根据您对许可证和知识产权法律的了解程度,您可能认为使用Reflector是可以接受的,而不考虑.NET Framework EULA,因为您可能认为反向工程的禁止是不可执行的(这是我的看法,但我又算什么呢?)。
以下是Reference Source Code Center (RSCC) Blog关于Reflector的说法:
《RSCC和.NET Reflector的区别》你不想使用RSCC源代码的一个原因是,许可证禁止您在以下情况下使用它:
如果您正处于设计、开发或测试其他非Windows操作系统的具有相同或基本相同特性或功能的软件,则不能使用该软件。
因此,如果您涉及Mono,您将不想使用RSCC。根据您的小心程度/偏执程度,即使您仅是Mono的用户,这可能也适用,因为这可能被“测试”覆盖。但是,我认为Mono开发人员也可能小心谨慎,甚至不使用像Reflector之类的东西(老实说,我不知道他们的政策是什么)。
正如Greg所指出的那样,
[操作系统最终用户许可协议明确规定]“反编译或反汇编”是不允许的。
另一方面,微软自己的MSDN杂志写道:
[...] 我认为.NET Reflector的最佳用途是检查.NET Framework程序集和方法。[...] 通过使用.NET Reflector,您可以看到Microsoft在编写DataSet的ReadXml方法时使用了什么,或者在从配置文件中读取数据时他们做了什么。.NET Reflector还是创建对象(如HttpHandlers或配置处理程序)的最佳实践的绝佳方式,因为您可以看到Microsoft团队实际上是如何在Framework中构建这些对象的。
我不是律师,但我猜想当他们建议你违反EULA时,强制执行EULA将会相当困难...