I feel bad ripping one in the crew that builds DVD Flick, a well regarded open source tool. From what I can tell, this is a fully-open, Sourceforge-hosted, quick-authoring tool similar to the excellent ConvertXToDVD.
During its installation, though, it attempts to overwrite the richtx32.ocx file in the windows/system32 directory. Richtx32.ocx is a Microsoft-authored GUI widget component (an AcitveX library) present in all or most Windows systems.
Trying to overwrite this is bad on so many levels. Who knows which version of this lib is being supplied by DVD Flick? The installer definitely doesn't compare versions and make an intelligent choice, or it would have chosen not to even try on my systems, where everything is up to date. So it's an old version, maybe one with bugs or security vulnerabilities, that could compromise my system because any process might load this code up.
Not to mention it appears to the user that the app needs to alter their system in order to continue. Since they trust this app (it's been written up in blogs like LifeHacker), they start thinking "oh, sometimes free apps I download off the Internet need to overwrite my system libraries, no big deal" ... all the UAC in the world won't be able to overcome that mentality (although theoretically Vista has other protections to remedy this specific problem).
I tried to think of any justification for this behavior, but I couldn't. True, there are aspects of the ActiveX/Registry/DLL Hell problem that can make something like this a little tricky, but there are workarounds as well.
Starting with the easiest fix: include a legit Microsoft merge module containing the latest DLL version, and first, in the installer script, check the installed lib version/signature to see if it's necessary to install a new one at all.
The other possibility, that DVD Flick isn't trying to update this library, but needs to install its own version on top of the existing one, with some extended functionality, would be even more ridiculous... I entertained this idea for a moment, but it appears not to be the case.