These days the terms in contracts regarding open source are much more nuanced to manage risk.
There can be a preapproved list of open source and uses, and I'd say more often than not customary warranties of compliance and indemnities do not explicitly exclude open source software, but it really depends on the parties on the deal and, and you know, depends on what's appropriate for the parties at the time. We are also seeing more open source-specific contractual provisions come into play. For instance, an obligation for the provider to provide information rights (e.g. what open source packages are used, what versions, how they're used) and that is very important many times to facilitate the clients being able to comply with open source licenses that are relevant. We talk to the customer and the provider as clients and look for what's appropriate in a given deal.
It's not always the case. We've seen some pretty creative practical approaches to deal with open source issues. For example, we had a client that was trying to sell a software package that included copyleft open source, and, in order to avoid an argument that our client distributed the copyleft code and, with it, all the integrated proprietary code, our client persuaded the buyer that it was in the interest of both parties for our clients to transfer only the proprietary system code and let the buyer itself download the open source copyleft code and rebuild the product. Doing that also avoided an automatic grant of a patent license. There was skepticism at first, but, when people understood the open source issues at hand, they were very in favor of a creative way to avoid them.
Then there's what is sometimes referred to as typosquatting. Here, a hacker downloads the code, injects malware into it, and puts it back on the internet for others to download, but with a slightly modified name to trick careless developers. So, for example, instead of a package called Julian.js it may be Jullian.js or julian.js. And of course, the hacker isn't just necessarily doing this once. It may create a multitude of packages with lookalike names to fool unsuspecting developers. This is a significant problem today, in part because we don't have the equivalent of an iTunes store for open source, where a central authority reviews and verifies what's available for download.