When an IoT device maker ships its product to an end user, it must also provide the compliance materials required by the applicable OSS licenses, including the OSS license texts, author IP notices, and source code for reciprocally and semi-reciprocally licensed components. This section describes common practical approaches to these obligations.
1. Licenses and IP Attribution
IoT devices distributed to end users must include copies of OSS licenses and IP attribution statements for each OSS component they contain. Product companies typically follow either or both of the following strategies for complying with the license & IP notice obligations:
- Printing all of the required license and attribution statements in the product manual or another printed document accompanying the product. (If the next IoT device you buy comes with a thick user manual, you can bet it’s 75% OSS compliance information.)
- Compiling all of the required information into a single digital text and incorporating it into the interface of the device. (If you navigate to the “Legal” option in the menu for your smart TV, you will likely have the pleasure of scrolling through the full text of dozens of OSS licenses.)
It is not sufficient to include a link to a webpage containing the required notices; most OSS licenses are clear that the information must be included with the (in this case, embedded) software when it’s distributed. 
2. Source Code
For reciprocally licensed OSS, in addition to providing end users with OSS licenses and IP attribution statements, device makers must also include either a copy of the source code for the OSS, or (depending on the license) an offer to provide the source code or information about how to obtain it.
Product companies generally prefer not to include the required source code for reciprocally licensed OSS components with the product.  Instead, most include a link or reference in their printed notices to a location on their website where they provide the required source code for their products. The source code will usually be contained in a compressed archive file (e.g. zip) containing a copy of the printed compliance notices and individual archive files with source for each reciprocally licensed component in the product.
The source code provided must be the actual source code to the component embedded in the product—what GPLv2 refers to as “the complete corresponding machine-readable source code.”  If the device maker has modified a GPL-licensed component, it’s not enough to include the unmodified source of that component as distributed by the open source project, it must include the modifications. For GPLv2-licensed components, the “complete corresponding... source code” also includes “any associated interface definition files, plus the scripts used to control compilation and installation of the executable,”20 meaning the code necessary to enable someone to configure and compile the code in the same way the manufacturer did.
 See, e.g., Open Source Initiative, The 3-Clause BSD License, https://opensource.org/licenses/BSD-3-Clause (requiring that “[r]edistributions in binary form must reproduce the... copyright notice, ... list of [license] conditions and ... [warranty] disclaimer in the documentation and/or other materials provided with the distribution.”)
 This was a fairly common practice back when most hardware products came with a physical CD of accompanying software, but gone are the days.