One point that needs clarifying, that is not touched on in Ovid's or tilly's reply, is the definition of the term "module". A loose definition of a module, as a collection of related subroutines is useful for resolving the question, but may lead to confusion if you get deeper into the subject.

The loose definition includes modules (*.pm), libraries, packages and distributions.

libraries

Putting your common reusable subroutines in a .pl file, a Perl library, is the traditional perl 4 way of doing things. Such libraries are loaded in at run time, using require 'foo.pl'.

packages

Suppose you are coding a Perl script that defines a subroutine called load_data. You are using the library common.pl which is a collective effort, and you don't know everything that it has inside. In particular, you don't know that your colleague Fred already has a sub called load_data.

Packages avoid this problem by providing separate namespaces. Hence we might have Application::load_data and Reference::load_data as distinct, separate subroutines. So, this involves more typing, but provides a software development model which works better (the extra typing may be avoided by importing, see below).

modules

Perl 5 introduced the concept of Perl module (.pm) files, which may be "require"d at run time, but are more often "use"d at compile time (BEGIN time). Modules usually declare their own package namespace, but sometimes .pm files may populate more than one namespace.

Importing of subroutine names is also available with "use".

use MyModule::Clever qw(foo bar)

...
my $wangle = foo('fleeg') . bar('dingle');
[download]

In tbe "use" declaration, we have told MyModule::Clever that we want to import the subroutines foo and bar into our namespace.

Modules can also provide an object orientated interface, but this is beyond the scope of this reply.

distributions

The tar ball kit that one downloads from CPAN is sometimes referred to as a module, but the correct term for this is a distribution. Distributions contain one or more modules, and also unit tests, documentation, example scripts, etc.