.NET – Understanding Microsoft .NET Licensing

I don't know what is meant by 'software'. My assumption would be that 'software' only refers to the library included under the license (being DotNetZip) and that is doesn't extends over to my code which includes the DotNetZip library.

That's correct. The term "Software" used in the license refers to the software that license is about: DotNetZip.

If you distribute any portion of DotNetZip, you must retain all copyright, patent, trademark, and attribution notices that are present in the software (3c).

If that is the case then everything is fine as I have no issues keeping the license for DotNetZip when release this project in compiled form while having my code under its own license. If 'software' also include my code that include the DotNetZip library then that would be an issue (as it would basically act like GPL with the copyleft sense).

The latter is not the case, MS-PL is not a reciprocal license. It only requires that the software you distribute if it contains MS-PL'ed parts, must comply with the license requirements for the MS-PL'ed parts. As long as you don't give any sources from DotNetZip you do not even need to provide a copy of the license text if I read the license correctly.

There is no hard and fast rule to use another full-fledged RDBMS. Even though the latest version of Visual Foxpro can be connected to SQL Server, but I have seen very large projects still, happily, using the old DBF. With .NET you have to connect to another RDBMS and it just adds to your Setup dependency.

no you don't have to connect to anything :) . This is fine if you want tight coupling of data/application as others have mentioned. However from a design prespective this breaks down quickly when you want to scale the application. What happens when you have a very heterogeneous system that has to interconnect to multiple platforms? web/desktop/mobile etc. In this case de-coupling the code from the data-store is the normal route.

Foxpro has built-in rich reporting capability since the time of DOS era, whereas .NET developers have to depend on Crystal Reports, SSRS or other third-party variants.

Again, you don't have to depend on anything. Most "reports" are either spreadsheets or pdf (insert other format). As you have mentioned 3rd party components are available. Most projects I've worked on use custom built solutions, code-reuse means that the investment is one off.

Visual Foxpro 9.0 has .NET capabilities as well. However, it is not dependent on .NET and therefore your final executable doesn't need .NET framework installed, which is again a dependency.

If you are targeting the Windows platform, this is a poor argument. Further there are solutions that can run .NET without needing the .NET runtime e.g http://spoon.net/ or others that bundle everything into a single executable. Using silverlight/Asp.net you could also host your application as a thin client.

I have seen very large databases of Foxpro in few major government organizations, successfully running from a long time. These organizations don't feel a need to shift to SQL Server, not because of migration risks, but because they are happy with VFP.

Many companies are also happy with COBOL, however things have improved vastly since then. When the option is available to use newer technology platform, there are no real reason to use legacy platforms.