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. ;)

Well, it depends...

A core module is one that is shipped along side the perl source/binary. A non-core module would, obviously, be any other module. However, some core modules lead dual lives on CPAN. These modules, once they have newer versions released to CPAN, will later be re-integrated back into the core.

A third-party module would encompass, i believe, not only all modules found on CPAN, but those shipped with other applications or available for download elsewhere (such as sourceforge).

I hope that makes sense. :) -- someone please correct me if i'm wrong.

A core module is one that is shipped along side the perl source/binary.
Almost.
Core modules come with the perl sources and reside in archlib ("perl -V:archlib").
They (like perl) are maintained by the perl5-porters.
Module::CoreList

"In a contract or transaction, a third-party is not a direct party of the contract, but has an indirect involvement."*

In this usage, "third party" refers to someone not involved in giving you the core Perl distribution. I'm so used to hearing this used in this sense in either software licensing or other computing related contexts that using it in relation to non-core modules seems pretty clear. Then again that may just be me . . .

* – Quoth one of the results for define:third party

I don't like the term third party, since I'm not quite sure what it means. I prefer to make the distinction this way. There are standard modules that come with Perl, CPAN modules for common problems, in house code for our particulars, and out house code for things given to us by vendors.

Phil

Heh. "out house code" - does that refer to where it was developed, or the quality of the code?

:-)

-- WARNING: You are logged into reality as root.

Out house code just started as the opposite of in house code, but as soon as I said it in the office everyone realized the benefit of the term, since it suggests aromas that tend to eminate from such code.

Phil