Guten Tag! Ich programmiere jetzt schon seit längerem hobbymäßig. Bisher habe ich kleinere Projekte immer ohne OS umgesetzt. Also direkt in C mit der jeweiligen Hersteller IDE. Um mich mal wieder ein bisschen weiterzuentwickeln wollte möchte ich mit embedded Betriebssystemen (FreeRTOS oder Embedded Linux) starten. Was würdet Ihr mir da empfehlen? Da ich noch kein spezielles Projekt vor Augen habe wäre es am besten wenn es möglichst vielseitig ist. Echtzeitanwendungen sehe ich bei mir aktuell noch nicht so wirklich. Aktuell tendiere ich zu Linux und wollte damit starten mit "Linux from Scratch" mein "eigenes" Linux aufzusetzten. Ich denke so bekommt man einen guten Einstieg zur Funktionsweise. Da ich mir zumindest die Option eines späteren Vertriebs offenhalten möchte wollte ich mich aber schon frühzeitig mit den Lizenzbedingungen auseinandersetzen. Ich habe auch schon ein bisschen recherchiert, aber ich konnte keine Quellen finden die z.B. die GPL Lizenzbedingungen mal ein bisschen verständlich ausdröseln. Wo kann man sich da ein bisschen einlesen? Am besten wäre eine Art Leitfaden. So könnte ich mir mal einen Überblick verschaffen. Vielen Dank! Steffen
FreeRTOS und Embedded Linux haben ungefähr so viel gemeinsam wie ein Bagger mit einem Linienbus. Was ich damit sagen will: Es kommt sehr darauf an, was du machen willst. Deine Idee, ein eigenes Linux from Scratch aufzusetzen halte ich für sehr fragwürdig. Bis du dir bewusst, was du dir da vorgenommen hast? Das ist absolut nichts für Einsteiger. Außerdem brauchst du einen zu Linux kompatiblen Rechner. Wie es der Zufall will, werden diese bereits mit einer fertigen Linux Distribution verkauft. Und genau die solltest du nutzen. In zehn Jahren, wenn du jede Datei persönlich kennst, kannst du dich mal daran versuchen, ein eigene Linux "from Scratch" aufzusetzen. Eine kommentierte deutsche Übersetzung der GPL findest du dort: https://www.gnu.de/documents/index.de.html Aber auch das verstehen normal-sterbliche kaum. Konsultiere einen Juristen, der Dir das erklärt. Das Grundprinzip der GPL ist: Wenn du etwas verkaufst, dass von GPL Produkten abhängt, dann musst du deines ebenfalls unter GPL stellen und die Quelltexte samt Build-Scripte kostenlos veröffentlichen.
Stefan ⛄ F. schrieb: > FreeRTOS und Embedded Linux haben ungefähr so viel gemeinsam wie ein > Bagger mit einem Linienbus. Haha :D ... okay. Wo liegt denn der wesentliche Unterschied? > Was ich damit sagen will: Es kommt sehr darauf an, was du machen willst. Eben das weiß ich noch nicht ganz genau. Deswegen möchte ich mich mit etwas möglichst vielseitigem auseinandersetzen. Bisher habe ich halt einfach nur Controller in C programmiert und jetzt möchte ich mich ganz gerne ein bisschen weiterentwickeln. Was würdest du denn für den nächsten Schritt empfehlen? Stefan ⛄ F. schrieb: > Deine Idee, ein eigenes Linux from Scratch aufzusetzen halte ich für > sehr fragwürdig. Bis du dir bewusst, was du dir da vorgenommen hast? Das > ist absolut nichts für Einsteiger. Ne bin ich mir nicht :D. http://www.linuxfromscratch.org/lfs/ Die Beschreibung im Link hörte sich für mich ganz gut an. Stefan ⛄ F. schrieb: > Aber auch das verstehen normal-sterbliche kaum. Konsultiere einen > Juristen, der Dir das erklärt. Das Grundprinzip der GPL ist: Wenn du > etwas verkaufst, dass von GPL Produkten abhängt, dann musst du deines > ebenfalls unter GPL stellen und die Quelltexte samt Build-Scripte > kostenlos veröffentlichen. Die GPL habe ich mir auch schon angeschaut und es auch grob verstanden. Es geht mir aber mehr um die ganz konkreten Bedingungen die man beachten muss wenn man das Produkt eventuell mal verkaufen möchte. Z.B. mit der Verlinkung und co. Einen Juristen möchte ich da gerade noch nicht beauftragen, da ich ja nichtmal eine konkrete Idee für ein Produkt habe. Ich habe gehofft das es da vielleicht gute Literatur bzw. Leitfäden gibt. Mit dieser Problematik müssen sich alle kleinen Entwickler ja irgendwann mal auseinandersetzen. Vielen Dank! Steffen
Moin, Steffen schrieb: > Ne bin ich mir nicht :D. > > http://www.linuxfromscratch.org/lfs/ > > Die Beschreibung im Link hörte sich für mich ganz gut an. Ja, die ist auch "ganz gut". Jetzt in erster Linie nicht direkt, um schwerpunktmaessig embedded Linux zu verstehen, aber doch um zu verstehen, wie so ein GNU/Linux tickt, wie das mit (cross)compilerbau so laeuft, etc. Also solide Grundlagen. Ich wuerd' nur empfehlen, das zum ersten Mal nicht auf einem Produktivrechner zu machen, man schiesst sich da am Anfang mal gerne aus Versehen in den Fuss ;-) Nur hat LFS/BLFS selbst auch nix mit den Lizenzen zu tun. Das muss man dann halt woanders lesen, bzw. sich irgendwo aufschlauen - nur hab' ich da Zweifel, dass das irgendwo im www so richtig rechtssicher moeglich ist. Gruss WK
Wichtig wäre auch wann überhaupt eine kommerzielle Nutzung von Software vorliegt. Wenn ich zum Beispiel eigene Raspberry Pi ähnliche Hardware mit nem Debian Betriebssystem und meiner eigenen Software verkaufen will ist das dann sofort eine kommerzielle Nutzung von Debian oder hängt es dann davon ab wie ich mein Porgramm mit dem Betriebssystem verknüpfe. Wie sieht das überhaupt hinsichtlich Hardware aus. Ich erinnere mich daran das unser Prof in einer Vorlesung mal meinte das Schaltungen zum Beispiel gar nicht Patentfähig sind. Kann man dann sich dann z.B. beim Raspberry einfach die Schaltung abgucken. Versteht mich nicht falsch ich will nicht alles klauen und abgucken aber es interessiert mich einfach. Gibt es vielleicht auch irgendwelche Modelle um die jeweiligen Hersteller später am Erlös zu beteiligen oder ähnliches? Ich habe da wirklich 1000 fragen und würde mich halt ganz gerne ohne Anwalt mit der Thematik auseinandersetzen. Danke!
Steffen schrieb: > Was würdet Ihr mir da empfehlen? Da ich noch kein > spezielles Projekt vor Augen habe wäre es am besten > wenn es möglichst vielseitig ist. Das Universalbetriebssystem gibt es nicht. FreeRTOS passt für "klein bis mittel" (RAM zweistellig KB bis MB), Linux für "mittel bis riesig" (RAM zweistellig MB bis TB), es gibt auch Systeme für "winzig". Der Funktionsumfang variiert entsprechend. Du musst dich also zumindest auf eine Größenklasse festlegen. Echtzeit mit Linux ist möglich, aber nicht ganz einfach. > Aktuell tendiere ich zu Linux und wollte damit starten mit "Linux from > Scratch" mein "eigenes" Linux aufzusetzten. Ich denke so bekommt man > einen guten Einstieg zur Funktionsweise. Das kann man machen, ist aber nicht die beste Variante. Ein System auf Basis der vollständigen GNU-Tools ist zwar schick und kompatibel, aber sehr aufwändig. Distributionen patchen diverse Pakete, aus guten Gründen. Schau dir lieber mal Systeme wie buildroot an. Da fällt hinten ein bootbares Image auf Basis von BusyBox (auch anschauen) raus. > Da ich mir zumindest die Option eines späteren Vertriebs > offenhalten möchte wollte ich mich aber schon frühzeitig > mit den Lizenzbedingungen auseinandersetzen. Da du mit verschiedenen Lizenzen hantierst, ist das schwierig. Was die GPL betrifft, so musst du sämtliche Quelltexte (und eigene Patches) auf Anfrage bereitstellen können. Nutzt du ein Projekt wie buildroot als Basis, dann reicht es aus, wenn du die genaue Version und Konfiguration von buildroot bereitstellst. Für GPLv3 und LGPLv3 gilt, dass ein Dritter den Code bauen und auf der Zielhardware auch ausführen können muss. Ob das legal geht, hängt von deinem Hausjuristen ab - bei uns geht das nicht, daher ist (L)GPLv3 bei meinem Arbeitgeber schlicht verboten. Dein persönlicher Aufwand hängt am Ende eigentlich nur davon ab, wieviel Arschloch du sein willst. Am Ende besteht dein System aus vielen Opensource-Komponenten und ein paar Eigenentwicklungen. Wenn du letztere sinnvoll in dein Basissystem integrierst, dann hindert dich niemand daran, das Basissystem auf Github zu kippen und deine eigenen Pakete lokal zu pflegen. Willst du stattdessen unter allen Umständen verhindern, dass auch nur eine Zeile deines eigenen Codes veröffentlicht wird oder Fremdcode auf deiner Hardware ausgeführt wird, dann wird das natürlich schwieriger. Aus einem Kackehaufen die entsprechenden Tarballs zu extrahieren, um sie dann getrennt auf einem geschützten FTP-Server zu lagern, dessen Zugangsdaten nur auf Anfrage kurzzeitig bereitgestellt werden... ja, geht auch. Ist aber Orschlach. > Ich habe auch schon ein bisschen recherchiert, aber ich konnte keine > Quellen finden die z.B. die GPL Lizenzbedingungen mal ein bisschen > verständlich ausdröseln. Frag einen Juristen. Der kann dir eine kompetente Antwort geben. Frag zwei weitere Juristen und du bekommst mindestens eine dazu widersprüchliche Antwort. Vergleiche mit einem Leitfaden und du bekommst weitere Widersprüche. Steffen schrieb: > Wenn ich zum Beispiel eigene Raspberry Pi ähnliche Hardware > mit nem Debian Betriebssystem und meiner eigenen Software > verkaufen will ist das dann sofort eine kommerzielle Nutzung Wenn du damit Geld verdienst, wird grundsätzlich kommerzielle Nutzung angenommen. Ausnahmen bestätigen die Regel, aber die musst du erstmal nachweisen. Würde ich nicht drauf bauen.
:
Bearbeitet durch User
Dergute W. schrieb: > Ja, die ist auch "ganz gut". Jetzt in erster Linie nicht direkt, um > schwerpunktmaessig embedded Linux zu verstehen, aber doch um zu > verstehen, wie so ein GNU/Linux tickt, wie das mit (cross)compilerbau so > laeuft, etc. > Also solide Grundlagen. So hatte ich das auf der Seite nämlich auch verstanden. Da Linux ja vor allem im Bezug auf IOT immer mehr an Bedeutung gewinnt. Dergute W. schrieb: > Ich wuerd' nur empfehlen, das zum ersten Mal nicht auf einem > Produktivrechner zu machen, man schiesst sich da am Anfang mal gerne aus > Versehen in den Fuss ;-) Das ist klar :). Würde ich wenn auf einem RPi machen. Dergute W. schrieb: > Nur hat LFS/BLFS selbst auch nix mit den Lizenzen zu tun. Dessen bin ich mir auch bewusst. > Das muss man dann halt woanders lesen, bzw. sich irgendwo aufschlauen - nur hab' ich > da Zweifel, dass das irgendwo im www so richtig rechtssicher moeglich > ist. Es muss auch nicht zu 1000% rechtssicher sein. Es geht mir nur darum überhaupt einen groben Überblick zu bekommen. Dafür reicht das einfache lesen der Lizenz-Texte halt nicht aus :D. Danke
Steffen schrieb: > Wo liegt denn der wesentliche Unterschied? Überall. Frage eher, wo die Gemeinsamkeiten liegen: Man kann mehrere Tasks parallel ausführen. Das kann man aber auch ohne RTOS und ohne Linux. > Was würdest du denn für den nächsten Schritt empfehlen? Erstmal keine Brötchen backen. Zum Beispiel die Grundlagen mit einem Arduino Set erforschen oder damit anfangen: http://stefanfrings.de/mikrocontroller_buch/index.html > Mit dieser (GPL) Problematik müssen sich alle kleinen Entwickler ja > irgendwann mal auseinandersetzen. Nein, das machen die Juristen der Firmen.
Steffen schrieb: > Es muss auch nicht zu 1000% rechtssicher sein. Selbst 90% Rechtssicherheit ist bei der kommerziellen Nutzung von Open-Source schwierig zu erreichen. Eben weil die Rechtslage nicht so eindeutig ist, wie die Mathematik. Mir wurde mal vorgeworfen, etwas kommerziell zu nutzen, weil ich auf meiner Homepage einen einzigen Werbebanner hatte. Für mich der einfachere Weg, auf die Werbung (und das bisschen Geld) zu verzichten, als mich auf einen Rechtsstreit einzulassen.
Moin, Steffen schrieb: > Kann man dann sich dann z.B. beim > Raspberry einfach die Schaltung abgucken. Da wuerd' ich mir sie eh' nicht abgucken. Eher aus den Originaldatenblaettern der Chiphersteller. Und die werden dich kaum verklagen, wenn du damit ihre Chips kaufst. Steffen schrieb: > Es geht mir nur darum > überhaupt einen groben Überblick zu bekommen. OK - der ganz grobe Ueberblick: 1.) Link' nix Geheimes gegen was, was unter der GPL steht. 2.) Link' nix Geheimes statisch gegen was, was unter der LGPL steht. Gruss WK
Dergute W. schrieb: > OK - der ganz grobe Ueberblick: > 1.) Link' nix Geheimes gegen was, was unter der GPL steht. > 2.) Link' nix Geheimes statisch gegen was, was unter der LGPL steht. Was "liken" genau heißt, darüber darf man sich im Zweifelsfall vor Gericht streiten. Programme die von GPL Produkten abhängig sind, gelten nämlich auch als angeleitete Werke, selbst wenn sie sich unabhängig compilieren und vielleicht sogar starten lassen.
Aus meiner Sicht ist Suse Linux , z.B. 13.1 immer eine Empfehlung. Für commerzielle Anwendung eher zugelassene OS verwenden.( mit Lizens )
eldorado schrieb: > Aus meiner Sicht ist Suse Linux , z.B. 13.1 immer eine Empfehlung. > Für commerzielle Anwendung eher zugelassene OS verwenden.( mit Lizens ) Auch SuSE Linux besteht zu mehr als 90% aus GPL Software.
Stefan ⛄ F. schrieb: > Erstmal keine Brötchen backen. Zum Beispiel die Grundlagen mit einem > Arduino Set erforschen Bin kein Profi aber ich habe halt mittlerweile schon ein paar Sachen gemacht. Größtes Projekt war die Umsetzung eines BMS. Ein bisschen Erfahrung hab ich also schon :). Ich habe Erfahrungen mit Controllern von Atmel, Microchip und ST. Stefan ⛄ F. schrieb: > Was "liken" genau heißt, darüber darf man sich im Zweifelsfall vor > Gericht streiten. Programme die von GPL Produkten abhängig sind, gelten > nämlich auch als angeleitete Werke, selbst wenn sie sich unabhängig > compilieren und vielleicht sogar starten lassen. Ich frage mich auch schon die ganze Zeit wie weit der Begriff linken auszulegen ist :D. Im Bezug auf Linux und GPL steht bei Wikipedia zumindest folgendes: "Jedoch muss Software, welche als Anwendungsprogramm unter einem GPL-lizenzierten Betriebssystem wie GNU/Linux läuft, nicht zwangsweise unter GPL oder quelloffen vertrieben werden. Die Lizenzierung ist dann nur von den verwendeten Bibliotheken und Software-Teilen abhängig (nicht von der unterliegenden Plattform)." Aber das ist natürlich auch keine gute Quelle :D. Allerdings wird hier auf folgendes Werk verwiesen: https://www.ifross.org/Druckfassung/Die_GPL_kommentiert_und_erklaert.pdf#page=75&zoom=100,0,520 eldorado schrieb: > Für commerzielle Anwendung eher zugelassene OS verwenden.( mit Lizens ) Hast du da ein paar Beispiele? Danke!
Stefan ⛄ F. schrieb: > Mir wurde mal vorgeworfen, etwas kommerziell zu nutzen, > weil ich auf meiner Homepage einen einzigen Werbebanner hatte. Das betrachte ich unbesehen weniger als "da gibt es eine problematische Rechtsauffassung", sondern als "dir ans Bein pissen wollen". Solche Menschen gibt es (leider), und du bist hier im Forum bekannt. Stefan ⛄ F. schrieb: > Programme die von GPL Produkten abhängig sind, gelten > nämlich auch als angeleitete Werke, selbst wenn sie sich > unabhängig compilieren und vielleicht sogar starten lassen. Das hätte ich gerne mal genauer erklärt. In der von dir beschriebenen Allgemeinheit ist das nämlich schlicht falsch. Hättest du Recht, dann wäre jede Linux-spezifische Anwendung prinzipiell ein von der GPL abgeleitetes Werk und das ist offensichtlich nicht der Fall. Gegenbeweis: Android (funktioniert nicht ohne Linux-Kernel). Dergute W. schrieb: > OK - der ganz grobe Ueberblick: > 1.) Link' nix Geheimes gegen was, was unter der GPL steht. > 2.) Link' nix Geheimes statisch gegen was, was unter der LGPL steht. Eventuell noch: 3.) Meide (L)GPLv3, wenn deine Hardware abgesichert sein muss/soll. 4.) Wähle bei dual-lizenzierter Software (BSD/GPL, "GPLv2 oder neuer", etc.) bewusst eine der Optionen aus und halte dich daran.
>Embedded Linux
Wenn Du damit Professionel anfangen willst, dann führt kein Weg vorbei
an Openembedded Yocto Linux, dazu reicht erstmal ein RPI als Hardware.
Wenn Du verstehst, wie Du Dir dein eigenes Image und Rezepte vergehen
schon ein paar Tage.
Steffen schrieb: > Um mich mal wieder ein bisschen weiterzuentwickeln wollte möchte ich mit > embedded Betriebssystemen (FreeRTOS oder Embedded Linux) starten. > > Was würdet Ihr mir da empfehlen? Als Alternative zu FreeRTOS kann ich dir embOS empfehlen. Kannst du für nicht kommerzielle Projekte kostenlos einsetzen und wenn es kommerziell wird sind die Lizenzfragen auch schnell geklärt. Nachteil ist das es dann natürlich Geld kostet. Vorteil ist das es out of the box läuft und ich Support geben kann falls du Fragen hast. https://www.segger.com/products/rtos/embos/ https://www.segger.com/downloads/embos/UM01001 Portierungen gibt es für so ziemlich alles. Ich würde dir empfehlen mit irgendeinem günstigen STM32 Nucleo oder Discovery Board zu starten. Dann die beiden folgenden Sachen downloaden und einfach damit rumspielen: https://www.segger.com/downloads/embos/embOS_CortexM_EmbeddedStudio_Trial https://www.segger.com/downloads/embedded-studio VG, Til
Wenn es ein Embedded Linux werden soll, beschäftige Dich besser mit einem Linux Buildsystemen. Glaube Yocto wurde weiter oben schon genannt. https://www.yoctoproject.org/ https://www.openembedded.org/wiki/Main_Page
Hardware abhängige Dateien bekommst für die Buildsysteme beim jeweiligen Hersteller.
Stefan ⛄ F. schrieb: > FreeRTOS und Embedded Linux haben ungefähr so viel gemeinsam wie ein > Bagger mit einem Linienbus. > Vorwärts kommt man mit beiden.
S. R. schrieb: > Hättest du Recht, dann wäre jede Linux-spezifische Anwendung > prinzipiell ein von der GPL abgeleitetes Werk und das ist offensichtlich > nicht der Fall. Gegenbeweis: Android (funktioniert nicht ohne > Linux-Kernel). In dem Buch aus meinem Link (s.S. 64 ff.) wird darauf genauer eingegangen. Eine klare Abgrenzung ist da wirklich schwierig. Dem Buch ist auch zu entnehmen das es kaum Rechtssprechungen gibt (zumindest zum Zeitpunkt der Erstellung des Buches). Dirk schrieb: > Wenn Du damit Professionel anfangen willst, dann führt kein Weg vorbei > an Openembedded Yocto Linux, dazu reicht erstmal ein RPI als Hardware. Schaue ich mir mal an :). Danke! Dirk schrieb: > Wenn Du verstehst, wie Du Dir dein eigenes Image und Rezepte vergehen > schon ein paar Tage. Das ist ja kein Problem. Aktuell hat man ja viel Zeit. Til S. schrieb: > Als Alternative zu FreeRTOS kann ich dir embOS empfehlen. Kannst du für > nicht kommerzielle Projekte kostenlos einsetzen und wenn es kommerziell > wird sind die Lizenzfragen auch schnell geklärt. Nachteil ist das es > dann natürlich Geld kostet. Vorteil ist das es out of the box läuft und > ich Support geben kann falls du Fragen hast. Schaue ich mir auch mal an. Sehe ich bei dem ganzen Open Source Lizenz spaß gar nicht mal so als Nachteil :D. Auf der Seite steht: "CPU licenses and buyouts are available upon request. " Ist damit gemeint das man auch Lizenzen für einzelne Controller kaufen kann? Das ich zum Beispiel 5 Produkte verkaufe und nur für die 5 dann jeweils eine kleine Gebühr bezahle oder verstehe ich das falsch. Ich möchte große Investitionen natürlich am Anfang vermeiden. Ich hab aber auch noch eine Frage zur Haftung. Angenommen ich verkaufe BMS-Systeme an Privatkunden und der Akku brennt wegen einem Fehler im BMS ab ... (natürlich nicht mein Ziel) :D. Bin ich da mit einer einfachen Haftungsbeschränkung fein raus oder muss man sich als Entwickler auch darüber Gedanken machen. Natürlich nur an Privatpersonen. Große Unternehmen werden so eine Haftungsbeschränkung vermutlich nicht akzeptieren :D. Vielen Dank für eure Beiträge!!!!! Steffen
Stefan ⛄ F. schrieb: > Wenn du > etwas verkaufst, dass von GPL Produkten abhängt, dann musst du deines > ebenfalls unter GPL stellen und die Quelltexte samt Build-Scripte > kostenlos veröffentlichen. Veröffentlichen musst du tatsächlich nichts. Es reicht völlig aus, deinen Käufern den Quellcode bereitzustellen. Die Käufer können dann aber natürlich deinen Quellcode veröffentlichen (steht ja unter GPL). Steffen schrieb: > Ich frage mich auch schon die ganze Zeit wie weit der Begriff linken > auszulegen ist :D. Das ist leider so eine Problematik mit open source Lizenzen. In den meisten Fällen gibt es niemanden der klagt, auch wenn die Lizenz ganz offensichtlich gebrochen wird. Das lohnt sich in den meisten Fällen einfach nicht - insbesondere wenn man wie z.B. in den USA den Anwalt auch dann noch selbst zaht, wenn man gewinnt. Dementsprechend gibt es nur sehr wenige Urteile insgesamt und - für uns wichtiger - kaum Urteile nach deutschem Recht. Insbesondere bei komplexeren und sehr US-zentrischen Lizenzen ist in Deutschland Chaos vorprogrammiert. Auch ist linken als Begriff eher unklar, da viele moderenere Programmiersprachen gar kein klassisches linken mehr kennen. Wenn dann noch dynamisch zwischen zwei API-kompatiblen Bibliotheken (eine GPL eine nicht-GPL) umgeschaltet werden kann, ist auch eher unklar, ob das Gesamtprogramm noch von der GPL abhängt. Ich selbst halte es da recht einfach. In privaten Projekte ohne Veröffentlichung sind mir Lizenzen komplett egal und werden ignoriert. Kein Kläger - Kein Richter. Wenn ich das ganze irgendwann als open source veröffentlichen will schau ich grob drüber (die meisten Lizenzen sind mir grob bekannt), was die Lizenzen verlangen. Im Zweifel ist da die Schadenssumme aber eher begrenzt. @Work haben wir eine Liste generell erlaubter Lizenzen (z.B. MIT), eine Liste mit generell verbotenen Lizenzen (z.B. AGPL) und eine Liste mit Lizenzen bei denen die Juristen und/oder Projektleiter vorab entscheiden müssen (z.B. GPL). Für jedes Projekt werden dann noch die verwendeten Subprojekte (und deren Abhängigkeiten) notiert, damit man zeitnah herausfinden kann unter welchen Lizenzen das Projekt letztendlich stehen kann. Extern zugekaufte Software wird dann genauso behandelt, da gibt es dann nur einen "Lizenzeintrag" pro Software.
Steffen schrieb: > Auf der Seite steht: > "CPU licenses and buyouts are available upon request. " > > Ist damit gemeint das man auch Lizenzen für einzelne Controller kaufen > kann? Das ich zum Beispiel 5 Produkte verkaufe und nur für die 5 dann > jeweils eine kleine Gebühr bezahle oder verstehe ich das falsch. Wir bieten verschiedene Lizenzmodelle an und die CPU und Buyout Lizenz sind die größten und teuersten Lizenzen, die auch sehr individuell sind. Deswegen findest du für diese beiden im Gegensatz zu allen anderen Lizenzen keine Preise auf unserer Webseite. Für dich in Frage kommt aber eher eine Single Developer Lizenz wenn du alleine entwickelst. Dann bezahlst du einmal und kannst damit so viele Produkte entwickeln, wie du möchtest. Auch Stückzahlen interessieren uns nicht. Solche Lizenzen können natürlich nicht immer alles abdecken. Deswegen kann man mit den Sales Kollegen reden und findet eigentlich immer eine Lösung, die für beide Seiten passt. Eine Single Developer Object Code Lizenz liegt bei 2500,- Euro. Hier findest du die Preise: https://www.segger.com/purchase/pricing/embos/
S. R. schrieb: > Das hätte ich gerne mal genauer erklärt... Hättest du Recht, Siehst du, ich hatte das wie gesagt erwartet. Es macht aber keinen Sinn, hier über irgendeine fiktive Sache zu diskutieren und außerdem bin zumindest ich kein Jurist. Deswegen belasse ich es mal bei der Aussage, dass es sich um eine Grauzone handelt. Was dein Android angeht: Das ist Open-Source und doch wurde dessen GPL Konformität lange Zeit von Juristen bezweifelt. Auch SuSE hatte mit seiner Linux Distribution Probleme, weil Teile (z.B. Yast) anfangs nicht Open-Source waren.
https://www.pro-linux.de/news/1/26425/risc-os-unter-freie-lizenz-gestellt.html https://revolution.kunbus.de/
Stefan ⛄ F. schrieb: > Was dein Android angeht: Das ist Open-Source und doch wurde > dessen GPL Konformität lange Zeit von Juristen bezweifelt. Das ist eine andere Frage, da "Open Source" noch lange nicht heißt, dass die Lizenzen auch kompatibel sind; z.B. ist GPL-Code (sowie einige andere) in den BSD-Betriebssystemen aus lizenzrechtlichen Gründen verboten. Android stand nie unter der GPL und Google arbeitet systematisch daran, sämtlichen GPL-Code aus Android zu entfernen (z.B. Busybox -> Toybox). Effektiv bleibt nur noch der Linux-Kernel als wesentlicher Android-Bestandteil. Steffen schrieb: > Angenommen ich verkaufe BMS-Systeme an Privatkunden und der Akku brennt > wegen einem Fehler im BMS ab ... (natürlich nicht mein Ziel) :D. > Bin ich da mit einer einfachen Haftungsbeschränkung fein raus oder > muss man sich als Entwickler auch darüber Gedanken machen. Faustregel: Du kannst nicht ein Gerät verkaufen und "keine Garantie, Pech gehabt" ranschreiben und dich so aus der Haftung stehlen. Verkaufen heißt kommerziell (wird zumindest angenommen) und damit bist du grundsätzlich in der Haftung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.