I concur. Working Effectively with Legacy Code, by Michael C. Feathers, should be considered the definitive guide book for working one's way through exactly the kind of scenario you've described.

You've painted a very black-and-white, either-or scenario. I think that the anti-copyright sentiment often expressed here on Slashdot is generally targeted against the locking up of our culture by large media organisation with deep pockets used to lobby congress and trample upon individuals with punitive lawsuits.

I believe an insistence that copyright be respected for GPL licenced software sits perfectly well with a desire for a more balanced copyright regime - one with much shorter copyright durations, and where people are free to exercise their fair-use rights without being criminalised by the DMCA.

It's probably worth noting that a chip cheap enough to be economically attractive for use in mobile phones, that can also decode 1080p video, may also be targeting significant other markets. HD TVs and set-top boxes, for example - there's a fair number of those sold each year.

Terminal velocity is somewhat of a red-herring here. If you were to drop a meteorite from a standing start from a high enough point (lets say you're in a hot air balloon), then terminal velocity is the asymptotic speed that the meteorite would approach as the acceleration due to gravity is cancelled out by air-resistance. But an actual meteorite doesn't hit the ground from a standing start. It could have been travelling at many times the speed of sound when it entered the atmosphere. Sure, its trip through the atmosphere would have slowed it down a little, but there's no guarantee that it would have dropped to terminal velocity before striking the ground. I'm sure there are plenty of examples of meteorites leaving impact craters that are many times their size. I'm no expert, but I presume that they would also have had to have been travelling faster than terminal velocity in order to leave such marks on the ground. (Hmm, it's late - anyone know what tense I used in my last sentence? I sure don't!)

Oh my!

IANAL, but couldn't you, as the defendant, simply waive your right to a jury trial. You'd be better off with a technical ruling from a judge in this scenario.

That's true for BT phone lines, but Virgin Media do indead run coax to the house (despite their adverts, where Samuel Jackson's claims that fibre runs to the house).

You're right of course. My original description of finalizers was rather simplistic. The best advice I can give to new Java developers (or C# developers, come to think of it), is to completely avoid using finalizers to dispose of non-memory resources such as file streams, sockets and database connections. It's just too easy to introduce bugs this way, and they're often the type of bug that's hard for a new developer to track down the cause.

There are two common alternatives to using finalizers. The first is to avoid retaining references to non-memory resources, wherever possible. As bckrispi mentioned above, it's good practice to close sockets and file streams as soon as you've finished with them (or in the case of database connections, relinquish then to a common pool).

The second is to expose lifecycle management methods on your class, typically by providing a close() or dispose() method, which passes the responsibility of lifecycle management to the code using your class. Needless to say, the first option is definitely preferred over the second.

In 15 years of Java and C# coding, I can honestly say that the only time finalizers have been useful is in trying to detect the case where client code hasn't invoked the relevant close() or dispose() method, in order to issue a debug logging call so that this can be trapped, and then make a final attempt to call close() or dispose() within the finalizer and hope for the best.