Last month I wrote a post in response to another blogger's comments on a story in the Seattle Times about the issues Seattle public schools were having in dealing with a legacy VAX student scheduling system which was on its last legs. The other blogger, Nick Malick, suggested that perhaps an open-source project could create software to replace the scheduling system; a way of leveraging volunteers and open source concepts for the general public good. My take was that this is often much easier said than done, that open-source projects are best used to scratch an itch, and that coordinating volunteer labor on software projects can be more complicated (and therefore, more expensive) than off the shelf software. In that vein, I suggested that perhaps an existing open-source project, say, a VAX emulator, might be the better solution.

It so happens that there was more to this particular story, though, and I thought it might be instructive to take a look at some of the additional complications and reasons that Nick may be right and I most likely was wrong.



It started with a comment from Stan Quayle, a consultant who specializes in VAX emulation solutions structured around CHARON VAX. Stan, as it happened, had already discussed the emulation option with Seattle Schools, and found that they weren't interested; it wasn't the VAX they were unhappy with so much as the program running on it. Although this wasn't what the Times article implied, it was understandable that they play up the "antique hardware" angle. But it turns out that even if that were the case, simply picking up an open-source VAX emulator isn't a solution: it's prohibited by the licensing.

Quayle says that CHARON VAX is the only supported option for VAX users hoping to move to a virtualized platform, and that HP, which has inherited the rights to OpenVMS after a complex series of corporate mergers and purchases, wants a minimum of $2000 even to allow that. As if that weren't complicated enough, it turns out that many of the component modules, programs, and languages that made up the VAX/VMS packages which were originally sold to many users have been sold off separately, and are goverened under separate licensing agreements, some of which allow no transfer at all.

It's easy for some to say that these are dead and unsupported systems, and that the many trivial workarounds that are available to move VAX images off their creaky hardware and onto free, open-source emulators are good enough, but that's an unsatisfactory approach for several reasons. One, it does violate legal agreements. Two, it often obviates support arrangements. Three, it dodges the real issue, which will only come back to bite us in the future: oppressive licensing agreements of this sort are still commonly issued today, and they are increasingly being enforced by mechanisms in the software itself.

This is terrific for the software vendors of the world, and it doesn't bother a lot of IT folks I know, who seem to have the attitude that if you don't upgrade everytime an upgrade is available, everything is your own damn fault. This is a ridiculous attitude; compare computers to any other big-ticket product and try to make the same argument. Who in their right mind invests that sort of money and expects to throw the product away in eighteen months?

So in the end, without retracting my arguments about the negatives of the approach, I think perhaps Nick was right to call for a newly developed open source project to fill needs such as these. It's not because open source development is the best solution... I continue to maintain that it's far from it. But the GPL, and other open software licenses, are the best solution for users who find a product they need or use, and don't want to be cornered by aggressive licensing policies years down the road.