mikrocontroller.net

Forum: Compiler & IDEs [Ann/GPL] Compiler für Datenserialisierung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Thomas M. (maierkomor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (maierkomor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (maierkomor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Thomas M. (maierkomor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Thomas M. (maierkomor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas M. (maierkomor)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ja, das liegt unter examples/hello-world.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (maierkomor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Thomas M. (maierkomor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis. Manchmal entstehen Projekte parallel. Ich denke 
WFC hat seine eigenen Anwendungsbereich...

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (maierkomor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas M. (maierkomor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.