This is why I drink: a discussion of Fedora's legal state

and doesn't explain why there's similar language limiting how you can use your music library program.

My best guess for that part is that a company like Apple it's a matter of simplicity. For a company that doesn't care about abstract issues like software freedom, it does no harm to include a license term forbidding people from using the software to design nuclear weapons or engage in some other nefarious activity. Nobody is going to complain about a license term telling them they mayn't do something that's either impossible or forbidden. If it's impossible, the restriction is irrelevant, and if it's illegal then the people who were going to do it anyway aren't going to let a license term stop them.

To the lawyers who draft the licenses, though, including the term is a definite benefit. On the one hand, it means they only have to have one license, the one that includes those terms, rather than multiple licenses tailored to the capabilities of the programs they're applied to. On the other hand, it means nobody has to sit down and figure out which license applies to any piece of software. That's not only tedious, but nobody wants to be in the position of getting it wrong and exposing the company to liability because they left out a restriction they should have included.

There's two reasons, usually intermingled and combined with legal inertia.

Firstly, there are risks who's outcomes are so large as to be uninsurable. You could imagine a program which melts down a reactor and not only kills a fair number of New York's residents but also makes uninhabitable some of the most expensive and litigious real estate in the world.

What should a company which sells software do to reduce its exposure to third-party damages? One possible response is to inhibit the programs use in these uninsurable situations and then take out insurance for the remaining insurable situations. You then copy the list of exclusions from your insurance policy into your software license or contract.

Secondly there is the Wassenaar Arrangement and its friends. These prevent the export of dual-use technologies. How do you prevent your average program from being tainted as a dual-use technology, which may then fall under the laws enabling this Arrangement? Using the same approach as above, you prevent the use of your program in fields of endeavour which may incorporate your program into a dual-use technology.

Now your lawyer leans back in their chair satisfied at a day's work well done, every 6 minutes billed out. But does this legal cleverness work in practice? Well have you ever seen a software license updated due to a change in insurance policy exclusions? So we're already fraying at the edges. And if you do contaminate large chunks of Manhattan, aren't the legal fees alone going to doom your company, especially since the insurer won't be helping pay them. There really is no practical legal protection offered, you're going to have to rely upon legislative limits.

The military-industrial complex has done its bit too. The export rules for dual-use technologies are far clearer than they used to be. After looking up some tables you can determine if your software is dual-use or not. If it is dual-use then its dual-use whether it has been used in a dual-use application or not: there is no theory of 'contamination'. Moreover there's a separate documentation dealing with exports -- the end-user certificate -- so there's no need to repeat all that in the software license or contract: the certificate itself can be your warranty from the exporter that they won't re-export the software. That allows the same license for exportable, dual-use and controlled technologies.