Most IoT device makers are integrators: they integrate hardware and software supplied by third party vendors into a finished product. And most of the OSS shipped in the final product typically comes from one or more of those vendors.
Device makers should therefore be sure to include appropriate provisions in their contracts with suppliers to address OSS license violations caused by the supplier. Since any violation of an OSS license is fundamentally copyright (and sometimes patent) infringement, device makers should look for broad warranties and indemnities related to intellectual property infringement arising from supplier-provided software.
OSS-specific provisions may also be warranted when:
- The device maker wants to see OSS-related information presented in a specific format, preferably such that it is ready to be viewed by end users without further editing;
- The device maker has a “go/no go” list it wants suppliers to follow, particularly if the supplier is providing software intended to be used as a component in a proprietary piece of software in the application layer of the product;
- The supplier is legally unsophisticated, and it is useful to spell out what compliance with OSS licenses means;
- Failure to comply with OSS licenses could impact the device maker’s relationship with the public at large or specific partners, customers, potential employees, etc., in addition to raising legal liability;
- The supplier is unwilling to offer broad warranties and/or indemnities, but is open to specific representations, warranties, or indemnities solely with respect to open source. 
The specific provisions that may be warranted in any given transaction will also depend on the nature of the software the supplier is providing. Custom software, particularly software bound for the application layer of product (as opposed to the operating system), may naturally result in a lot of feedback and iteration between the device maker and the supplier. In such a relationship, suppliers are more likely to agree to seek the device maker’s pre-approval of particular OSS components, or to be amenable to following a specific policy regarding the OSS components to be used.
A provision like the following may be appropriate to ensure that a supplier does not incorporate reciprocally licensed OSS in proprietary application-layer software:
“Supplier will not incorporate into any Supplier Software any third-party software that does, will or would reasonably be expected to require the (a) disclosure or distribution of the Device Maker Software in source code form, (b) licensing or other provision of the Device Maker Product on a royalty-free basis, or (c) grant of any patent license, non-assertion covenant or other rights under any intellectual property rights or rights to modify, make derivate work based on, decompile, disassemble, or reverse engineer the Device Maker Product. Without limiting the foregoing, Supplier Software will not include any software licensed under any version of the GNU General Public License, the GNU Affero General Public License, or the SleepyCat License.”
Note, however, that for devices that depend upon Linux, such a provision cannot not be applied to the entire product (i.e. both the OS and application layers), since Linux contains a number of reciprocally-licensed components.
A provision like the following can be used to ensure that the device maker receives all necessary OSS-related information:
“During the Support Period, Supplier will:
(a) provide Device Maker with a listing of all third-party software components that Supplier includes directly or indirectly in or with the Supplier Software upon delivery of each release thereof to Device Maker. Such listing will include for each component: (i) the name, (ii) the version, (iii) the download URL, and (iv) the full license text(s) as included in the component as all as any copyright notices. The listing will be of sufficient quality to be customer-facing without modification by Device Maker and Device Maker may use and distribute the listing verbatim, with modification, or aggregated within other Device Maker documentation; and (b) provide Device Maker with all source code that Supplier is required to disclose under any applicable third-party software licenses.”
Note that this provision puts the supplier on notice that its obligations extend to transitive OSS components (“...direct or indirectly...”) and it also extends all the OSS-related obligations to each and every release of software that the supplier may make to the device maker.
However, suppliers of “off-the-shelf” software (which typically includes operating systems), are less likely to agree to these sorts of provisions and it becomes incumbent on the device maker to shop around for a trustworthy supplier. Device makers should look for a supplier who provides the licenses and copyright notices for the OSS components it uses, has made the source code easily available, and publishes information on its OSS compliance practices and policies. 
Open source software is an essential part of any IoT device, but it must be used mindfully to avoid security issues and ensure compliance with OSS licenses. Device makers should pick their suppliers carefully, adopt tools and processes to track the OSS components they use, and surface security vulnerabilities in a timely way. They should also develop institutional knowledge about OSS license terms, and engage outside expertise where needed, to ensure their use of OSS is consistent with the OSS license terms and with their business strategy.
 The OpenChain Project publishes a specification for open source compliance programs that suppliers can adhere to and claim conformance with. Note that the specification ensures that certain artifacts documenting processes and controls exist, but the specification is agnostic as to “go/no go” policies, so mere conformance with OpenChain may not be sufficient to meet the needs of a specific device manufacturer. OpenChain itself also does not conduct any audits. However, claims of OpenChain conformance constitute one indication that a supplier is sophisticated in this area.