UCITA: Why software users will lose

From his perch at Carnegie Mellon University, Stephen Cross thinks a lot about software.

Cross, the director of the university's Software Engineering Institute, is concerned about the progress of UCITA. He believes the proposed legislation could have severe technical consequences for software applications.

The Uniform Computer Information Transaction Act (UCITA), introduced three years ago, is meant to protect software developers from intellectual property theft by resolving conflicting software licensing laws that vary from state to state. Concerns over how the law is put together has prevented the legislation from passing in all but two states.

After testifying against UCITA in front of the Federal Trade Commission, Cross spoke with CNET News.com about his concerns and fears over the proposed legislation.

Q: Instead of promoting uniformity as it's set out to do, UCITA seems to have bred more confusion about the rules that apply to software. Why is that?
A: There are several reasons. Software as a field is changing very quickly--in some cases from a product to a service. So when we think about financial services provided over the Internet, the service is enabled by software. We are really buying a service; we are not buying the software as a product. It gets very confusing because in many cases we do buy shrink-wrapped software--like Quicken.

What makes it even more confusing is the premise that software--whether it is as a product or service--is just too hard to engineer. The premise is that you can't build it without bugs or defects. We prefer the words "defect." Because of that, software vendors require unprecedented warranty protection that is not extended to other product manufacturers.

The assumption that software engineering can't be done without defects means is that there is no incentive to produce higher-quality software.

Is that your central objection?
That is the heart of opposition to the proposed legislation. We know it is possible to engineer software without defects; the techniques are known. There just isn't market pressure to encourage vendors to produce such software...When we study the number of incidents we've looked at this year (it's up to 53,000) 95 percent of those we investigated involved a preventable defect in commercial software products.

You are saying that UCITA hurts the progress of developing better software?
Yes. The way I understand the legislation, the vendor of the software can't be held liable for the defects or the damages the software causes--except for maybe the initial cost of the software. With all the embedded software in medical devices and automobiles, it is conceivable that there could be a life-threatening issue related to defects in software. Still, the only liability to the vendor would be the actual cost of that software, which would be minimal.

Isn't it plausible that writing code without some flaws somewhere is close to impossible?
We think that is totally false. There are engineering techniques, many of them we developed here at the SEI (Software Engineering Institute) that allow software developers to produce zero-defect software. The assumption that software engineering can't be done without defects means is that there is no incentive to produce higher-quality software. It actually encourages the foisting of poor-quality products into the marketplace.

Another premise we need to change is that we are somehow protecting the industry with this proposed legislation.

So what technical premise would be fair to both sides?
The No. 1 premise is that it is possible to produce quality software. The second premise that needs to be changed is that using engineering techniques to make defect-free software would increase the cost of developing software. The way it's worked in other engineering fields--and it's turning out to work this way in the software field also--is that most of the cost associated with the work to remove defects happens after the software has been built. So, intuitively, if you build it right the first time around and you don't have to do that work, your costs will be less.

Another premise we need to change is that we are somehow protecting the industry with this proposed legislation. The real risk I see is that while we are protecting this U.S. industry, the overseas industry is going to be fast and adopt high-quality methods. We'll just end up giving the industry away.

Is it possible to balance the need for piracy protection with the need for reverse-engineering to improve software or software compatibility?
I certainly understand why the vendors of software have a right to protect their intellectual property. The pirating of software is a very important issue. However, there are trusted groups--including us--who do reverse-engineer software at times when we have permission of the vendor to identify defects. We do this in the context of cybersecurity. It is a valuable engineering technique, but it's a very thorny issue because I do understand the need for software piracy protection.

What's the next step that the pro-UCITA groups should take in drafting the legislation?
I would advocate strongly that the legal community--which is authoring this legislation--go back and correct the underlying technical premises and then go forward from there.