Many people were instinctively opposed to Microsoft's proposed release of SQL Server source code. I think their fears are overblown. This article explains why I think that's so.

According to a recent ZDNet article, Microsoft is considering making SQL Server source code available to customers under its shared source program. I emphasise "considering," as Microsoft hasn't committed to doing anything yet.

The shared source program is Microsoft's catch-all for making source code available to selected products. Terms, however, vary, depending on which product's source code you are trying to access. In the case of Windows, the crown jewel of Microsoft's product line, you have to be a fairly large or important customer.

Corporations with 1,500 active Windows seats, a government, a researcher at an approved organisation (such as a school) or an OEM are eligible, meaning many users (including myself) won't have a chance in hell of seeing it. In the case of Windows CE, however, the terms are much more open, even to the extent that companies can sell derivatives works.

That's a pretty broad range of licensing terms, and probably represent the outer bounds of what Microsoft will consider for SQL Server. Microsoft could decide to set the terms as restrictive as those which exist for Windows, but I doubt it, given that SQL Server isn't nearly as sensitive a product for Microsoft as Windows. I also don't think they will be as open as they are with Windows CE, given that consistency is far more important in a database environment than in embedded systems. In other words, I'm guessing the final terms, should Microsoft decide to release SQL Server source code, will likely fall somewhere between these two extremes.

The differences
Microsoft's shared source efforts are either similar to other open source products, or completely different, depending on the product. If we are talking about desktop and server Windows, then differences are glaring. With Linux or the Apache web server, everyone gets access to the source code, whether you're a large organisation or a hobbyist at home. Anyone can make derivative works and distribute it. Anyone can compile the code and sell binaries, as multiple vendors of Linux have already done.

If we are talking about Windows CE, however, the similarities are striking. Everyone has access to Windows CE source code, and anyone can make derivative works and distribute them. In fact, the Windows CE approach bears strong resemblance to code licensed under a BSD license. You can make derivative works of Free-BSD that you keep secret, and sell the result for a profit. Ditto with Apache.

Continued ... (continued from previous page)

With Windows CE, though, derivative works bear a fee responsibility to Microsoft for every copy sold, something which doesn't apply to FreeBSD or Apache, the base for which is free as in cost. Other differences emerge if you compare Windows CE licensing terms to the GPL terms under which Linux is licensed. GPL licenses require derivates to be licensed under the GPL, which means that all source code must be released to all derivative works. In other words, derivative works cannot  keep their changes secret, something which wouldn't appeal to companies hoping to derive revenue from sale of software as such.

Microsoft's shared source efforts aren't automatically a different planet from the rest of the open source world. Fees are often involved, but as the Windows CE example shows, Microsoft can offer access to source code on terms comparable to other open source licenses.

What I'm hoping to see
I'd like everyone with a valid licence to SQL Server to get access to SQL Server source code. Perhaps that's self serving, but I'm not 1,500 people (though my friends under the pillow say I am), and I want to see the SQL Server code, anyway.

Why would I find that useful? It's not  because I want to make a derivative variant of SQL Server. I could care less about database development, not because there isn't anything interesting in it, but because I have 80,000 other programming responsibilities which take precedence over worrying about the proper way to write a database. Division of labour is a good thing, and I've made the decision that my time is not best spent worrying about writing a database.

Rather, I want to debug my own code with access to SQL Server source code. That's extremely useful. If something unexpected happens, whether catastrophic or just weird, I can dive into the code to figure out what instructions were executed. This is better than trying to untangle assembly language, which is God's way of saying you have no life.

Access to source code also makes things more predictable. When I make a call into SQL Server, I'll know exactly  how it will handle the data I'm passing because I can see how it is being handled.

Again, none of those things require that I have the ability to make derivative works. 99.99999% of the programmers in this world do not need to make a derivative version of SQL Server, and many among that last 0.00001% probably shouldn't, anyway. To put it simply, programmers who don't work for database companies and mess around with the inner workings of a database are like auto mechanics that waste time trying to fix wonky plumbing. Their time is better spent concentrating on the things they do best rather than obsessing over areas they are not experts.

Consuming red herrings
Some characterise the proposed release of SQL Server source code as Microsoft placing the burden for finding bugs in their system on others, while keeping the benefits for themselves.

Imagine I owned a beach. Beaches are big. I try to comb the beach for pieces of glass and other nastiness which might make life unpleasant for visitors, but god knows I'm human, and it's a big beach. So, I ask visitors to tell me if they find anything unpleasant. They're all over the beach, and a thousand pairs of eyes are better than one pair. This enables me to fix the problem by knocking them out with a club (no, no, removing the offending item).

Continued ... (continued from previous page)

The analogy isn't perfect, as fixing bugs in software is much  harder than picking up bits of glass on a beach. Bug fixes have to be stress tested as well as tested for compatibility with the thousands of other pieces of software which might use it. The analogy is apt, however, in that it reveals the information power of millions of disparate users. Microsoft isn't asking anyone to pull that abandoned land mine out of the sand. They are just making it easier for their customers to identify it when they see it.

That's a win-win situation. Customers, who are the most likely people to find bugs as they are the real world to Microsoft's laboratory, can find errors in a manner that makes it easy for Microsoft to fix them. In return, they then get a more bulletproof product in shorter timeframes, absolved of the responsibility of doing all the things it takes to make a real bug fix. That's an improved version of the division of labor contract businesses make when they buy proprietary software.

Parting thoughts
People are instinctively uncharitable when Microsoft does anything, even if that something is right. As a certain Carl Rapson noted in a recent ZDNet Talkback post,

The 'true religion' states that everything Microsoft does is bad and everything anyone else does (even if it's the same thing Microsoft did) is good.

Come on, people. Even if you are one of those individuals who believes that anything less than a GPL licence is tantamount to armed robbery, Microsoft efforts to release more source code is clearly a step in the right direction. Granted, they are steps made by a proprietary software company, but surely you didn't expect them to be the same steps the Free Software Foundation might have made?

I'm hoping Microsoft opts to move towards something approaching the Windows CE licensing model. Even if they don't, though, Microsoft deciding to release ANY source code is good for developers and a product millions rely on for their business.

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.