The music world is going soft — but the economics of software production run up hard against the inadequacies of software protection. Cutting Edge speculates on a possible solution.
We've talked about copy protection a lot in Cutting Edge — probably too much. I've always said that copy protecting music is impossible, and I still think it's pretty much a no-win exercise that can leave a lot of crippled equipment and frustrated consumers in its wake. But there are big differences between music and software copy protection, because there are big differences between music and software.
To put it simply, you can't hear software. You can hear the results created by DSP software, but what you don't actually listen to is the DSP program code itself. (If you could hear it, it would almost certainly damage your loudspeakers). This distinction is important, because no matter what you do to stop digital music arriving in the wrong hands, as long as you can hear it, you can copy it.
It's worth looking for a minute at why we should be concerned about software piracy. Then I've got a potentially rather neat solution to it. But first: why does software cost anything at all?
Soft Sell
The reason is that software is the non-corporeal equivalent of a very complex machine. Think of a VST plug-in and you'll see what I mean. The fact that it does literally look like the machine it is supposed to be emulating helps, perhaps, to illustrate the amount of work that goes into creating it. Yes, once it's written there are practically no material costs in distributing software — especially via the Internet — but employing some of the brainiest people on the planet to write the software doesn't come cheaply. Add all the costs of developing a software product to the duplication and distribution overheads, plus a modest margin, and what you have is the price of a software package on the shelf (or virtual shelf, in the case of the Internet).
All of this is fairly obvious, as is one of the conclusions that proceeds from it: the fewer copies of a software product that are actually bought as opposed to copied, the scarcer the funds, or indeed the inclination, to support and — most importantly — develop the product. I always find it amazing that the bulletin boards of the most famous music software products are at times populated by people with an illegal copy of the software, asking for support. In such cases it's not clear exactly where the money to pay the support team is going to come from.
Now, I'm the first in line to complain that some software is overpriced, but I would suggest that that's rarely the case with plug-ins, which always cost a small fraction of the price of the physical unit they are emulating (and rightly so, when you consider that there are no materials or manufacturing costs) but which have such extraordinarily powerful capabilities. The current copyright laws simply don't work, and some of the proposed legislation to replace them is so draconian as to be almost beyond belief, but copying music software isn't just about the law: it's about whether or not we want to be able to buy such innovative, powerful software in future.
There will always be people who copy software, and you can understand the need, from the manufacturers' point of view, to protect their products. The thing is that even if you support the idea of software copy protection, virtually every way of implementing it so far is almost universally disliked. I have an idea for an answer for this, which is based around the idea that copy protection normally pisses people off, so you have to give them something in return for it. But before I elaborate, it's worth looking at how copy protection is done at the moment.
The Angle Of The Dongle
There are really only two main sorts of copy protection, with several variants. My favourite (which is a bit like saying that the common cold is the world's favourite illness) is the dongle. As almost all of you will know (possibly only too well), it's a physical device that, once plugged into a suitable orifice in your computer, acts like an ignition key. Without it, you can't start the program. Until recently, dongles normally went into a parallel port and would 'pass through' any other parallel data unchanged. One of few real problems with them was that if you had several programs with dongle security you could find yourself with cascading dongles, drooping alarmingly But let's not go there!
Nowadays, dongles tend to be USB based, which is much better. They're just as easy to lose, though, and you should always insure your dongle for the full value of your application software. Manufacturers will happily replace a damaged or faulty dongle, but they certainly won't replace a lost one. Dongles can go wrong and dongle drivers can get corrupted. Either way, there's a possibility that you might be in the middle of a project and suddenly be locked out of your software.
But that danger is nothing compared with what you face from 'Product Activation'. I've covered this before in Cutting Edge, so I won't dwell on it. And, to be perfectly fair, the product through which most people first encounter Product Activation, Windows XP, seems to handle this type of rigorous registration process fairly painlessly. However, that isn't necessarily the case with some of the more specialised applications. One well-known video-editing program dropped its dongle protection a couple of years ago and introduced online Product Activation. This caused so much trouble for its mainly professional users that they had to re-introduce a dongle protection scheme a very short time afterwards. There are other disadvantages to this type of protection too. Recently, I heard that the professional user of another software package decided not to connect his machine to the Internet, to ensure that nothing nasty got on to it. Unfortunately for him, he had to go online to activate the software. During the minute or so that he was connected, he was hit with a nasty virus and had to reinstall the entire machine. Of course, this example doesn't necessarily militate against Product Activation but it does highlight one of the dangers of using it. Compared to these, I prefer a dongle any day. But if we're going to have to use dongles, why not make them do something useful? Why not make them an integral part of the product? It's really only a question of topology.
In the dark ages, as much as six or seven years ago, if you wanted to do audio editing on a computer you'd probably have to plug in some kind of accelerator or co-processor. This would normally come in the form of a PCI- or ISA-based I/O card that might even have its own SCSI controller on board. Such cards normally came with software that was closely associated with the specialised hardware. Examples include Pro Tools from Digidesign or (obscurely) Studiotracks XP from Spectral Synthesis. Since the software for these systems was tied into, and in part actually ran on, the hardware, the specialist plug-in cards themselves acted like giant dongles. Nobody quibbled or complained about this, though, because it was clear that you needed the cards to make the whole system work.
Take-Away Software: Another Idea For Dongles
Why stop at turning dongles into hardware controllers? Why not store the application itself on them? What's prompted this thought is the sudden and massive popularity of small USB storage devices. I don't see why manufacturers shouldn't deliver their applications stored on these removable devices (sometimes called 'pen' drives), and require that the device is present while the application is run. The downside of this is that it could be a nuisance — although possibly no more so than having to insert a 'dumb' dongle. The upside is that your application would be portable. You'd simply carry it round on your USB device and load it up onto any available computer. There would have to be a lot of thought about how the operating system dealt with these 'removable applications', since you wouldn't want to inflict all sorts of registry detritus on someone else's computer just because you'd borrowed it to run Cubase SX. But if new applications were designed from the ground up to behave like this and the OS was aware of portable software, I don't see any problems.
In time, USB flash storage would be big enough and fast enough to save your project and media on as well. Imagine being able to work in a studio all day, then bring the day's work home — in editable form — to carry on working with on another computer. And then there's Ultra WideBand (UWB), a wireless connection that works at hard disk speeds. (Imagine Bluetooth with the same bandwidth as FireWire.) It's not here yet, but we'll be keeping an eye on its progress. If we had something like that, there would be no need to plug software-protection devices into your computer at all. Your computer would download and run the software, together with the media, while the device was still in your pocket. Perfect. Until your wife put your trousers in the washing machine...
Something For Something
Perhaps this is a position we need to get back to — and indeed, one or two manufacturers are attempting to, in a piecemeal way. (An example is the TC Powercore system, which offers a benefit to the user in return for requiring a dedicated hardware component to be used with plug-ins.) So maybe we need to make people want the copy-protection device because it's a useful thing to have in itself. One way to do this would be to make a dedicated hardware controller for plug-ins a necessity. For example: let's say you're a manufacturer of a new and radical software synthesis plug-in. In today's climate, the chances are that if it's good, illegal copies of it will have swamped the potential customer base within a few weeks, with only the completely honest ones actually buying a legitimate version.
But what if the software was designed to actually require a hardware controller to be connected to a USB port before the program would work? The benefit is that you could have a superb looking synth controller in your studio, with hands-on control and feedback available in a way that will forever be missing from a software-only version. It might not necessarily be much more expensive, either; because the chances are that so many more people would buy it that the additional income would pay for the development of the complex hardware. In any case, I'm sure that someone could develop a design program that would interpret the way a software program works and lay out a physical control surface complete with the appropriate controls.
Much thought would need to go into the implementation of such an idea: after all, some people use many plug-ins for their individual strengths, and it could obviously become impractical to have controllers for 20, 30 or more plug-ins littered around the studio. I would say, though, that a lot of those people who use many plug-ins may well not have paid for them all. Introducing a method such as I'm discussing could do away with the mass collecting of illegal copies and encourage people to fix on a realistic number of quality plug-ins that they've actually purchased.
Imagine a program like Reason with a rack of physical controllers for all the wonderful devices in the software. I'd buy it even if it cost four times as much. (And if you're thinking that this is missing the point completely — for example: Reason lets you invoke multiple instances of devices — all you'd have to do would be select which 'instance' of a device the external controller is supposed to represent.)
Well, that's my suggestion. These are only ideas and I have no idea whether they would be cost-effective or would even stand a chance of working commercially; but I would personally love to see it happen. Maybe if it took off, manufacturers could devise a standard physical format for interlocking controller devices together: 19-inch racks are all very well but why not figure out a space-saving version that doesn't involve all the nuts and bolts that make assembling a physical rack such a laborious process?