Like many, I was pretty shocked [1] by the recent Microsoft-EU deal to settle the long-running investigation [1] into interoperability issues. This was not so much because of the way Microsoft has used every kind of delaying tactic it could before eventually agreeing (for the nth time) to try harder in the future. My real dismay was provoked by the gap between appearance and reality – a chasm that I think bodes ill for the future of open source.
At first – again, like many others - I was lulled into a sense of false security by the declarations [1] of Neelie Kroes, the EU's Commissioner for Competition:
I told Microsoft that it should give legal security to programmers who help to develop open source software and confine its patent disputes to commercial software distributors and end users. Microsoft will now pledge to do so.
What impressed me particularly was the fact that open source was not only mentioned, but singled out as one of the key issues that the EU felt had to be addressed. That seemed to show an awareness of open source, and of its importance for the future of computing, that was surprising coming from such high-level – and usually tech-averse – politicians.
It was only when I read the FFII's press release [1] offering a very different perspective that I began to worry:
Neelie Kroes European Commissioner for Competition and Microsoft agreed that the royalties payable for the interoperability information will be 10,000 Euros, and that Microsoft can use its EPO software patents to charge 0.4 percent of all the sales of its competitors. The FFII says that these conditions effectively exclude open source competitors and add costs for all who wish to communicate with Microsoft products. This is a new transaction cost for all society, its the opposite of an open Internet.
Following this up, the FFII pointed me to a question in the EU's FAQ [1] on the agreement:
Can open source software developers implement patented interoperability information?
Open source software developers use various “open source” licences to distribute their software. Some of these licences are incompatible with the patent licence offered by Microsoft. It is up to the commercial open source distributors to ensure that their software products do not infringe upon Microsoft’s patents. If they consider that one or more of Microsoft’s patents would apply to their software product, they can either design around these patents, challenge their validity or take a patent licence from Microsoft.
This, of course, was rather different from what Kroes had said. about giving “legal security to programmers who help to develop open source software and confine its patent disputes to commercial software distributors.”
So what is going on?
One issue seems to hinge on the phrase “Open source software developers use various “open source” licences to distribute their software. Some of these licences are incompatible with the patent licence offered by Microsoft.” Perhaps the EU assumed that this is not a problem: provided some open source licences work, so the thinking went, it will always be possible to offer an open source alternative. Of course, what this overlooks are the details: the fact that one of those licences that are “incompatible” with Microsoft's licence is the GNU GPLv3 – which also just happens to be the licence used by Samba, the only project that really cares about Microsoft's protocols.
The Samba crew has decided [1] to get around this by taking the option of making a one-time payment of 10,000 euros for details of the protocols. That may allow Samba to get the information it needs, but there's still a big problem. As Microsoft's Patent Pledge for Open Source Projects [1] makes absolutely clear:
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you as an open source software developer ("You") for making, using, importing or distributing any implementation of a Covered Specification ("Covered Implementation"), subject to the following.
...
An "open source project" is a software development project the resulting source code of which is freely distributed, modified or copied pursuant to an open source license, and is not commercially distributed by its participants. If You engage in the commercial distribution or importation of software derived from an open source project or if You make or use such software outside the scope of creating such software code, You do not benefit from this promise for such distribution or for these other activities.
Samba may be fine, then, but commercial distributions like Red Hat, Ubuntu and the rest most certainly are not.
What really worries me is what looks like an emerging pattern in Microsoft's behaviour. The EU agreement is perhaps the first fruit of this, but I predict it will not be the last. What is happening is that Microsoft is effectively being allowed to define the meaning of “open source” as it wishes, not as everyone else understands the term. For example, in the pledge quoted above, an open source project is “not commercially distributed by its participants” - and this is a distinction also made by Kroes and her FAQ.
In this context, the recent approval [1] of two Microsoft licences as officially “open source” is only going to make things worse. Although I felt this was the right decision – to have ad hoc rules just because it's Microsoft would damage the open source process - I also believe it's going to prove a problem. After all, it means that Microsoft can rightfully point to its OSI-approved licences as proof that open source and Microsoft no longer stand in opposition to each other. This alone is likely to perplex people who thought they understood what open source meant.
Nor is this the only way in which Microsoft is carefully draining away the original power of openness. As many have pointed out, Microsoft's attempt to have its OOXML document format declared an ISO standard will devalue the whole point of having open standards. Moreover, the way in which Microsoft has gone about this – by encouraging [1] friendly parties to join the ISO voting bodies – has damaged the open standards process well beyond this particular case. As Andy Updegrove points out [1], we are already seeing the knock-on consequences of this, as real open standards are stuck in a kind of administrative limbo thanks to Microsoft's corporate hacking of the ISO machinery.
What we are seeing here are a series of major assaults on different but related fields – open source, open file formats and open standards. All are directed to one goal: the hijacking of the very concept of openness. If we are to stop this inner corrosion, we must point out whenever we see wilful misuse and lazy misunderstandings of the term, and we must strive to make the real state of affairs quite clear. If we don't, then core concepts like “open source” will be massaged, kneaded and pummelled into uselessness.
Glyn Moody writes about openness at opendotdotdot [1].
__________________________
Links:
[1] http://www.linuxjournal.com/http