Software Wars

Last week Hewlett-Packard attempted to use the Digital Millennium Copyright Act (DMCA) to crush security research company SNOsoft for revealing a particular nasty exploit allowing a remote attacker to access to machines running HP’s Tru64 Unix operating system. While this is not the first attempt to disrupt legitimate security research using the DMCA (see earlier attempts by the RIAA against Dr. Ed Felten), this represents a true departure from previous attempts: to a casual observer, SNOsoft didn’t even violate the DMCA!

The DMCA, as its name suggests, is about protecting copyright in the age of technology that enables perfect digital copies of copyrighted materials. Part of the act outlines terms that make it a crime to circumvent copyright controls or distribute tools for that purpose. What’s interesting is that the “technology” distributed by SNOsoft had nothing to do with copyright protection technology, it only really enabled a malicious user to access a system running Tru64 without proper authorization. Is that wrong? Undoubtedly a person using the exploit against a third-party’s system would be breaking the law, but they, not SNOsoft, would be prosecutable under US federal computer fraud statutes, not the DMCA.

Did HP honestly expect it would be able to sue SNOsoft for damages resulting from the release of the exploit, despite the fact that the problem was a direct result of HP’s own faulty software? Most software today is distributed under an End User License Agreement (such as this example Microsoft EULA) that stipulates the software is provided “as is”, under no warranty, and not even guaranteed to be suitable for any purpose! If HP is not liable to its own customers for faults in its Tru64 Unix, how can it contend that SNOsoft should be liable for any damages that result from an exploit that someone other than SNOsoft used to breach a Tru64 system?

Perhaps recognizing the possibility of setting a software-liability precedent, HP hastily recanted its legal threats.

Software companies want to be able to sell a product, but they don’t want to be liable for any damage their product might inflict. They want to sell something, but a person who purchases their product doesn’t actually own it, they only own a “license” which can be revoked by the manufacturer at any time. They want to be able to access a user’s machine without their knowledge. They want. They want. They want.

How about what we, the users, want?

It’s time that software development companies realized that they’re just regular companies and, like every other company (recent examples notwithstanding), they have to follow the rules. Play time is over. Grow up or go home.

Professional Practice Exam

I wrote the Professional Practice Exam on Monday, part of fulfilling the requirements for registration as a PEng (Professional Engineer) with APEGBC. Though the exam went well, I am still concerned with the focus of the Association on the “traditional” fields of engineering, and the lack of action with respect to advancing the state of the software engineering as a profession. Now, more than ever, the Canadian public (and the world in general) needs professional software engineers who are empowered to protect the public’s health and welfare.

Consider the suggested study material for the exam:

Though the books cover the requisite material in excellent detail, most of the case studies leave much to be desired. Legal precedents cited in the first book focus primarily on legal actions related to the construction industry, ignoring most other areas of engineering. Studies of ethical dilemmas in the second book again focus on “traditional” engineering fields. What amazes me is the complete lack of any coverage of the multitude of unique legal and ethical problems faced by Software Engineering, the youngest of the professional engineering streams. Engineers in this field require more, not less, guidance than their colleagues in more traditional fields of engineering where most of the “best practices” have been well established for decades, if not centuries.

When I registered as an EIT, I wasn’t entirely convinced that the Association provided any real benefit to electronic, computer, or software engineers. Every year at my university (SFU) the Association would swing by and declare, “you should go for your PEng!” but would fail to provide any tangible reason to do so, except for members of the “traditional” engineering fields. I entered the EIT program with the hope that the appearance of the Software Engineering stream signalled that the Association was becoming more relevant.

Three years later, I’ve seen little action on the part of the Association for Software Engineering. Sure, the Engineer and Geoscientist’s Act (“the Act”) requires you to be registered to engage in the practice of engineering, but I see little or no enforcement in the fields of software, computer, or software engineering. There are plenty of people operating in the field without certificates or registration, but the Association isn’t stopping them (in fact, the Act doesn’t provide adequate enforcement provisions according to APEGBC). Most employers aren’t looking for registered computer, electronic, or software engineers, and anyone who’s “really into computers” seems to be calling himself or herself a “software engineer”.

Any time I’ve contacted members of the Association, the reply has taken a long time and has done little to reassure me. The CSED (Computer and Software Engineering Division) of APEGBC shows very little activity. Though I’m trying to get involved to help the CSED, I get the sense that members of the CSED have already been deflated by the Association’s lack of action.

You might ask: why is this important? True, most software is destined for applications that don’t have even a remote chance of endangering life, but bad software is costing companies billions in downtime and exposing their confidential corporate data. Isn’t it part of our obligation to protect property, and the general public good? What public good is served by allowing companies to release defective software? In addition, there is a risk to the traditional engineering fields (civil and mechanical engineering in particular) that their increasing reliance on software products (most likely not designed by engineers) to design and build products could endanger life and limb.

Software touches every aspect of our lives. I would suggest that by failing to act appropriately to enforce registration, the Association is failing to fulfill its obligations as described by the Act. My question is: what is the Association currently doing, or (in the near future) going to do about it?