The unknowns of .net 3.5 framework library source code licensing

Frans has an interesting post (and an update here) regarding .net 3.5 framework library source code licensing and he is raising an interesting question: "Should we look at this source code or not". AFAIK he is the only blog poster so far that is concerned with [MS] .net 3.5 framework source code hot topic. All the others, including me, is very happy to see this happen. So, should we have concerns, too?

Well, yes and no. First, Frans is developer behind excellent [LGP] ORM that will be a competition to [MS], once .net 3.5 is released. Actually [LGP] will (future tense because none of [MS] products is out there yet) be superior, except for LINQ integration, to both [MS] products: LINQ to SQL (which is very limited anyway) and Entity Framework (whose release data is unknown, but after .net 3.5 RTM for sure). So, he is not a typical developer like you or me, he is a component developer and he competes with [MS], or better, he will compete. So, he has to take in account any possible drawback for looking at .net source code and his concerns are legitimate - who says [MS] won't try a legal action against competition based on .net source code license agreement?

Next, I doubt that anybody actually understands the licensing. That's because licenses are written in legal dialect which is unreadable to humans and understood by few lawyers at most. And even those lawyers understand it differently. A good example is saga. So, forget about common sense and hire a bunch of good lawyers if you want to have your back partially covered - afaik there is no other way to understand the license. You can't ask [MS] whether you can do this or that - they will redirect you to your lawyer(s). And if you are dealing with [MS] lawyers you would probably need many of your lawyers - the more the better. As per us, "normal, non competition" developers, I don't think this is a problem in real world nor will [MS] bother.

Frans also says that looking at reverse engineered code (i.e. Reflector output) isn't the same as looking at source code. Actually, looking at reverse engineered code might actually be worse. I don't think anybody is allowing anybody to reverse engineering the code in the beginning (big brother doesn't yet have cameras at our work places, so it is tolerated for now). Anyway, looking at or using reverse engineered code sounds same to me as looking at or using source code. If there are patent issues it won't matter where did you get code from.

True, you can only look at the source code and not touch it or use it. I am going to say: at least I can look at it. I didn't ever think to modify the .net library anyway. But then I can't fix the bugs that I am having problems with (assuming I would know how to fix them). True, but knowing the enemy is half of the victory - IOW if I understand why the bug happens and what's going on behind the scenes I might be able to create a workaround. Next, there is no better documentation than source code. Period. And comments are even better - a cherry on the cake (who knows what they'll look like). And ability to step into the methods is very good, too. So it does solve real problems as it did Reflector. If we'd be able to temporarily use (in the case of [MS] bugfix cycle this means at least 3 years ;-)) recompiled assemblies for our own application it would be even better. But heck, even releasing source code took many years. Less restrictive licensing might take next n-years but it might happen as well. If the demand is there of course.

The bottom line is that Frans is looking through eyes of the competition developer and he has to be prudent in what he does. While for the rest of us, source code is still a great benefit, and I don't think there are real problems as long as we don't do anything really stupid. Take also note, that I am not a lawyer nor I did read [MS] Reference License carefully so my opinions are opinions of a developer.

Comments (1) -

  • Petar Repac

    9.10.2007 10:35:32 | Reply

    Well, here are two articles that warn open-source developers:,1895,2191754,00.asp">Microsoft's Open-Source Trap for Mono and">Microsoft's .NET Poison Pill?

    The risk is greatest for commercial and open-source developers and least for those doing in-house corporate applications. Microsoft isn't much in the business of suing its customers, but the company has already laid claim—" target="_blank">assertion of 235 patent violations—against open-source software. Microsoft has the means and incentive to sue open-source developers, and .NET Framework code could make the assault that much easier.

    Don't forget that competition is a good thing for us customers and that we too are concerned. I personally wouldn't like to see MS come upon NUnit, NAnt or LLBLGen Pro.