The "you" here is nebulous. Games are made by a studio, but are often
ported by that studio's
publisher, who will often then subcontract the porting work to some other development house.
(Why? Because the original studio is busy making other new games. Or because the publisher got the game produced as a one-off work-for-hire, so the original studio has no ongoing contractual relationship for the publisher to lean on. Or, sometimes, because the studio is defunct, but customers are still interested in getting new ports of the game, so "you gotta do what you gotta do.")
Publishers can't change what engine a game is written in; and there's certainly no positive ROI in a ground-up rewrite. They just have to cope with the game's codebase as-is, relying on combining small tweaks with techniques like emulation/virtualization to get the port shipped. Pushing to get the target platform to natively support the APIs the game uses, is just another such strategy.
> Microsoft proprietary APIs
What is a "proprietary API"? APIs aren't IP. Even in Oracle vs. Google, the copyright case had to focus on plagiarism of header files, not of the API.
The moment there's more than one (popular) implementation of an API, its original creator loses de-facto control over it. Third parties interested in using that API will almost always focus on the lowest-common denominator subset of the API supported by both implementations.
Which is to say that, if anything, Linux implementing DX12 would be bad for Microsoft's control over DX12, since it means that Linux could "hold DX12 features hostage" by refusing to implement them. Just like Chrome and/or Safari are currently holding a lot of HTML5 features hostage from appearing in most web-apps, by being a hold-out on implementing them.