December 3, 2024

Microsoft to Pay Per-Processor License on Zune

Last week Universal Music Group (UMG), one of the major record companies, announced a deal with Microsoft, under which UMG would receive a royalty for every Zune music player Microsoft sells. (Zune is Microsoft’s new iPod competitor.)

This may be a first. Apple doesn’t pay a per-iPod fee to record companies; instead it pays a royalty for every song it sells at its iTunes Music Store. UM hailed the Zune deal as a breakthrough. Here’s Doug Morris, UMG’s CEO (quoted by Engadget): “We felt that any business that’s built on the bedrock of music we should share in.” The clear subtext is that UMG wanted a fee for the pirated UMG music that would inevitably end up on some Zunes.

There’s less here than meets the eye, I think. Microsoft needed to license UMG music to sell to Zune users. Microsoft could have paid UMG a per-song fee like Apple does. Instead, UMG presumably lowered the per-song fee in exchange for adding a per-Zune fee. Microsoft, in a weak bargaining position, had little choice but to go along. If there’s a precedent here, it’s that new entrants in the music player market may have to accept unwanted terms from record companies.

There’s an interesting echo here from Microsoft’s antitrust history. Once upon a time, Microsoft insisted that PC makers pay it a royalty for every PC they sold, whether or not that PC came with Windows. This was called a per-processor license. PC makers, in a weak bargaining position, went along. Microsoft said this was only fair, claiming that most non-Windows PCs ended up with pirated copies of Windows.

Eventually the government forced Microsoft to abandon this practice, because of its anticompetitive effect on other operating system vendors – users would be less likely to buy alternative operating systems if they were already paying for Windows.

To be sure, the parallel between the UMG and Windows per-processor licenses has its limits. For one thing, UMG doesn’t have nearly the lock on the recorded music market that Microsoft had on the OS market, so anticompetitive tactics are less available to UMG than they were to Microsoft. Also, the UMG license is partial, reducing per-song costs a bit in exchange for a relatively small per-processor royalty, where the Microsoft license was total, eliminating per-copy costs of Windows on covered PCs in exchange for a hefty per-processor royalty. Both factors make the UMG deal less of a market-restrictor than the Windows deals were.

My guess is that the UMG/Zune deal is not the start of a trend but just a concession extracted from one company that needed UMG more than UMG needed it.

Don't Be Evil, Yet

Mike at TechDirt writes:

As everyone is talking about Google’s (not particularly surprising or interesting) move into offering hosted business apps (basically taking their existing mail and calendar apps, and allowing you to run them for your business), it seems that the story of AOL’s new download software being criticized for secretly installing plenty of additional apps is perhaps more indicative of the drive away from client-side software. These days, it’s gotten to the point where you basically can’t trust any downloadable software at all not to clutter your machine, whether on purpose or not. So, while many people tout the “access it anywhere” or “no setup involved” features of web-based software, the simple lack of additional annoying crud getting installed on your computer may turn into a powerful added incentive for moving towards hosted apps.

The TechDirt guys are usually pretty sharp, but I’m afraid they’re too optimistic here. I’ll grant that today’s web-based software tends to come with less crud than desktop apps, but I doubt that will last.

It’s quite possible to distribute crud with web apps. AOL’s download app installed a browser toolbar; but a web-based app can carry its own crud-filled toolbar – it just has to put that toolbar inside the browser window, just above its app functionality. The main difference is that web apps’ crud has to be displayed inside the browser window, which doesn’t seem like much consolation to a user who depends on the web app.

So why is AOL distributing crud with its app while Google isn’t? One possibility is that Google practicing its “Don’t Be Evil” motto. Another possibility is that the companies are at different stages of a standard software business model, which goes like this:

  1. build market share
  2. lock in customers
  3. profit from lock-in

Economics tells us that if a customer is locked in so that he would have to pay a cost of C (in money or hassle) to stop using your product, then you can extract extra revenue of C from that customer. You can extract that value by charging him a higher price or by subjecting him to hassles that he would pay C to avoid. In this case the hassle is crudware that the vendor is presumably being paid to deliver.

AOL’s client software is at Stage 3 of this plan, so it makes sense for them to be cashing in with crudware. But Google’s web apps are still at Stage 1, where the goal is to attract customers. The same is true, presumably, of most web-based apps – which means that once we all come to rely on web-based apps, they’re likely to start delivering crudware too. Being an early adopter has its advantages.

Next-Gen DVD Support Yanked from 32-Bit Vista

Microsoft has announced that the 32-bit version of its forthcoming Windows Vista operating system product won’t support playing commercially-produced next-generation DVDs (i.e., HD-DVD and Blu-Ray discs), according to Dan Warne’s story at APC. 32-bit Vista will be able to access the discs, reading and writing ordinary content, but they won’t be allowed to access DRM-encoded content such as major studio movies.

For those not up on the jargon, Vista is the next major version of Windows. There are different flavors of Vista for 32-bit processors and 64-bit processors. virtually all of the computers in use today, and most of the ones for sale in stores, use 32-bit processors, so they’ll run the 32-bit version of Vista – the one that won’t be able to play next-gen DVDs.

The reason, Microsoft says, is that the DVD cartel won’t license them the right to read DRMed content on 32-bit Vista. The problem is supposedly that 32-bit Vista allows the use of unsigned device drivers, while 64-bit Vista allows only signed drivers. To be signed, a device driver has to be approved by a special testing bureaucracy, according to criteria set up by Microsoft. (Device drivers are small programs that allow the system to interact with external devices or services.)

Optional signing of device drivers is a fine idea. Bad device drivers have caused many headaches for Windows users, so it’s good to give users more control over which drivers are on their systems. Users have to make choices about which drivers to install, and a Microsoft-sponsored stamp of approval, as provided by the signing process, helps users make that decision. All of this is helpful, as long as it is ultimately the user who decides what is safe to use on his computer.

But the reality is that lots of good and useful drivers are unsigned, because companies don’t want to subject themselves to the certification process. Competent users accept unsigned drivers all the time – my two-month-old Windows XP laptop has a few dozen unsigned drivers, many of which were pre-installed by the manufacturer.

In short, moving to 64-bit Vista, to get next-gen DVD playback with Windows, means giving up your current computer and some of your current peripherals and applications. You can be compatible with next-gen DVDs, or you can be compatible with the other stuff you use. Your choice.

Or you could just get one of the other Windows-compatible DVD player applications. According to an anonymous Microsoft source quoted at BoingBoing, Hollywood’s objection to next-gen DVDs on Vista-32 applies to Microsoft but not to third-party player applications like WinDVD and PowerDVD. Those apps will be allowed to play next-gen DVDs on Vista-32 and WinXP, even in the presence of unsigned drivers. If the goal is to stop piracy, this decision makes no technical sense. If unsigned drivers are a threat to DRM, it doesn’t matter whether those drivers are attacking a Microsoft-brand player application or a third-party application. So why did Hollywood refuse to license only Microsoft?

The BoingBoing source offers two hypotheses:

This leads folks at Microsoft to conclude either:

A) The studios don’t understand the technology enough to see these risks clearly, or

B) They just want to screw Microsoft

The studios all have tech consultants, and many of them are not fools, so A seems unlikely. B also doesn’t seem completely likely. It’s probably the usual: human stupidity rolled up in a big ball.

The stupidity-ball explanation is always a contender in cases like this, but I wouldn’t rule out A or B either. Yes, the studios have tech consultants, but they had equally good consultants when they chose the horribly misdesigned CSS as the encryption scheme for first-gen DVDs, which suggests that they don’t always listen to the consultants.

There’s an interesting connection to antitrust policy here. Microsoft’s business strategy is apparently to tie Media Player to Windows. Antitrust authorities, in Europe at least, didn’t like this, and so Microsoft is claiming that Media Player is an Integral Part of Windows and not just a nice application that is designed to work well with Windows. (Recall that they tried the same argument for Internet Explorer in the U.S. antitrust case, and the U.S. courts didn’t buy it.)

This may affect the DVD cartel’s decisionmaking in at least two ways. First, if they fell for the line that Media Player is not just another pretty app, they may have concluded that it made sense to hold Media Player accountable for the Windows “bug” of allowing unsigned drivers. This makes no sense from a content security standpoint, but remember that these are the same people who thought CSS was a good idea.

Another possibility is that the DVD cartel is implementing its own antitrust policy, encouraging competition in the market for Windows-compatible DVD players by neutralizing Microsoft’s tying strategy. Having acquired quasi-governmental power to regulate the design of DVD players and the structure of DVD-related markets, the cartel would naturally want to prevent any player vendor from accumulating market power.

All of this brings us back to Tim Wu’s paper about the drawbacks of putting one small group in charge of a whole economic sector. Markets may make good decisions – if they’re competitive – but there’s no guarantee that a single entity will make good decisions. That’s especially true if we put a small group of movie executives and lawyers in charge of technology design.

PRM Wars

Today I want to wrap up the recap of my invited talk at Usenix Security. Previously (1; 2) I explained how advocates of DRM-bolstering laws are starting to switch to arguments based on price discrimination and platform lock-in, and how technology is starting to enable the use of DRM-like technologies, which I dubbed Property Rights Management or PRM, on everyday goods. Today I want to speculate on how the policy argument over PRM might unfold, and how it might differ from today’s debate over copyright-oriented DRM.

As with the DRM debate, the policy debate about PRM shouldn’t be (directly) about whether PRM is good or bad, but should instead be about whether the law should bolster PRM by requiring, subsidizing, or legally privileging it; or hinder PRM by banning or regulating it; or maintain a neutral policy that lets companies build PRM products and others to study and use them as they see fit.

What might a PRM-bolstering law look like? One guess is that it will extend the DMCA to PRM scenarios where no copyrighted work is at issue. Courts have generally read the DMCA as not extending to such scenarios (as in the Skylink and Static Control cases), but Congress could change that. The result would be a general ban on circumventing anti-interoperability technology or trafficking in circumvention tools. This would have side effects even worse than the DMCA’s, but Congress seemed to underestimate the DMCA’s side effects when debating it, so we can’t rule out a similar Congressional mistake again.

The most important feature of the PRM policy argument is that it won’t be about copyright. So fair use arguments are off the table, which should clarify the debate all around – arguments about DRM and fair use often devolve into legal hairsplitting or focus too much on the less interesting fair use scenarios. Instead of fair use we’ll have the simpler intuition that people should be able to use their stuff as they see fit.

We can expect the public to be more skeptical about PRM than DRM. Users who sympathize with anti-infringement efforts will not accept so easily the desire of ordinary manufacturers to price discriminate or lock in customers. People distrust DRM because of its side-effects. With PRM they may also reject its stated goals.

So the advocates of PRM-bolstering laws will have to change the argument. Perhaps they’ll come up with some kind of story about trademark infringement – we want to make your fancy-brand watch reject third-party watchbands to protect you against watchband counterfeiters. Or perhaps they’ll try a safety argument – as responsible automakers, we want to protect you from the risks of unlicensed tires.

Our best hope for sane policy in this area is that policymakers will have learned from the mistakes of DRM policy. That’s not too much to ask, is it?

DRM Wars: Property Rights Management

In the first part of my invited talk at Usenix Security, I argued that as the inability of DRM technology to stop peer-to-peer infringement becomes increasingly obvious to everybody, the rationale for DRM is shifting. The new argument for DRM-bolstering laws is that DRM enables price discrimination and platform lock-in, which are almost always good for vendors, and sometimes good for society as a whole. The new arguments have no real connection to copyright enforcement so (I predict) the DRM policy debate will come unmoored from copyright.

The second trend I identified in the talk was toward the use of DRM-like technologies on traditional physical products. A good example is the use of cryptographic lockout codes in computer printers and their toner cartridges. Printer manufacturers want to sell printers at a low price and compensate by charging more for toner cartridges. To do this, they want to stop consumers from buying cheap third-party toner cartridges. So some printer makers have their printers do a cryptographic handshake with a chip in their cartridges, and they lock out third-party cartridges by programming the printers not to operate with cartridges that can’t do the secret handshake.

Doing this requires having some minimal level of computing functionality in both devices (e.g., the printer and cartridge). Moore’s Law is driving the size and price of that functionality to zero, so it will become economical to put secret-handshake functions into more and more products. Just as traditional DRM operates by limiting and controlling interoperation (i.e., compatibility) between digital products, these technologies will limit and control interoperation between ordinary products. We can call this Property Rights Management, or PRM.

(Unfortunately, I didn’t coin this term until after the talk. During the actual talk I used the awkward “DRM-like technologies”.)

Where can PRM technologies be deployed? I gave three examples where they’ll be feasible before too many more years. (1) A pen may refuse to dispense ink unless it’s being used with licensed paper. The pen would handshake with the paper by short-range RFID or through physical contact. (2) A shoe may refuse to provide some features, such as high-tech cushioning of the sole, unless used with licensed shoelaces. Again, this could be done by short-range RFID or physical contact. (3) The scratchy side of a velcro connector may refuse to stick to the fuzzy size unless the fuzzy side is licensed. The scratchy side of velcro has little hooks to grab loops on the fuzzy side; the hooks may refuse to function unless the license is in order. For example, Apple could put PRMed scratchy-velcro onto the iPod, in the hope of extracting license fees from companies that make fuzzy-velcro for the iPod to stick to.

[UPDATE (August 16): I missed an obvious PRM example: razors and blades. The razor would refuse to grip the blade unless the blade knew the secret handshake.]

Will these things actually happen? I can’t say for sure. I chose these examples to illustrate how far PRM micht go. The examples will be feasible to implement, eventually. Whether PRM gets used in these particular markets depends on market conditions and business decisions by the vendors. What we can say, I think, is that as PRM becomes practical in more product areas, its use will widen and we’ll face policy decisions about how to treat it.

To sum up thus far, the arguments for DRM are disconnecting from copyright, and the mechanisms of DRM are starting to disconnect from copyright in the form of Property Rights Management. Where does this leave the public policy debates? That will be the topic of the next (and final) installment.