I have a somewhat similar situation where I deliver tools written in Perl into an IBM environment where the client does not want to know about Perl. So we have chosen to use PerlApp from ActiveState, but an equally valid choice would be PAR. This way we can precisely control what is deployed - but all of the dependency testing is kept at the development end which is where I think it ought to be.

We also have some Windows Perl/Tk applications. It is even more important there because you can readily find dll's on many Windows installations that are not usuable. In one case we have to go so far as to specifically remove two SSL related encryption dll's fomr teh system directory. PerlApp has been our friend here too. We can precisely control the Perl environment and I am sure that PAR would do the same.

The legal situation is interesting and we run into this with the IBM user - which is a major corporation. Using a packager we can go through the legal issues at development and maintain the tracking necessary for standards compliance without leaving ourselves open to any risk of changes at the production level.

jdtoronto