Well, VICE is GPLv2 licensed, so you're free to tivoise it. I'm not sure what Spectrum emulators they looked at, but if all the ones they were interested in using were GPLv3 licensed, they'd need to get it relicensed to be able to use it in a commercial product I think.
For the Vega, it was a home-grown emulation written in-house. For the Vega+ with the departure of the two directors, they used Fuse, the Free Unix Spectrum Emulator that's under the GPL. Of course, that's not been released as of yet.
That menthod of removing lag is interesting, but suboptimal I'd suggest. Any test like the one we saw that illustrates the lag by flashing the screen or beeping will still show lag between the joystick being pressed and the indicator being received, and a game like sonic would show two frames of him tapping his foot before he'd suddenly running two frames forward including two frames of distance travelled. You'd miss two frames of animation, if any C64 games have non-repeating transition animations like that. Perhaps it's not an important disctinction when it comes to 8-bit games, but I wouldn't like to see an approach done on anything 32-bit or later, from about a decade or so on. Just imagine Street Fighter 3 Third Strike crippled like that!
At the risk of derailing this thread, I'll go on. You don't lose any frames at all. Consider Sonic again:
Emulate a frame of CPU work, including graphics. Save the state in a two-frame buffer.
Emulate another frame, save that state also.
Emulate another frame, but detect user input - so re-load the first frame from the buffer.
Now, with the user input present, re-emulate both stored frames (and this third frame) without disturbing the display.
Display this new frame.
Continue, using a rotating pointer to the state buffer.
Because emulation is not time-bound, the user notices no missing frames because instead of Sonic starting his running animation two frames from now, he starts it on the same frame the user initiated the action. The effect is that input no longer has a lag of two frames and appears immediately responsive to the user.
Now, it's not authentic as Sonic has been coded by the original authors with a two-frame delay for input-response on the original hardware. But it does present an interesting mechanic. All the user has to do is tell the emulator how many emulation frames the game will skip before responding to input. And it will glitch if the game doesn't actually wait that long, you have to know what the input lag was originally. But for hardware that has built-in lag, it will be very interesting indeed and useful to overcome it.
Possibly.
