1 2 next »

1. Copyright monopolies
2. Patent monopolies

Monopoly madness

by Glyn Moody

Monopolies, whether created by the state or created by the market, can be problematic for open source, and as technology moves forward, new spaces to monopolise are always appearing. Glyn Moody looks at how the authorities should handle the problem.

Something is in the air – and it's certainly not spring, judging by the weather. But everywhere we turn in the digital world, we seem to find monopolies. That's worrying, because monopolies are generally regarded as bad things, for reasons Wikipedia explains:

Monopolies are thus characterized by a lack of economic competition to produce the good or service and a lack of viable substitute goods. The verb "monopolize" refers to the process by which a company gains the ability to raise prices or exclude competitors. In economics, a monopoly is a single seller. In law, a monopoly is business entity that has significant market power, that is, the power, to charge high prices.

Monopolies carry with them the threat that prices will be higher than they need to be. That's particularly problematic for markets where open source operates, since monopolies are often able to resist open source's downward pressure on prices, or even shut it out of the market altogether.

Unfortunately, new monopolies can arise at any time. For example, the current long-running legal battle between Google and Oracle over the former's use of Java in Android has thrown up a very disturbing possibility:

If Judge William Alsup rules that APIs are subject to copyrights, he would overturn common wisdom in programming circles, potentially exposing many companies and developers who have built software platforms that openly mimic existing APIs. But that’s not all. Such a ruling could shake things up for many other companies across the programming world and beyond.

Now, it's important to note that Alsup has not made a ruling at the time of writing, and has also shown himself to be an uncommonly tech-savvy judge throughout the case, so there's no need to panic. But the fact that people can even think that APIs should be copyrightable – and remember that copyright is a state-backed, time-limited monopoly – shows how monopolies can pop up when you least expect them.

The issue of APIs and monopolistic control over them has also arisen rather closer to the open source world with the following story that has blown up recently:

Microsoft is trying to lock out competing browsers when it comes to Windows running on ARM chips. IE is allowed there but not Firefox or Chrome or Opera or any other competitive browser. This is bad for the Web.

Here's what's going on. For Windows on X86, Microsoft is giving other browsers basically the same privileges it gives IE. It's not great that you don't get those privileges (certain API access) unless you're the default browser and I think that's deeply unfair (a post for later,) but at least we're able to build a competitive browser and ship it to Windows users on x86 chips.

But on ARM chips, Microsoft gives IE access special APIs absolutely necessary for building a modern browser that it won't give to other browsers so there's no way another browser can possibly compete with IE in terms of features or performance.

Some people have asked why this is any different from what Apple does, but a key issue is that Microsoft is a convicted monopolist, and Apple is not (yet...). And as the author of the above, Asa Dotzler, points out, in addition to meeting the conditions placed on it to escape any more severe punishment for its monopolistic behaviour, Microsoft also made a public commitment to render all its APIs generally available, in a document entitled "Windows Principles: Twelve Tenets to Promote Competition":

Microsoft provides the developer community with a broad range of innovative operating system services, via documented application programming interfaces (APIs), for use in developing state-of-the-art applications. The U.S. antitrust ruling requires that Microsoft disclose all of the interfaces internal to Windows called by “middleware” within the operating system, such as the browser, the media player and so forth. In this way, competitors in these categories will know that they can plug into Windows to get services in the same way that these built-in Windows features do. This has worked well, and we will continue to disclose these interfaces even after the U.S. antitrust ruling expires. In fact, we will go further, extending our API commitment to the benefit of all software developers. Going forward, Microsoft will ensure that all the interfaces within Windows called by any other Microsoft product, such as the Microsoft Office system or Windows Live, will be disclosed for use by the developer community generally. That means that anything that Microsoft’s products can do in terms of how they plug into Windows, competing products will be able to do as well.

Microsoft says there: "we will go further, extending our API commitment to the benefit of all software developers". What's not quite clear is how that sits with the earlier sentence in the document that states: "These principles will apply to Windows desktop development projects going forward." You could argue (and Microsoft doubtless will) that its API commitment only applies to the desktop, and not to ARM-based devices.

Next: Patent monopolies

1 2 next »