December 23, 2024

Archives for 2004

Vadasz Attacks INDUCE Act

An op-ed in today’s Wall Street Journal, by recently retired Intel VP Les Vadasz, urges the Senate to reject the INDUCE Act. News junkies may remember Vadasz’s testimony against the now-infamous Hollings CBDTPA at a Senate hearing, during which Vadasz was treated quite harshly. They may also remember that Vadasz’s view ultimately prevailed, because it was right.

Vadasz paints the INDUCE Act as the second coming of CBDTPA:

Two years ago, I had the “pleasure” of testifying before the Senate Commerce Committee on the so-called Hollings bill, which aimed to protect entertainment content against piracy by getting the government involved in the design of the innards of personal computers. Far from protecting against piracy, the bill would have suffocated innovation in the high-tech industry. Rationality prevailed, and the bill never moved forward.

Yet last month, a bill with similar goals was introduced by Orrin Hatch. The Inducing Infringement of Copyrights Act of 2004 – the “Induce bill” for short – would make liable anyone who “intentionally aids, abets, induces or procures” a copyright violation. As President Reagan once remarked, “Here we go again.” Sen. Hatch and others argue that the bill will protect kids from porn and punish those who “intentionally induce” piracy. In reality it will do neither. But it will do serious harm to innovation.

There’s a hearing on the INDUCE Act tomorrow. Who will play the Vadasz role this time?

MS to Sue Linux over Patents?

A two-year-old internal memo from Hewlett-Packard predicted that Microsoft would soon launch patent-infringement suits against companies that distribute open-source products such as Linux and Apache, according to a Joe Barr story at NewsForge. (The article reprints the memo in full.) The memo is clearly based on statements made by Microsoft negotiators during a patent licensing negotiation with HP.

My first reaction to the story was that this was just a negotiating ploy by Microsoft, to scare HP into granting better patent licensing terms – an implicit threat to sue HP if you they rejected an offered deal. But after reading the whole memo, that seems unlikely. Apparently the eventual agreement did not protect HP against the threatened suits; so raising a false alarm about such suits would have made the negotiation harder for Microsoft, not easier.

Another possibility is that Microsoft really did intend at the time to file suits. If so, the question is why, two years later, no suits have been filed. Slashdot posters suggested that the SCO-IBM suit is providing the FUD (fear, uncertainty, and doubt) about open-source that Microsoft was hoping to create with its suits, rendering a Microsoft suit unnecessary. But if some FUD is good for Microsoft, why isn’t more better?

Perhaps Microsoft changed its mind, because it couldn’t find a strong enough patent to assert, or because it feared patent-infringement countersuits from the intended targets of its litigation. This one also seems unlikely. If Microsoft’s goal was to create FUD and run up a defendant’s litigation expenses, then even an iffy patent would suffice, and Microsoft would have no trouble at all finding a patent to use. And if the goal of a suit was just to create FUD, then it wouldn’t much matter who they sued, so they would certainly be able to find somebody without a big patent portfolio to go after.

Most likely, the lawsuit threat was a ploy, designed to create FUD at HP about its use of open-source products. And the HP memo is evidence that it was working; the author clearly wanted to reduce HP’s “exposure” from its use of open-source.

Software That Lasts 200 Years

Dan Bricklin has a provocative new essay arguing that at least some software should be built to last for a long time, perhaps as long as 200 years.

We need to start thinking about software in a way more like how we think about building bridges, dams, and sewers. What we build must last for generations without total rebuilding. This requires new thinking and new ways of organizing development. This is especially important for governments of all sizes as well as for established, ongoing businesses and institutions.

It’s definitely worth thinking about how to do this, but after some thought I am skeptical that this kind of long-term investment really makes sense given the present rate of improvement in software.

Whenever we trade off present spending against future spending, we have to be careful that costs in the future are properly discounted, to account for the time value of money and for the greater efficiency of future engineers. What should the discount rate be for software investments? That’s arguable, but the correct rate is reasonably large.

Some costs deflate according to Moore’s Law, or about 60% per year (compounded). Others deflate according to the rate of improvement in programmer productivity, which I will estimate (via an utterly unsupported wild guess) as 10% annually. Some deflate as standard business expenses would; I’ll estimate that rate at 5% annually. According to those rates, over a 200 year period, Moore’s Law expenses will deflate, astronomically, by a factor of about 10 to the 40th power; programming time will deflate by a factor of about 200,000,000; and ordinary expenses will deflate by a factor of about 17,000. So an investment of $1 now is only worthwhile if it saves year-2204 expenses of $17,000 (for ordinary expenses), $200 million (of programming expenses), or a bazillion dollars of Moore’s-Law-sensitive expenses.

Given those numbers, how much should we be willing to invest now, to provide benefits to our 200-years-from-now descendants? Present investment is only worthwhile if it creates enormous savings in that distant future – and it’s hard to believe that we know much of anything about what will be wanted, technologically, that far in the future. Remember, it was only sixty years ago that Thomas Watson of IBM famously estimated that the total world market would demand only five computers.

There is one area where it certainly makes sense to invest now to provide future benefits, and that is in ensuring that records of major events (birth and death records, and similar social archives) are recoverable in the future. The easy part of doing this is ensuring that the data are archived in an easily decoded format, so that it can be reconstructed later, if necessary. (Remember, programmer effort in the far future is cheap.)

The hard part of preserving these records is in making sure that the data is stored on a medium that is still readable (and hasn’t been misplaced) two hundred years from now. Many of today’s storage media have a life much shorter than that. I understand that there is a method involving patterns of pigment on thin cellulose-based sheets that is quite promising for this purpose.

In Search of Cool Stuff

In mid-August I’m going to a small technical workshop that has a “cool stuff” session, where everybody is invited to demonstrate or explain to the group something cool. It doesn’t have to be useful or technological; the only requirement is that a group of uber-geeks will think it is cool.

Perhaps you can help me out with suggestions….

Inducing You to Read Ernest Miller

Ernest Miller is on a roll lately, especially on the topic of the INCUDE/IICA Act. I would be saying more about this dangerous bill, but Ernie is saying most of what needs to be said. James Grimmelmann at LawMeme made a nice index of Ernie’s INDUCE/IICA writings.

Ernie has instituted Hatch’s Hit List, a list of technologies that would appear to be banned by the IICA, as inducers of copyright infringement. (This is modeled on Fritz’s Hit List, a feature I introduced here in response to an earlier overreaching technology-regulation bill.)