And I'm talking about how indie developers often don't have the time (and may not even have the skills, if they're depending on 3rd-party tooling) to watch for when "included with the system" becomes "not included with the system" and release an update.
And how do you expect these developers to provide security support for their bundled libraries when they do not even have the time or the skills to check if that library is included with the system? Seriously, then they should do another job.
(In essence, you're taking the idealist view and I'm taking the pragmatist view.)
No. Doing software development that way is criminal and should be treated as that. Imagine a car manufacturer which does not "have the time" or the skills to check if their built-in seat belts work ...
Edit: Software is more and more getting a critical part of our infrastructure, of our lives. It's about time software manufacturers have the same responsibility for their products as any other manufacturer already has.
Obviously we're not going to see eye-to-eye on this. If I'd designed the system of laws, attempting to enforce your viewpoint on games and other digital forms of artistic expression would have a name like "criminal suppression of cultural exchange".
Besides, even if it were possible to enforce that politically on a global scale (Which it isn't. Just look at how the movie industry failed to stamp out code like DeCSS and at the ongoing failures
to block access to sites like The Pirate Bay. In fact, there are good arguments
to be made that attempting to do so is a human rights violation.), it's impossible to enforce on a technical level.
I'm a Computer Information Science major and one academic paper I read on the subject summarized its findings by analogizing the inherent fragility of software to the golden gate bridge collapsing to dust because not enough force was applied when tightening one single bolt. (And we can't fix that in the near future because the only reason the world is so robust is because it's unimaginably, massively redundant. A bolt is a cooperating collection of countless sub-microscopic bonds and we don't even have the processing power to add "just turn it on" support for soft-body physics and fluid dynamics to the full ecosystem of ready-to-run physics engines yet.)
I firmly believe that the solution is better sandboxing, better support infrastructure for developers, and a push to make as much of the game code as possible commonly maintained.
1. Microsoft, Apple, and the Linux ecosystem are all working toward OS-level sandboxing for applications, which should provide a first layer of protection.
2. The various Linux desktop projects which work together via FreeDesktop.org are working on a cross-distro solution for package metadata.
3. The Rust programming language looks very promising as a C/C++ replacement which can rule out entire classes of bugs across wide swathes of code.
4. As the games industry matures, more and more code is becoming open-source, which sets the foundation for something like "Game engines can update independently from the games that are built on them. On Linux, games depend on a system-provided engine" to become feasible.
(Think "system-provided ScummVM/DOSBox/etc." on a massive scale.)
If you're not familiar with Rust, it's a Mozilla-developed language intended to replace C++ for writing programs like web browsers which must be both high-performance and high-security. It gives you VM-like safety guarantees without the overhead of a VM by verifying safety invariants at compile-time and Cargo, its combination package manager and build automation tool beats every other language I've tried for making it easy to publish as much of your program as you want in the form of small, cooperating components.
Rust is specifically designed so it can call C code easily and you can generate a C-compatible library in it, so you can upgrade your program piecemeal. (The Firefox source has already gained experimental support for opting into URL and MP4 parsing using Rust.) They're also designing an API for exchanging memory management information with a garbage collector so the interface between Rust libraries and garbage-collected languages doesn't have to be a point of friction and potential bugs.
UPDATE: Here are a couple of links that help to make clear why Rust is such a big deal: https://cmcenroe.me/2015/08/08/why-rust.html http://blog.skylight.io/rust-means-never-having-to-close-a-socket