I would call them “public modules” because they are publicly open sourced, not private.
Calling them “private” modules is irrelevant and misleading considering that you can only require uncopylocked modules (since the update) - which appeared to cause confusion earlier.
It’s been called PrivateModule since forever, it’s your opinion to call it PublicModule, I never asked about how to use someone else’s Module either in the OP, I only intend to use my own Modules.
In the Wiki it’s also called Private Module, I’m not the one deciding what to call it, I am using it as a reference since it’s most relatable and official.
Note: “Public modules” is a relevant name for other people’s modules.
On the wiki it’s lowercase “private” module because it’s simply describing the behavior of a module script FYI - meaning that you can call it whatever you want based on its purpose.
Since the update, private modules on Roblox appear to have become more obsolete considering that only the publisher has access to the code and accessibility, and that you can simply have the private module within your game’s file.
There’s no point nitpicking the terminology being used.
Only those who use private modules as a business model have actually faced any regression or complete roadblocks with the update. Those who made open source utilities or those who are using their own modules are not facing any trouble with the update.
I’d personally switch over to packaging your modules or keeping them in the DataModel. I personally don’t use id-based modules anymore and I never really have except for running novelty code on other games (i.e. welding aesthetics to my character). DataModel modules always win. In production, you typically would want your resources available as soon as possible as well (save for any module-based hierarchies incorporating lazy loading, which then their implicit presence isn’t as necessary).