Here is my complete response to Sam. As you can see, very little was left out of the article.
The impact on FOSS would depend on what circumstances the code was released under. Windows code is already available under Microsoft’s ‘shared source’ programme. In this state, you must sign a restrictive NDA to see the code, and after that your mind is forever tainted with Microsoft’s intellectual property. Write anything even remotely similar to the code you were deigned to see, and you leave yourself open to litigation. In other words, taking part in shared source is a sure-fire way to torpedo your career in software.
Microsoft have for years been experimenting to find a licence that they can convince people is ‘free enough’. Fortunately they haven’t succeeded. The danger if they did would be to shift the balance in the open source world away from free software and towards a model that is more restrictive but still accepted. They have enough code to seriously upset the balance, ignoring for the moment the complexity (which includes also legacy cruft, bloat and so on) and hence difficulty for anyone to actually comprehend the code and participate in development.
Quality (or rather, lack of quality) aside, Microsoft’s code could be useful to see how formats and protocols are implemented. Linus Torvalds once wrote, “A ‘spec’ is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate. And I have seen _lots_ of total crap work that was based on specs. It’s _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality.” It’s one thing to have documentation (as the Samba team have recently managed to acquire), but there’s nothing to guarantee that there are no mistakes or deviations (intentional or otherwise) in the actual implementation. The WINE project is a classic example – consigned to faithfully reimplement all of Microsoft’s bugs, even if they run counter to documents you might find on MSDN.
There are many ‘open source’ licences. Too many, in fact. Many of these are incompatible with each other, and a ludicrous volume of them are just MPL with ‘Mozilla’ replaced with $company. What keeps open source strong are the licences that either have clout in their own right or ones which can share code with those licences. The GPL is right at the centre of this, and we should be proud that the core of open source’s superiority is Free Software. Microsoft could try and release code that meets the Free Software Definition but is intentionally incompatible with the GPL, as Sun did with OpenSolaris and CDDL. It still remains to be seen if OpenSolaris is of any success, and I think GPL incompatibility is certainly a factor there (for example, they can’t take drivers from Linux, so its hardware support remains poor). OpenOffice.org, on the other hand, is a prime example of a large proprietary project that has been released under a GPL-compatible licence (LGPL) and has gone on to be successful as a consequence. That success would not have happened if code could not be shared with other FOSS projects, integration could not be made (direct linking, etc.) and mindshare not won (FOSS advocates to write code, report bugs, evangelise, etc.).
The big stinger here is patents. Sun have addressed this in the past with a strong patent covenant, and more recently they’ve been trying to do it properly by for instance relicensing OpenOffice.org as LGPLv3 (hence granting its users the inherent patent protections of that licence). Would a mere ‘Covenant Not to Sue’ suffice for Microsoft? In the case of Microsoft’s recent releases of binary Office formats documentation, their covenant only covers non-commercial derivations. Similarly, their Singularity Research Development Kit was released a few weeks ago under a ‘Non-Commercial Academic Use Only’ licence.
It is be vital that companies have as full rights to use the code as non-commercial groups. Otherwise, the code would be deemed to be non-Free (Free Software doesn’t permit such discrimination). The contributions made by commercial entities into the FOSS realm is immense and cannot be ignored. To deny them access would be a death sentence for your code. Microsoft would be stuck improving it on their own, and in that case what was the point in releasing it in the first place? Don’t malware writers have enough of an advantage?
Don’t trust what a single company says on its own. Novell was for a short while the darling of the FOSS world… then they made a deal with Microsoft. I’m glad that many of us were sceptical of Mono back before the Novell-MS deal, because I’m sure as hell ain’t touching it now. .NET might be an ECMA ‘standard’, but like OOXML it is a ‘standard’ controlled wholly by Microsoft. Will such a standard remain competitive and open? We’ve seen this in other standards debates, a good example being the development of WiFi. Companies jostled to get their own technologies into the official standard. The end result might indeed be open, but if it’s your technology in there you already have the initiative over everyone else. If Windows is accepted as being open source, Microsoft will continue to dominate by virtue of controlling and having unparalleled expertise in the underlying platform.
To raise the most basic (and in this case, flawed) argument, free software is fantastic for all users no matter what. Free (not just ‘open’) Windows means that Free Software has finally achieved global domination – a Free World, if you will. By this argument, we should simply rejoice in our liberation from proprietary software and restrictive formats/protocols.
Of course, I have already demonstrated that this cornucopia likely will not eventuate even if Microsoft released the Windows source code as open source (even GPL). The software on top will remain proprietary (the GPL’s ‘viral’ nature aside). We’ll still have proprietary protocols and formats – and even digital restrictions management (DRM) – at the application level. In the grand scheme of things, the end consequence on FOSS of Windows source code being released might possibly be zilch.