Hallo zusammen, fast jedes Embedded System muss Daten serialisieren und deserialisieren. Sei es um Konfigurationsdaten zu sichern und wiederherzustellen oder mit der Außenwelt über UART oder TCP/IP zu kommunizieren. Die effizienteste Art der Darstellung ist eine applikationsspezifische Binärrepresentation. Allerdings ist die Umsetzung aufwendig und Wartungsintensiv und wirft Fragen bzgl. Kompatibilität mit anderen Versionen auf. Auf leistungsstarken Systemen ist Google Protocol Buffers geeignet, um den erforderlich Code aus einer Datenbeschreibung zu erzeugen. Allerdings ist der generierte Code nicht optimiert für kleine Systeme und benötigt außerdem eine relativ große Bibliothek. Wire Format Compiler (WFC) schließt diese Lücke für eingebettete Systeme. Die Datenbeschreibungssprache ist eine Erweiterung der von Google Protocol Buffers, die zusätzlich 8- und 16 Bit Datentypen anbietet. Der generierte C++ Code benötigt weder RTTI noch andere aufwendige C++ Techniken und ist auf Codegröße und Geschwindigkeit optimiert. Darüber hinaus bietet WFC erweiterte Konzepte zur Target spezifischen Optimierung und Konfiguration an. Der Compiler wird mit einer ausführlichen Testsuite abgesichert und ist bereits seit ein paar Jahren im Einsatz. Die Doku könnte noch etwas Pflege vertragen. Der generierte Code unterliegt der GPL. Eine BSD-Lizenzierung werde ich für die Zukunft ggf. in Erwägung ziehen. WFC läuft auf Linux, BSD und MinGW und kann von folgenden Seiten heruntergeladen werden: http://www.maier-komor.de/wfc.html https://github.com/maierkomor/wfc Feedback bitte an: thomas at maier-komor punkt de. Viel Spaß und frohes Hacken! Thomas M-K.
Thomas M. schrieb: > fast jedes Embedded System ...ist kommerziell. Thomas M. schrieb: > Der generierte Code unterliegt der GPL. Eine BSD-Lizenzierung > werde ich für die Zukunft ggf. in Erwägung ziehen. Nicht nur GPL, sondern sogar GPLv3. Damit ist es für jede Form von kommerzieller Nutzung unbrauchbar. Für Hobbybastler vielleicht eine gute Idee. Anmerkung: LGPLv3 und GPLv3 sind die einzigen Lizenzen, die bei meinem Arbeitgeber strikt verboten sind. Für alle anderen Open Source-Lizenzen lassen sich Lösungen finden - für diese beiden nicht. Thomas M. schrieb: > Feedback bitte an: thomas at maier-komor punkt de. Nö. Die Antwort soll bitte das gleiche Medium nutzen dürfen wie auch die Werbung.
Hallo S.R., vielen Dank erst einmal für das Interesse. Feedback in diesem Forum ist auf jeden Fall willkommen, aber hier lese ich unter Umständen nicht jeden Beitrag. Was den kommerziellen Aspekt angeht, denke ich, dass es genug Beispiele von erfolgreichen Projekten mit GPL lizenzierter Software gibt, so dass man davon ausgehen kann, dass das Eine und das Andere sich nicht ausschließen. Außerdem bin ich nicht davon ausgegangen, dass es unmittelbares Interesse seitens eines kommerziellen Projekts gibt, die Software einzusetzen. Wenn dem aber so sein sollte, so bin ich selbstverständlich offen für eine kommerzielle Lösung dieses Konflikts. Die Kosten der einsparbaren Stunden an Programmier- und Testaufwand werden sicherlich deutlich unterboten. Primär möchte ich aber in der OSS Community einen Beitrag leisten. Dafür habe ich die GPL gewählt. Argumente für Alternativen höre ich mir gerne an. Schöne Grüße, Thomas Maier-Komor
Ich finde das Thema an sich sehr spannend. Ich frage mich lediglich warum du gerade protobuf genommen hast und nicht etwa Flatbuffers bzw. cap'n'proto (beide unterstützen nativ uint8_t, int16_t und co.). Das der generierte Code GPL sein soll halte ich doch für ein bisschen arg übertrieben. Das Tool an sich kann natürlich unter GPL sein aber der generierte Code...? Ich denke allerdings auch, dass dieser Thread eher in "Projekte und Code" als in "Compiler und IDEs" gehört.
Hier liegt evtl. ein Missverständnis vor. WFC hat von Protocol Buffers lediglich Teile der Syntax und das Serialisierungskonzept geerbt und ist als solches auch in weiten Teilen kompatibel. Ansonsten ist es jedoch ein komplett unabhängiges Projekt und hat eine eigene Codebasis. Wenn ich in Zukunft einen Wert darin sehe, die Lizenz des generierten Codes zu ändern, werde ich das sicher machen. Allerdings ist das Projekt nicht über Nacht entstanden und bis jetzt habe nur ich dazu beigetragen. Werft einen Blick darauf, probiert es aus und lasst uns diskutieren. So entsteht ein Mehrwert für alle.
Thomas M. schrieb: > Der generierte Code unterliegt der GPL. Huh? Darin, daß Dein Compiler selbst der GPL unterliegt sehe ich gar kein Problem. Das ist gängige Praxis und sorgt dafür, daß Erweiterungen von anderen ins Projekt zurückfließen. Aber der aus meiner Datenbeschreibung generierte Code? Ist das nicht extrem ungewöhnlich für den seitens der Toolchain überhaupt einer Lizenz festzulegen? Das wäre als ob mein GCC alle meine mit ihm erzeugten Binaries irgendeiner Lizenz unterlegen würde. Oder Gimp ein von mir mit Gimp erstelltes Bild einer bestimmten Lizenz unterlegen würde. Oder der Hersteller meiner Kamera mir vorschreiben würde, daß alle meine damit geschossenen Fotos unter irgendeiner vom Hersteller festgelegten Lizenz stehen müssen. Ich frage mich jetzt außerdem, ob der vollautomatisch generierte Code überhaupt einer Lizenz unterliegen kann: Durch das Umwandeln der Datenbeschreibung in Programmcode findet keine geistige Schöpfung statt. Es wird streng nach nach einer Vorschrift (=Deinem Compiler) vom einen Format in ein anderes umgewandelt. Das Urheberrecht fordert aber eine gewisse Schöpfungshöhe, bevor ein Werk überhaupt urheberrechtlich geschützt werden kann. Es wird also eine gewisse Individualität oder Originalität gefordert. Genau das macht aber ein Compiler nicht, der ist nicht kreativ, sondern setzt ausschließlich feste Regeln um. Siehe https://de.wikipedia.org/wiki/Schöpfungshöhe Ich bin jetzt kein Anwalt, aber so weit ich das Urheberrecht verstehe passt das so nicht.
:
Bearbeitet durch User
Der generierte Code referenziert eine bedarfsgerecht konfigurierte Bibliothek mit Funktionen die ich erstellt habe und die der GPL unterliegen. Das nur zur Erklärung. Ich würde aber viel lieber über die Verwendung des Tools reden als über die Lizenzierung. Die Lizenzdiskussion führe ich nur mit jemanden, der ernsthaft über den Einsatz nachdenkt und sich mit dem Werkzeug als solches sich auch auseinandergesetzt hat. Ich denke so viel Vorleistung ist nicht zu viel verlangt. Ansonsten entsteht bei mir der Eindruck, dass jemand der gerade etwas geschenkt bekommen hat, noch etwas dazu möchte. Das finde ich nicht seriös. Viel Spaß beim ausprobieren. Fragen zum Tool beantworte ich gerne.
Thomas M. schrieb: > Was den kommerziellen Aspekt angeht, denke ich, dass es genug > Beispiele von erfolgreichen Projekten mit GPL lizenzierter > Software gibt, [...] Wenn du den Linux-Kernel meinst, der steht absichtlich nicht unter GPLv3, sondern unter GPLv2. Bitte vermische die beiden Lizenzen nicht. Die meisten großen Projekte lassen Dual-Lizenzierungen zu, meist GPL/BSD. Für meinen Arbeitgeber ist es beispielsweise schlicht unmöglich, GPLv3-lizenzierte Software gesetzeskonform einzusetzen. Meiner Einschätzung nach betrifft das die meisten einigermaßen regulierten Branchen. Die GPLv2 wäre bei uns im Prinzip akzeptabel, aber mit so hohem Aufwand verbunden, dass Alternativen (auch Eigenentwicklungen) grundsätzlich bevorzugt werden. Thomas M. schrieb: > Argumente für Alternativen höre ich mir gerne an. Weder GPLv2 noch GPLv3 sind mit der BSD-Lizenz vereinbar, daher ist dein Projekt auch für die BSD-Betriebssysteme nutzlos, ebenso wie für jedes andere BSD-lizenzierte Projekt. Ob das für Apache o.ä. auch gilt, kann ich spontan nicht sagen. Da du nicht nur deinen Code unter die GPLv3 stellst, sondern auch den generierten Code, ist dein Projekt sogar ausschließlich für reine (L)GPLv3-Projekte nützlich. Die Verwendung in dual-lizenzierten Projekten schließt nämlich eine Verwendung unter jeder anderen Lizenz aus. Schlimmer noch: Damit erschwerst du anders lizenzierten Projekten auch die Nutzung von entsprechend serialisierten Daten (sie dürfen ja den Deserialisierer nicht einsetzen, und inwiefern man den sauber reimplementieren kann, ist fraglich - was ist Interface, was ist Implementation, was ist Dokumentation). Wenn du dein Projekt ausschließlich für GPLv3-Codebasen zugänglich machen möchtest, dann sei es so. Das halte ich aber nicht für sinnvoll, insbesondere nicht für Kommunikationsschnittstellen. Ich würde dir aber die BSD-Lizenz ans Herz legen. Wenn du unbedingt auf der GPL beharren möchtest, dann nimm wenigstens GPLv2 oder GPLv2-or-newer. Eine sinnvolle Nutzung ist ohnehin erst möglich, wenn der generierte Code relativ uneingeschränkt verwendet werden darf. Meine Empfehlung hier ist "Public Domain", alternativ BSD. Eine Relizenzierung wird in dem Augenblick schwierig, wenn du Contributors hast. Stirbt ein Contributor, wird sie sogar unmöglich. Bedenke das, auch im Hinblick auf mögliche kommerzielle Duallizenzierungsoptionen. Thomas M. schrieb: > Wenn dem aber so sein sollte, so bin ich selbstverständlich > offen für eine kommerzielle Lösung dieses Konflikts. Ehe ein Konzern darüber auch nur nachdenkt, friert die Hölle zu. Da gelten andere Maßstäbe. Nachtrag: Thomas M. schrieb: > Ich würde aber viel lieber über die Verwendung des Tools reden > als über die Lizenzierung. Wenn ich mir nicht sicher sein kann, dass ich dein Tool überhaupt verwenden darf, dann werde ich es mir auch nicht näher anschauen. Meine eigene freie Software steht üblicherweise unter BSD-Lizenz oder Public Domain und damit ist dein Tool schonmal raus. Unabhängig von der Genialität der Implementierung. Thomas M. schrieb: > Ansonsten entsteht bei mir der Eindruck, dass jemand der > gerade etwas geschenkt bekommen hat, noch etwas dazu möchte. Du hast es ja gerade nicht verschenkt, sondern einen Delikatessenladen mit Schokoladenduft eröffnet, indem ich mit meiner Währung leider nicht einkaufen kann.
:
Bearbeitet durch User
Das Argument habe ich verstanden und soweit auch im Blick. Ich habe vor Veröffentlichung auch darüber nachgedacht und verschiedene Aspekte abgewogen. Ich bin für Diskussionen dies bzgl. auch offen, und Stand heute gibt es keine Contributor. Das ist also für mich eine ganz einfache Entscheidung. Offen gesagt: wenn jemand das Tool kommerziell einsetzen möchte, kann er gerne von mir die Lizenz zur Generierung von BSD Code bekommen. Aber not "for free as beer". Dafür war der Aufwand zu groß. Plausibel? Hast Du Dir das Tool angesehen? Ein Kommentar oder eine Frage zum Tool wäre für die Rubrik passend.
hab ich eventuelle übersehen, aber gibt es ein "hallo Welt" in Textform? Also ein paar Zeilen, wie Spec und Code aussehen? Also ein paar Datenfelder und erzeugter C-Code für 2 Plattformen oder so?
Thomas M. schrieb: > Hier liegt evtl. ein Missverständnis vor. WFC hat von Protocol Buffers > lediglich Teile der Syntax und das Serialisierungskonzept geerbt und ist > als solches auch in weiten Teilen kompatibel. Das meine ich soweit verstanden zu haben. Meine Frage nach den Alternativen kam daher, weil ich denke das Protobufs relativ "fett" sind. Sie haben sicherlich ihre Daseinsberechtigung, gerade im Umfeld eines Konzerns wie Google aber sie brauchen relativ viele Ressourcen, sowohl für den eigentlichen (De-)Serializer, als auch für die eigentlichen Daten. capnproto oder Flatbuffers sind einfacher gestrickt, haben weniger Schnickschnack (z.B. hat Flatbuffers kein RPC) aber beide serialisieren sehr kompakt und sehr schnell. Es gibt aber für capnproto keine richtige Embeddedvariante. Für "normale" Systeme ist die libcapnp mit etwa 160kb ja schon winzig aber die Abhängigkeiten sind teilweise sehr unpraktikabel (Boost, etc.) außerdem könnte ein abgespecktes capnproto vermutlich auch noch gut in einen AVR passen.
Die von Dir genannten Tools sind mir nicht bekannt. WFC schafft es aber für den AVR bei richtiger Konfiguration eine Serialisierung einer kleinen Konfiguration mit wenigen kB zu realisieren. Konkret hängt das von den verwendeten Datentypen und der Anzahl der Felder ab. Allerdings stellt sich bei einem AVR wirklich die Frage nach der Sinnhaftigkeit. Ich habe das nur zu Testzwecken ausprobiert. Interessanter finde ich den Einsatz auf kleinen 32 Bittern oder vielleicht auch 16 Bittern. Ich verwende es gerne auf einem ESP8266 und ESP32. Da komme ich dann mit 28kB für eine ernsthafte Konfiguration inklusive Stringsupport hin.
Thomas M. schrieb: > Die von Dir genannten Tools sind mir nicht bekannt. Dann solltest du vielleicht mal einen Blick darauf werfen (und sei es nur als Anregung) ;) https://google.github.io/flatbuffers/ https://capnproto.org/
Danke für den Hinweis. Manchmal entstehen Projekte parallel. Ich denke WFC hat seine eigenen Anwendungsbereich...
Thomas M. schrieb: > Der generierte Code referenziert eine bedarfsgerecht konfigurierte > Bibliothek mit Funktionen die ich erstellt habe und die der GPL > unterliegen. Das nur zur Erklärung. Dann schreib' das doch so rein, dass die 'Runtime' oder was das dann ist unter GPL steht. Das andere laesst sich nicht durchsetzen, da teile ich robbernights Ansicht. Im Uebrigen gibt es einige Firmen, die fuer in-house-Entwicklung die GPL gar nicht interessiert, die setzen sich einfach stinkfrech drueber hinweg oder benutzen einfache callback-tricks, wo ein FSF-Anwalt schon ins Schleudern kommt. Oder du verbiegst dich in Richtung LGPL. Sonst ein Tip: mach ne Dual-License draus, seltenst kommt da eine industriell relevante "contribution" bei rum, die dir da Schwierigkeiten mit GPL-Infektion deines Codes macht (fuer den du dir die Lizenz ja frei aussuchen darfst). Wenn der Kunde nur haben, aber nicht geben will, muss er eben fuer die Nutzungsrechte/IP blechen. Wenn er wiederum fuer die Entwicklung geblecht hat, ist es auch uncool, wenn das dann alles fuer die anderen gratis ist. Nachteil ist halt doppelte Wartungsarbeit.
Vielleicht macht es wirklich Sinn die Lizensierung unter GPL im README genauer zu erläutern und zu begründen. Für Kommerzielle Projekte würde ich Stand heute ein Doppel-Lizenz Modell anbieten, dass den Einsatz in closed Source Projekten ermöglicht. Contributions erwarte ich tatsächlich nicht in Form von Source. Und dass es Firmen gibt die um die GPL herumarbeiten ist mir bekannt. Das macht im Kontext von Serialisierungcode aber wahrscheinlich wenig Sinn. Sollte es bzgl. einer Evaluierung Vorbehalte gegenüber der GPL geben, so möchte ich betonen, dass ich eine Evaluierung grundsätzlich begrüße und deswegen dafür auf Anfrage ein kostenlose Ausnahmegenehmigung erteile.
Martin S. schrieb: > Im Uebrigen gibt es einige Firmen, die fuer in-house-Entwicklung die GPL > gar nicht interessiert, Solange die die Software nur in-House einsetzen und nicht weitergeben, ist das völlig legal, und nicht stinkfrech. Oliver
Oliver S. schrieb: > Martin S. schrieb: >> Im Uebrigen gibt es einige Firmen, die fuer in-house-Entwicklung die GPL >> gar nicht interessiert, > > Solange die die Software nur in-House einsetzen und nicht weitergeben, > ist das völlig legal, und nicht stinkfrech. > > Oliver Der Position schließe ich mich an. Problematisch wird es erst, wenn dann die Software mit GPL Anteil aus Versehen einer Partnerfirma im Rahmen der Zusammenarbeit überlassen wird. Dann steht der Partnerfirma plötzlich der Zugriff auf die Sourcen des gesamten damit "gelinkten" Umfangs zu. Wie das dann in Realität gelebt wird, ist wieder eine andere Geschichte. Wichtig finde ich vor allem, dass ein Software-Umfang, der an Kunden geht (mit oder ohne Elektronik), sich klar gegenüber dem Source Model positioniert. Wenn es ein Open Source Modell ist, sollte die GPL OK sein. Ansonsten ist eine wie auch immer geartete (kommerzielle) Lizenz notwendig.
Thomas M. schrieb: > Wenn es ein Open Source Modell ist, sollte die GPL OK sein. Es sei denn, das Open Source-Projekt steht nicht unter der GPL, sondern unter einer der anderen verbreiteten freien Lizenzen.
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.