It's not really the developers installing their own toolchain you have to worry about here, though. The folks working on the official builds and deployment should be far more aware of what's happening, because that's what has to be supported. If you're letting B&D do things willy-nilly, that's a serious business problem.
I aware they're often the same folks (DevOps), but your senior engineer and/or project manager should be watching what's going out.
Back in college, I created a small desktop app that played a WAV file when any key was pressed, but could be closed silently with the mouse. (Its purpose, along with a recording of me screaming, was to train my cats not to sleep on my laptop.) It would have been written in Java 1.4 or maybe 1.3. The applet library was a pretty standard way to open and play an audio file, because it was simple.
Fast forward a few years, I came across the app again and decided to see if it still worked. It didn't work with the existing JRE on my box. So I rebuilt it with a more recent JDK (1.6, I think). It built, but it still didn't work.
See, Java 1.5 AKA "Java 2" had a new memory model, deprecated a lot of things (like applets), and started modernizing heavily. They attempted to maintain backward compatibility, giving us things like the awful erasure-based generics, but it really wasn't fully BC. They really should have just done what Python did with Python 3 and make Java 2.0 non-BC.
This isn't an isolated incident, either. A major project I worked on updated from Java 1.6 to 1.7 and it broke several things. They were fixed pretty quickly, but it still wasn't truly backwards compatible. It's just like the Java claim that you can write once and run anywhere, which is only half-jokingly referred to by devs as "write once, debug everywhere".
If you don't care about all aspects of your software, including security, ethics, and legality, you are not an engineer. Engineering implies professionalism.
It's debatable whether there are any true software engineers (we're certainly not licensed like traditional engineers), but all software professionals should be concerned about licenses. It's part of the job, as are all ethical considerations of your work.
I aware they're often the same folks (DevOps), but your senior engineer and/or project manager should be watching what's going out.