Not OSS != no source access. A cloud provider on top of the MS stack would most likely have Shared Source Initiative licenses.
Licensees may use the source code as a reference or view within a debugger,
but may not modify the code or use it to create derivative works.Furthermore, no source access != no way to fix problems.
People have been fixing things with no source for ages, EULAs be damned. If the fix is literally flipping a single bit, the decision is easy. Just do it. The vendor doesn't need to know nor care what we did to fix it, but often giving a detailed description to them of the problem --- one that comes out of the process of fixing it --- will help them fix it quickly and distribute to their other customers too. I've had this experience a few times.
Obviously, "the byte at 0x73F441 of somefile.dll should be 31, not 32" is not how you should communicate such things to the vendor, but they do appreciate your effort in debugging the issue instead of immediately blaming it on a fault in their software. ;-)
(And relatedly, no source access != no way to find problems either, as the security community shows quite plainly...)
`git clone` is an incredible power. Companies should reward those who are generous with their code.
Careful with those goalposts, you're tearing up the pavement.
> Companies should reward those who are generous with their code.
So companies "should reward those who are generous with their code" but not compensate them for it?
No, they absolutely should compensate them for it. Buy OSS.
This issue didn't get solved particularly quickly, either. Nor was "source to the whole stack" required -- kernel source made for a illustrative blog post but was not really part of the process.
Do you have source files for the CPU? The motherboard? Your DRAM controller? At some point you draw the line and make shit work. Tools plus docs plus code is great, but you can make do with just one of 'em in a pinch.