A draft committee has proposed some changes, but the old, ugly UCITA still lurks below the surface I GUESS I’D LIKEN the recently proposed changes to UCITA (Uniform Computer Information Transaction Act) to putting a bit of makeup on Frankenstein and then telling people not to worry when he’s turned loose. What underlies the rouge and lipstick is still just as scary, and the makeup never stays in place very long. The legal experts are still in the process of analyzing the amendments to UCITA that were approved by a standby drafting committee last December, so it’s probably unfair to say that all the changes are purely cosmetic. A few of the amendments do seem to be a step in the right direction, although not nearly as big a step as the proponents claim. And at least one — a change that was supposedly going to offer some needed protection to the open-source software community — appears to leave matters significantly worse than they were before. What I have to say here must be considered first-blush impressions for another reason as well. The one thing I’ve learned in all these years of observing the process that created this monster is that no matter how much it seems to change, it never really does in the long run. There are just too many mechanisms allowing it to snap back into its old form when no one’s looking. From what I’ve heard about the committee’s deliberations, the drafting committee was not totally enthusiastic about all of the changes that it nonetheless adopted unanimously. Many members felt some of the changes should be made optional. This might spawn even more variations of what’s supposed to be a uniform law, and also leads to the question of whether Virginia and Maryland will adopt the new amendments for the versions of UCITA they already enacted. Will legislators who assured constituents that UCITA is just fine as is now admit that it needs fixing? The change most trumpeted by the UCITA proponents is a proposed ban on electronic self-help. On superficial inspection it looks like just about everything UCITA opponents asked for. Of course, it does not close the security holes that have been my primary concern, but I don’t believe those can be fixed without tossing UCITA and starting over. (See “UCITA and national security,” www.infoworld.com/ucita .) But the more I look at the electronic self-help ban, the less I like the looks of it. In the context in which the ban is placed, UCITA will still permit remote disabling of software if called something else. Particularly troubling is a pointed reference to the Digital Millennium Copyright Act (DMCA) as permitting forms of electronic self-help to which the ban will not apply. We’ll need to study this further, but some observers fear the two laws could interact in dangerous ways. Another concern is that, along with excising UCITA’s old endorsement of electronic self-help, the amendment also dropped the safeguards against its improper use. Thus the ban is toothless, while UCITA still shields software companies from responsibility for the damage their remote disabling mechanisms may cause. As much as I would like to never have to utter the words “self-help” again, I’m afraid this is an issue that isn’t going away. Another UCITA amendment whose beauty is only skin-deep is one that purports to invalidate license terms that restrict public comment or criticism. But as it only applies to a product “offered in its final form to the general public including consumers,” it wouldn’t protect InfoWorld or its readers from the real-world attempts we’ve seen of companies brandishing such terms. For example, the case we saw last year where Microsoft invoked its SQL Server (not a consumer product by UCITA’s definitions) license to keep an independent lab (arguably not an end-user) from reporting its benchmark test results would not be affected. Similarly, another amendment that is supposed to limit the effect of shrinkwrap prohibitions against reverse engineering does so but only in some very particular circumstances. Reverse engineering for purposes of testing for security holes could still be a forbidden activity due to a licensor’s unseen shrinkwrap terms. Oddest of all is the free software amendment. At its November meeting, the committee had in front of it proposed amendments from UCITA proponents and opponents, as well as language that was adopted in Maryland and Virginia. Any of them might have been sufficient to solve the basic problem: making sure free software developers aren’t obliged to provide or disclaim an implied warranty of merchantability or fitness for their code. For certain, any of the alternative proposals would have been better than the language the committee came up with — apparently out of thin air — for the free software amendment. The amendment the committee approved doesn’t appear to benefit much of anyone, except maybe Microsoft. Just a coincidence, I’m sure. The committee’s definition of free software is so broad that it fits Internet Explorer as easily as it does Red Hat Linux. The bigger problem, however, is that the warranty exclusion does not apply “if the transaction is with a consumer licensee that is not a software developer.” So free software isn’t free if a consumer acquires it? If you don’t understand the logic here, you’re not alone. The consumer warranty is not a problem for Microsoft because it disclaims all implied warranties anyway. It could be a much bigger problem for some who distribute free software to make certain they aren’t inadvertently providing an undisclaimed warranty of merchantability. But that’s UCITA for you. Even when it tries to put a pretty face on it, you can bet things will soon get ugly. Security