The handling of configuration files is described in the XDG Base Directory Specification.
It defines a set of related path environment variables like
XDG_CONFIG_DIRS, which define, for example, where the
.config directory is by default, and how to handle it in various other controlled ways .
Very common is obviously the form
~/.config/product_name, and when it's about only one product of the company,
~/.config/company_name would not really be different.
But assuming there are multiple products - I think that the structure
makes much sense;
I do not know whether it's described in these or related standards. But it can be that the XDG standard would see that as a normal product directory, only that it sees the whole set of software of the company as one product for that purpose.
The general standard use of the fielsystem hierarchy is described in the Linux Filesystem Hierarchy.
As a place for the application itself, take a look at the
/opt directory; You would install the application in either
/opt/company_name/product1 etc or
/opt/product1 etc, both is correct according to the standard.
You found out yourself that the
/srv directory could be a good option.
I agree it is the right solution - so I describe here to have it in an answer:
/srv is similar to
/opt - the standard does not say much about the subdirectory structure, you can use the same separation as above.
/opt is explicitly intended for readonly application code, like executables, static data files and documentation,
/srv does not restrict much about the variability of the data; It even allows mixing files with different access permissions and variability.
For example, it would be acceptable to deploy files there that can be changed in place by users of the system.
From Linux Filesystem Hierarchy: 1.19:
This main purpose of specifying this is so that users may find
the location of the data files for particular service, and so that
services which require a single tree for readonly data, writable data
and scripts (such as cgi scripts) can be reasonably placed. Data that
is only of interest to a specific user should go in that users'
The methodology used to name subdirectories of /srv is unspecified as there
is currently no consensus on how this should be done.
To manage the access permissions to the data that needs to be writable to all users of the software, you should use permissions assigned to a group, that contains all the users.
That is true even when "all users of that computer" would be in this group - there are many system users that should not be able to write the data; An attacker may get access to one of the system user accounts.