A lot of responses have focused on the warn aspect. And, while they're interesting, I think they're missing the bigger question, though haukex touched on (first, where it belongs, IMNSHO).

YES you should close filehandles you don't need. Modules that reference DATA should close DATA when they're done. IMO, this is a bug in the module you're using - it is leaving open a filehandle, which is a (relatively) scarce kernel resource, instead of closing it. With normal filehandles, you can (mostly) get away with using a lexical, and letting perl auto-close it (though I've read a few places indicating this is bad - you should explicitly close it and handle the errors that may result gracefully). But since DATA is a global, you get no such help. And so it stays open for the life of the program.

For many programs, this turns out to be not that bad - it's a waste of resources, but the program runs, it dies, and everything gets cleaned up. That's nice. But if your app that uses said module has use for many filehandles (I had one managing stdin, stdout, and stderr for many parallel subprocesses simultaneously - 3 times the number of subprocesses right there, and we could run dozens of subprocesses), you may find that a bunch of modules chewing up filehandles needlessly could prove limiting. Now, again, in my case, I was probably fine - the systems were large which meant we didn't need as many subprocesses, but if I had to deal with a cluster of hundreds of machines (each subprocess was an ssh to another machine), this could have been annoying, without adding a burden from modules' bugs. And the fact you can get away with it for so long is why most developers don't even think about it.

So, all that is nice and all, but what to do in your particular case? Well, some have helpfully suggesting a warn workaround. To me, that's still a workaround, albeit quite cheap. (It's not so cheap when you start to lose the extra information that could help debug other problems when it isn't giving you grief about this one.) Better would be to go to the original module owner with a bug report. However, given that the module hasn't been updated in over a decade, this may not get you anywhere. In this case, you may need to look at taking over ownership of the module so you can fix it and post it. Or you can just use a forked version locally, but I prefer the giving-back option over the not-giving-back option.

Best of luck,