I’m writing this page using Mozilla’s Composer application. I’d normally use Macromedia’s Dreamweaver MX for this task. Dreamweaver is definitely a more powerful and convenient tool; Composer is downright primitive by comparison. But I’ll suffer the inconvenience of more clumsy tools rather than upgrade to Macromedia’s latest Studio MX 2004 suite.

Why? Product activation.

For those who aren’t familiar with product activation yet, it’s basically a fancy form of copy prevention that makes it difficult to install software on more than a fixed number of computers. While the idea has been around for a long time, Microsoft was the first mass-market software vendor to widely deploy it. In most current versions of product activation, a number of hardware characteristics are mashed together in order to form a unique hardware ID. The hardware ID and a serial number provided in print form with the product are sent off to a license clearinghouse, which validates the serial number and then issues a software license (basically a digitally-signed certificate) if the serial number hasn’t been used too many times. Every so often, the software checks to make sure the license is valid, and that the hardware hasn’t changed too dramatically. If there’s a problem, the user is locked out of the software until the vendor issues another software license.

In principle, this doesn’t seem that bad so long as the process is transparent. But product activation actually fundamentally changes the relationship between software vendor and consumer. Instead of purchasing the right to use the software in perpetuity, you’re really just leasing it now—you just don’t know for how long. Maybe the vendor will be around in five years when you need to reinstall the application again for some reason. Then again, maybe they won’t. Or perhaps they’ll be around but would really rather have you purchase an upgrade to the latest version of the product. Maybe they’ll need to charge you a fee for that activation in the future. Maybe you’ve upgraded your machine one time more than they think is reasonable. Or it’s possible that they’ll get into a dispute with another company over patent rights or product ancestry or one of the myriad other things that tech companies fight about. While a dispute of this sort can always cast uncertainty onto the future of a product, the activation process means you’re potentially a victim since you have to ask permission to use the product every time you install it.

To add insult to injury, the license enforcement code does low-level manipulation of the hard disk (writing unspecified stuff into what it considers to be “unused space” on track zero of the hard disk). Maybe this will work well. Then again, maybe it will trash people’s disks, as some unlucky users of Intuit’s TurboTax product activation scheme discovered earlier this year. Fortunately for Macromedia, their ridiculously lopsided end-user license “agreement” protects them against having to compensate you in any meaningful way should their software trash your machine.

So, I won’t be purchasing any upgrades to Studio MX.

I also discovered the other day that I’ll be switching from Norton Antivirus to another vendor’s product. Product activation isn’t quite so odious in principle on a product which depends on a steady stream of updates to be effective, but it’s still an unnecessary hassle for the honest customer. I might wind up using McAfee’s VirusScan product, or there’s always Grisoft’s well-regarded AVG product, which is even available free to noncommercial users.

As I’ve spent some time reflecting on the mechanics and implications of product activation, I’ve reached the conclusion that this ugly turn of events is likely to be good for open-source software.

I’m not the only person who’s going to abandon tools saddled with product activation technology whenever it’s reasonably possible to do so. I’m probably not also not the only person who will first consider open-source tools when searching for a replacement for a commercial tool gone bad.

My luck thus far has been pretty good. On my desktop machine, I’m using a no-activation-required volume license for Windows XP and a similar volume-license version of Office XP, so I’m not in the position of having to immediately replace my desktop environment. But I do find recent developments in desktop versions of Linux to be encouraging, and I downloaded a recent version of the OpenOffice suite and was pleasantly surprised with its performance and flexibility. Though I also own a copy of Adobe’s PhotoShop application, I understand the next version is slated to inflict product activation technology on its users. So, I won’t be upgrading. I’ve downloaded and installed the Windows version of the GNU Image Manipulation Program (GIMP) and believe it will meet my needs (which I’d characterize as intermediate to advanced) adequately. I’d frankly rather be using PhotoShop, as it’s still a slicker and easier-to-use product, but not at the cost of enduring product activation.

On the server side, the latest version of Windows (Server 2003) requires product activation when not installed with a volume-license key. It’s foolish to even consider deploying mission-critical technology that can fail just because some piece of otherwise-unnecessary license management software decides it’s unhappy for some reason. The good news is that a very large number of server-side applications can be managed using tools such as Linux, MySQL, PostgreSQL, Apache, and PHP; in many if not most of these cases, the open-source applications are already better and more feature-rich than the commercial applications they supplant.

And, I think the software economy will ultimately be the better for it. I’ll continue to buy products and services where it makes sense to do so, but the migration to open-source software helps ensure that I do so on my own terms and that I’m always in control of my data and applications.