Creating a customized SDK basically comes down to selecting the set of embedded computer libraries and APIs that application developers should use, and then ensuring that they are built into the application development toolchain in a version-controlled way. If the application will take advantage of dynamic linking, then this also means ensuring consistent versions are built for the developers’ desktops as well as into the runtime target images. Delivering the SDK in an easily installable format solutions to ensure consistency across all application developers.
As with most typical embedded products built upon solutions an open source platform, it’s likely that the development team will have to keep track of the obligations incurred across many different open source licenses, not just a single license. As one example, we provide “small footprint starting points,” which are prebuilt embedded Linux images typically only a few megabytes in size and which simplify getting up and running quickly and easily with embedded Linux. As solutions shown in Figure 2, a small footprint starting point might only include seven open source packages, but those seven packages actually fall under four different open source licenses.
The use of each type of open source license in an embedded product design imposes a unique set of obligations on the development team that is incorporating this software into their products. Because of this, some companies maintain a list of open source licenses approved for use by their developers. Other companies go further, explicitly listing which specific version of each open source package has been approved for possible incorporation into the company’s embedded computer products.
refer to: http://embedded-computing.com/articles/the-not-code-quality/
