With privacy and security obligations consuming more and more attention during contract negotiations, open-source issues seem almost an afterthought. Once the darling of doomsayers and CLE workshops, open source is not at the top of everyone’s deal-breaker list anymore. But what open-source issues should customers think about in today’s environment?

Back in the good ol’ days, a customer could reasonably add a representation to a software or development agreement that promised “no open-source materials will be provided in the work product/software.” Those days are long gone because nearly every product incorporates open source. It seems that every vendor has a list of open-source software that is incorporated into its products and is more than eager to share the list with customers.

The temptation, of course, is to simply forward the list to the tech team (or, at least, the most tech-savvy member of the legal team) and ask if there are any red flags. Although that may not be a bad idea, one should consider three primary issues when marking up or otherwise negotiating an open source–related provision.

1. Will the vendor’s use of open source require your company to disclose or distribute its proprietary products in source code form or for no charge? Customers should ask if the vendor has managed its open source in a manner that will not trigger the “viral nature” of General Public License (GPL) or GPL-flavored open-source licenses. This is the doomsday open-source scenario that was the subject of much discussion a mere decade ago. Software vendors can manage the use of open-source code in a way that will not trigger issues for your end product, whether through the use of post-compile access, separate binaries, or other technical matters. Customers should consider adding provisions to their agreements that focus on whether the vendor has taken appropriate measures to ensure that the customer’s organization will not become an open-source or freeware company.

2. Are you protected against intellectual property claims? Vendors commonly attempt to exclude third-party open-source products from their intellectual property protections. Although this may seem reasonable at first glance (after all, the vendor didn’t create the code), customers may not want to assume the infringement risk. The vendor presumably made a build-or-buy decision, and incorporating open source may have been a cheaper, faster approach. Consider whether the vendor should rely on its own due diligence as to whether the code is clear for usage. Intellectual property protection for open source should always be an issue that a customer evaluates when dealing with a software vendor.

3. Should a vendor be responsible for the performance of the code’s open-source portions? This issue is similar to the second issue above, but less nerdy. If the product you purchased fails, should the vendor be responsible if the failure was caused by open-source software? Using the build-or-buy decision reasoning above, some reasonable minds would say “yes.” The issue, however, is that many open-source projects are merely communication protocols or other utilities that are actually required by virtue of the customer’s operating environment. Said differently, the customer’s environment may create situations that require the use of open-source protocols or other utilities. In these situations, vendors may ask for limited exclusions to certain performance warranties. The issue of performance is always tricky in this regard, and the use of open source further complicates the analysis. Still, it remains one of the major issues that customers should consider when negotiating agreements.

Although open-source issues may no longer be the headliners for webinars or discussions at the local lawyer watering hole, there are still important issues to consider when negotiating agreements.