The simplest definition of ‘open source’ is: ‘can I fork this and use it?’ If the answer is yes, company B (or university B or person B …) can make a copy of the code originally written by company A and try to commercialise services around it. However, company B might also decide that working on company A’s original code is more useful to their goals.
If however, the original code-base managed by company A needs certain characteristics to remain legally and commercially viable for company A, but which don’t fit the goals of newer participants on that code base (maybe they are researchers who want to remove some safety aspects to do interesting experiments), company A can always fork that code base to a version that only it manages, to ensure its purposes are satisfied, or convince the others to fork into a research version.
One of the key questions therefore with respect to any code-base is: what specific goals does this code-base need to fulfill? If those goals include things necessary to continued provision of a commercially supported solution by several companies, then people who want to do incompatible things … will need to fork.
‘open source’ doesn’t mean ‘anything goes’. Just ask the developers of Postgres or the Linux kernel.
For these and other reasons, the process of ‘open sourcing’ an existing major code base isn’t an instant thing, and it is not a binary situation.