To me, it's "system software" when it's intended to be a building block for other software. The important implication of this is that various potentially impor

To me, it's "system software" when it's intended to be a building block for other software. The important implication of this is that various potentially important requirements are unknown. Performance, load, memory, scaleability, regulatory, security, platform, CPU, etc. If you're successful, your users (developers of apps or higher-level systems) will be using your software in ways and for purposes you can only partially know. You have to deal with that somehow. Maybe you can design your software to be agnostic to a concern (e.g. if your protocol uses a TCP stream, your users can adopt SSL as needed). Maybe you optimize for the concern as much as is feasible (this is why performance is such a concern for "systems programming languages... there is no acceptable level of performance, you want the performance overhead to be as small as feasible. Maybe you miss a concern that is important to your potential users and fail.