To comply with their obligations under OSS licenses, device makers must maintain accurate and comprehensive information about which open source components (and which version of each) are used in their devices. This requires significant effort because, as we stated above, most IoT devices contain dozens of OSS components, and each of those may depend upon anywhere from a handful to more than a hundred other OSS components (which are sometimes referred to as “transitive dependencies”).
License compliance is not the only reason to invest in managing this information—it’s also essential to keeping the devices secure. While OSS is not inherently more or less secure than closed or proprietary software, it contains bugs just as all software does. Some of those bugs can make the OSS—and any device it runs on—vulnerable to attack by malicious hackers. To keep their devices reasonably secure, device makers must track information about vulnerabilities in their OSS dependencies, fix newly discovered vulnerabilities as soon as they’re discovered, and issue those fixes to end users promptly via software updates.
Finally, maintaining accurate OSS-related information is key to demonstrating proper controls to auditors, investors, partners, and customers (especially if the customers are large distributors, resellers, OEMs, or enterprises). Such information can also be vital in both the decision to bring a legal action against a third party,  and in defending an OSS-related legal action.
1. Open Source Management Tools
Companies increasingly use automated tools to track this mountain of information. A growing industry provides software that enables companies to discover and track the OSS components in their products, provides updates about newly discovered security vulnerabilities in those components, and helps companies in preparing OSS license compliance information for distribution to end users. These tools integrate with a company’s software development pipeline to automatically capture new and updated OSS components as developers add them to their software.
2. Processes and Policies
OSS management tools are not magic bullets; effective OSS management requires institutional knowledge and human intervention. Like all software companies, device makers are well served by creating written policies describing, among other things:
- What OSS management tool(s) they use and how they work
- Who is responsible for maintaining such tools
- How they ensure that new software is scanned by or integrated with any OSS management tools
- Who is responsible for reviewing the results of such tools and at what cadence
- The process for dealing with an OSS component with insufficient information or a license that the device maker cannot comply with
- Who is tasked with putting together the license and IP attribution notices and source code described above, and the form in which this is done
- The creation, approval, and maintenance of a list of licenses that the device maker can and cannot comply with (a “go/no go” list) 
Device makers often utilize more than one “go/no go” list for their devices. It is common to have one governing the operating system layer of the device, which commonly contains a number GPL-licensed components and is licensed from a supplier, and a separate “go/no go” list for application layer software typically written by the device maker itself. While device makers wishing to take advantage of Linux can’t avoid the GPL at the operating system level of their software stack, they may restrict reciprocal and semi-reciprocal licenses at the application layer to ensure that product-differentiating applications remain proprietary while avoiding tricky analyses of software interactions. 
3. Relationships with Suppliers
When it comes to OSS license compliance, the venerated “garbage in, garbage out” rule applies: if a device maker doesn’t get useful information about OSS components from its OEM hardware suppliers, its hopes of discovering all of the OSS in its product are slim, and its risk of compliance or security issues goes up. Even the best open source management tools can’t effectively analyze software delivered to the device maker in binary form. And supplier-provided source code can pose its own challenges for such tools if the supplier’s developers did not utilize proper coding hygiene. For these reasons, it is essential to gather this information directly from the supplier rather than to try to assemble it forensically.
 For example, a device maker may wish to avoid bringing suit against the copyright holder of an OSS component that’s essential to its product, as many OSS licenses contain termination provisions triggered by such claims (including Apache 2.0, Eclipse Public License 2.0, and Mozilla Public License 2.0).
 The Linux Foundation’s OpenChain Project publishes a standard for open source license compliance practices, which contains more detailed information about best practices for open source management. See The OpenChain Project, https://www.openchainproject.org/.
 It is generally accepted that the GPLv2 license applicable to Linux does not affect the licensing of software at the application layer. See, e.g., Linus Torvalds, preamble to the Linux kernel license, http://etutorials.org/Linux+systems/embedded+linux+systems/Appendix+C.+Important+Licenses+and+Notices/C.1 +Exclusion+of+User-Space+Applications+from+Kernel+s+GPL/.