Should We Boycott Microsoft? Can We?
Captain Charles Boycott was an unfortunate chap. Not only was he the object of prolonged social ostracism, but his name has passed into history as both a noun and a verb describing that action. At the moment, the idea is much on people's minds because of suggestions that the Beijing Olympic games should be boycotted, but here I want to discuss something quite different: whether the open source community should be boycotting Microsoft, and if that is even possible.
In part, the trigger for this is Microsoft's recent behaviour during the approval process for its OOXML document format. As I've written elsewhere on Linux Journal, it seems to me that on this occasion Microsoft has crossed the line of acceptability: not only has it stooped to just about every trick in the book to win “approval”, it has broken the entire ISO organisation in the process, with huge, long-term collateral damage.
But if that provided the immediate stimulus for the idea of boycotting Microsoft, there are other, deeper reasons why I think the open source community should consider the move. Observing the company over the last year of so, it's evident that its policy towards open source has shifted. Where before it fell back on crude invective – it's “communism”, it's a “cancer”, it's “un-American”, etc. - today it has completely re-thought its approach, and taken a far more subtle – and hence dangerous - tack.
Now, it seems, Microsoft just can't snuggle up close enough to those cute little open sourcies. Bryan Kirschner, Director of Platform Community at Microsoft, wrote: “I describe my job as “helping Microsoft and open source to grow together,” while Ray Ozzie, Chief Software Architect of the company said: “as people have been using [open source] more and more, the nature of interoperability between our systems and other systems has increased.” But the most revealing comments have come from Brad Smith, who rejoices in the glorious job title of “Senior Vice President, General Counsel, Corporate Secretary, Legal & Corporate Affairs, Microsoft”:
I do want to say this: We at Microsoft respect and appreciate the important role that open source software plays in our industry. We respect and we appreciate the passion and the great contribution that open source developers make in our industry. We respect and we appreciate the important role that open source software plays for our customers, customers who almost always have heterogeneous computer networks with software and hardware and services that, as you all well know, come from multiple vendors.
But as well as all the respect and appreciation that Brad wanted to express, he also has an interesting explanation of Microsoft's current world-view:
we believe in the importance of building a bridge that makes it possible for the different parts of our industry to work together. We believe it needs to be a bridge that respects the diversity of different business models. We believe in a bridge that is scalable, that is affordable, that is workable, and that doesn't try to move people from one island over the bridge to another but let’s everybody do what they love to do and respects that.
Live and let live: what could be more reasonable?
But let's listen to Brad again as he explains what that means in practical terms:
That is a hard bridge to build, and yet I will say I believe today more than ever that it is a bridge we need to build. And I very much value the work and the conversations we were able to have at Novell when we started to build that bridge in November of 2006.
Ah, Novell. And what lies at the heart of that joint bridge-building with Novell?
we believe that patents are best sorted out by industry leaders so that developers and customers don't have to deal with these issues themselves. We as industry leaders should take it upon ourselves to sort these things out.
When we worked things out with Novell, we did it with an eye towards succeeding in ensuring that the developers who were creating the software for Novell would not have to worry about this set of things, nor would their customers.
So there we have it. You shouldn't worry about those silly old software patents because Microsoft and Novell have sorted everything out for you: all you have to do is carry on coding.
Except that it's not quite that simple. Microsoft's vision of “live and let live” is predicated on its continuing use of software patents, and of the open source side letting Microsoft and Novell handle all the tiresome implications for open source. In effect, though, this amounts to recognising Microsoft's patents, and accepting its “solutions” for the open source community. “Live and let live” turns out to be tantamount to accepting Microsoft's right to file, own and use software patents, which, in its turn, means accepting they apply to the open source world.
Reasonable as Brad's position of “live and let live” might sound – and remember, he is not just a lawyer, but the top lawyer at Microsoft, and one of the cleverest and most articulate people in the industry – it is actually a trick. “Live and let live” on these terms represents a capitulation to Microsoft's worldview that software patents are valid. And once that it accepted, it essentially gives Microsoft the power to control open source for the duration of those patents.
This is why I think the open source world should boycott Microsoft, however much the latter might profess its respect and appreciation. Its recent overtures are, in fact, nothing less than the start of the old “embrace, extend and extinguish” cha-cha. First, it “embraces” the wonderfulness of open source; then it “extends” open source through deals like the one it signed with Novell, effectively adding software patents to the free software mix; and then, one day, it “extinguishes” by changing the terms of the licences it grants.
The question then becomes: assuming the open source world wants to boycott Microsoft, can it? Clearly it can't through refusing to buy its products, but it seems to me that it can if it returns to the roots of the word and begins to ostracise Microsoft socially. In practice, that means no more chummy get-togethers to discuss “interoperability”; no more joint projects on “optimising” open source code on the Windows platform; and generally, no more trips to Seattle or to Microsoft conferences.
What good will that do? Well, for a start it will put an end to all this oleaginous respect and appreciation nonsense, and return things to a more honest relationship in the wake of the OOXML scandal. It will cease to provide Microsoft with opportunities to blur the boundaries between real open source and all the compromised forms it is promoting through its “bridge-building” exercises with companies like Novell.
Above all, it will send a message to the company that the open source world is not falling for the old “embrace, extend and extinguish” trick, and that if Microsoft really wants collaborate, "live and let live" is simply not enough, because of the asymmetric bargain it implies. As a basic pre-condition of working together with open source, the company needs to accept free software's absolute foundation – the ability to share all its code in any way and with anyone – and that, by definition, means no software patents whatsoever.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide