Your term should reflect the distinction you want to make. You don't need to label a particular module with only one term. Use the one that fits in context to what you want to communincate.

I call things not shipped with Perl "non-core" modules, as in saying "it has non-core dependencies" (which is usually the only reason I use such a term). This a pretty big group of things. To make it even more difficult, the same module can be core or non-core depending on the version of Perl.

I use "CPAN modules" to refer to things I can install from CPAN. That sounds stupid until you realize that some core modules don't live on CPAN and you get the newer versions when you upgrade perl. ExtUtils::MakeMaker wasn't a CPAN module, but now is, for instance.

I use "vendor modules" to refer to those that I get from applications not distributed through CPAN. These are typically SDKs, etc. I think I might have used that term to refer to things in the OS's version of Perl when the distro adds extra stuff. Typically this means I'm saying "you're screwed on updates and you need to fix these yourself because there is no support".

I use "local modules" to refer to, well, locally produced modules that are intended for internal use only. They aren't the sort that make it onto CPAN, either because of the sensitive information they may expose or not being perceived as useful to anyone outside of the local situation. This is different than locally produced modules intended for CPAN.

"Third party" is tougher, because you have to figure out the relationship of the source to what you are doing. If I get modules from a vendor under some sort of agreement, they aren't a third party, really, because they are directly involved. If I use those same modules with a different client, then between the client and I the source is third party. This term is all about relationships, and that doesn't come into it until you know the situation. ;)