Allgemein bietet der Einsatz eines Betriebssystems als Basis für ein zu entwickelndes Produkt gegenüber einer eigenen In-House-Entwicklung ab einer gewissen Komplexität den Vorteil, dass benötigt Funktionalitäten (für deren Entwicklung häufig nicht das benötigte Fachwissen existiert) bereits als Module vorhanden sind. Speziell Linux (aber auch die verschiedenen BSD-Derivate) bietet eine Unix-ähnliche und weitesgehend standardisierte Basis. Die Standards LSB, FHS, POSIX und SUS sind nur die wichtigsten, viele weitere Organisationen existieren um Detailaspekte festzulegen (z. B. LiMo, freedesktop.org und viele weitere).
Der offensichtliche und oft gepriesene Vorteil von Linux als Basis für ein Embedded System sind die Primärkosten: Sowohl der Kernel als auch weitesgehend alle benötigten Dienste sind kostenlos unter Open Source-Lizenzen verfügbar. Das ist Software im Wert mehrerer Millionen Euro. Bei einem typischen proprietären Echtzeit- oder Embedded-Betriebssystemen fallen häufig nicht nur Lizenzgebühren in vierstelliger Höhe alleine für die Basisfunktionalität an. Hinzu kommen Paketpreise für häufig benötigte Features wie z. B. dem IP-Stack (sowohl IPv4 als auch IPv6 und zuzüglich Diensten wie DHCP-Client und Webserver), USB-Stack oder eine API für eine grafische Benutzerschnittstelle. Diese Gebühren sind häufig pro Entwickler und Jahr zu bezahlen, pro Lizenzbündel sind schnell Gebühren in fünfstelliger Höhe zu bezahlen.
Die frei verfügbaren Quellen machen es möglich, die Software an eigene individuelle Bedürfnisse anzupassen und potentiell existierende Fehler selbst zu korrigieren ohne auf eine Korrektur vom Anbieter warten zu müssen. Zwar ist (gegen Aufpreis) auch bei den meisten Anbietern proprietärer Lösungen über spezielle Lizenzen Zugriff auf den Quellcode möglich.
Weiterhin macht der uneingeschränkte Zugriff auf die Quellen das Produkt unabhängig von einem einzelnen Anbieter. Sollte dieser eine Produktreihe einstellen oder gar komplett vom Markt verschwinden, dann ist oft auch das Produkt oder gar die ganze Firma dem Untergang geweiht.
Software alleine macht noch kein fertiges Produkt, häufig helfen die Anbieter proprietärer Lösungen mit umfangreichen Support- und Schulungspaketen weiter. Verfügbarer Support war lange ein Schwachpunkt von Linux als Embedded Platform. Durch den gewachsenen Zuspruch konnten sich aber inzwischen viele Firmen verschiedener Größe mit Support-Paketen etablieren, beginnend bei kleinen Spezialisten wie DENX über große spezialisierte Distributoren wie MontaVista bis hin zu Konzernen wie IBM. Auch die klassischen Anbieter im Embedded-Bereich bieten inzwischen fast alle zusätzlich eine Linux-Lösung an, dazu gehören Wind River, Timesys und LynuxWorks (ehemals LynxWorks). Nicht zu vergessen sind fertige Distributionen für verschiedene Zwecke, zu den bekanntesten gehören OpenWRT, Maemo, Android, sowie die diversen Versionen von OpenEmbedded.
Häufig ist der Umstieg auf freie Software bzw. Plattformen aber auch mit Probleme verbunden. Gerade die Entwicklungsmethoden unterscheiden sich grundlegend und speziell im Zusammenhang mit der GPL gibt es häufig Probleme mit dem sogenannten Intellectual Property. Der Umstieg ist immer ein Abwiegen zwischen dem Für und Wider, häufig einhergehend mit dem Hinterfragen althergebrachter Sichtweisen. Gerade der Wert besagten Intellectual Property kann von den Vorteilen überwogen werden.
Nicht zu vernachlässigen sind auch die Kosten, die für die Suche, das Einstellen und das Training der Entwickler benötigt werden. Auch hier spricht aufgrund des Markts viel für den Einsatz von Linux als Basis für ein Embedded System. Gerade Entwickler für proprietäre Systeme sind rar und dementsprechend zu entlohnen. Für ein Linux-Team werden weniger Spezialkenntnisse benötigt, je nach Größe des Projekts kann z. B. ein Experte in Sachen hardwarenaher (Kernel-) Programmierung unterstützt werden von einem C- oder C++-Programmierer für problemspezifische Dienste sowie beispielsweise PHP- oder Python-Entwickler für das Web-Frontend. Ein Experte in Sachen Linux-Administration und Debian-Packaging kann das Team abrunden ohne viel Programmierkenntnisse in anderen Bereichen zu benötigen. Da für Linux bereits diverse Embedded Platforms zur Verfügung stehen wird im Zweifelsfalle gar keine systemnahe Programmierung benötigt.
Wie bereits zuvor erwähnt unterliegt der Linux Kernel der GPL 2.0. Für einen allgemeinen Überblick über Open Source-Lizenzen ist die Präsentation Making Sense of Open Source Licenses von J Aaron Farr ein guter Ausgangspunkt. Die Verwendung von Open Source-Software bietet viele Chancen, wie bei kommerzieller Software ist die Lizenz jedoch immer einzuhalten. Gerade die GPL hat ihre Tücken und wird häufig falsch interpretiert. Dabei lässt sie sich grob auf einige wenige Punkte zusammenfassen:
Software unter der GPL steht im Quellcode zur Verfügung und alle abgeleiteten Produkte müssen dem Lizenznehmer (also dem Kunden) ebenfalls im Quellcode zur Verfügung gestellt werden. Zu abgeleiteten Produkten zählt prinzipiell alle Software, die im selben Adressraum wie die Originalsoftware läuft oder auf spezifische Schnittstellen zugreift. Dies bedeutet, dass die GPL aus Entwicklersicht zu den restriktivsten der Open Source-Lizenzen gehört: Auch die Verwendung einer unter der GPL lizenzierten Bibliothek (zumindest ohne weitere Ausnahmen) verlangt die Offenlegung des nutzenden Quellcodes.
Die Kernel-Entwickler um Linus Torvalds legen diesen Passus so aus, dass Software (z. B. Treiber), die von anderen Systemen (z. B. Windows) portiert wird, kein abgeleitetes Produkt darstellt, da sie nicht ursprünglich für Linux geschrieben wurde. Einige Schnittstellen sind zudem explizit als GPLONLY markiert.
Dem Produkt ist eine Kopie der GPL beizulegen, die Quellen sind dem Kunden auf Anfrage zur Verfügung zu stellen und zwar auf dem selben Wege wie die Software. Dafür können durchaus angemessene Gebühren verlangt werden. Dem Kunden ist es dann erlaubt, die Quellen wiederum weiterzugeben.