Public Support

Nachtrag zur Vollständigkeit:
Es gibt nicht nur EB Lizenzen sondern mehr Vertriebspartner -> https://www.digitalwerk.net/adtf/vertriebspartner/
Alle haben einen eigenen Lizenzmechanismus, der aber mit der ADTF License Lib kompatibel sein muss, auch wenn künftig ein neuer Lizenzmechanismus entsteht.

Danke für die Klarstellung. Ich habe es so weitergegeben und warte auf Feedback, ob die DW-Pakete mit EB-Lizenzen funktionieren. Werde das Ticket dann aktualisieren, sobald ich Neues weiß.

Verstehe ich das richtig, dass in das DW-ADTF-Paket manuell bei jedem EB-Lizenz-Nutzer (also all unseren externen Partnern) noch eine licenser.dll reingepatcht werden muss ? Oder wird das DW-Paket dahingehend angepasst, dass die EB-DLL standardmäßig drin ist und somit von beiden Parteien (int und ext) genutzt werden kann?

Hallo Falk,

Im DW Paket ist natürlich auch die DW Licenser DLL/SO. Wir geben das Paket 1:1 an unsere Distributoren, so wie es für die ganze Welt verfügbar ist. Wenn ein Distributor eine eigene Logik und eine abweichende Lizenzierung mit eigener Licenser DLL/SO verwenden, müssen sie diesen auch reinpacken und austauschen, was sie soweit ich informiert bin auch tun. Der grundsätzliche Lizenzmechanismus (ADTF License Lib API) im Backend ist aber gleich, nur die Licenser DLL kann spezifisch sein und eine gewisse Logik bereitstellen. Es müssen allerdings die gleichen Flags natürlich implementiert werden.

Ich meinte zur Not müsst ihr einmal ein Pakte lokal patchen, man zieht das ADTF ja nur einmalig.

Sofern EB den Lizenzlibrary austauscht, gibt's keine generische Lösung

Von uns kommt die generische Lösung, die spezifische vom Distributor, d.h. hier muss die Abhilfe geschaffen werden. Rechtlich gibt es keine Probleme, dass ihr zusammenarbeitet.

Meiner Meinung nach müsstet ihr im recipe bei der Dependency lediglich den DW und den Distributor Channel unterscheiden, damit könnt ihr beide Abhängigkeiten nutzen.

Vielleicht ist es aber noch einfacher und die EB Licenser DLL/SO und deren Mechanismus ist kompatibel. Das sollte aber der EB Support beantworten bzw das lässt sich ja relativ schnell herausfinden, wenn eure Partner ein DW Paket mit einer EB Lizenz benutzen und zb den CE starten.

Vielleicht ist es aber noch einfacher und die EB Licenser DLL/SO und deren Mechanismus ist kompatibel. Das sollte aber der EB Support beantworten bzw das lässt sich ja relativ schnell herausfinden, wenn eure Partner ein DW Paket mit einer EB Lizenz benutzen und zb den CE starten."

• DW und EB-Lizenzen sind nicht kompatibel, die DLL muss überschrieben werden.
• EB-Support sagt, es ist weder vorgesehen noch möglich, die DW-Pakete zu verwenden

Ich weigere mich aktuell, die zur Verfügung gestellten Pakete zu "patchen". Wo sollen die gehostet werden, wer übernimmt den Support und die Aktualisierungen? Zumal das gepatchte Paket dann auch nur DW oder EB unterstützt. Oder man würde es on-the-fly im conan-install beim jeweiligen Nutzer zurechtbiegen, was aber auch wieder zu lokalen Änderungen am Paket führt.

Alternativ im Conan-Rezept des Plugins die zwei Paket-Dependencies zu unterschieden wird nicht sauber gehen, da je nach verwendeten ADTF-Paket eine andere Package-ID generiert wird und diese dann inkompatibel zueinander sind. Mal von der "Qualität der Lösung" abgesehen (if adtf_lic == "EB": ...)

Unser Anspruch ist, dass alle Projektpartner mit dem selben von DW bereitgestellten Conan-Paketen arbeiten. Ohne Hacks in den Dependencies oder den Paketen. Wir arbeiten mit diversen Partnern gemeinsam an den Plugins und Configs, die möglichen Fehlerursachen durch verschieden gepatchte Pakete will ich gern von vornherein ausschließen.

ist denn bekannt, ob die Pakete der anderen Distributoren die DW-License-DLL verwenden? Es wäre ja auch eine Option, dass sich die externen Partner von EB zu verabschieden und bei einem anderen Dist die Lizenzen kaufen.

Hi Florian,

erstmal Danke für deine detaillierte Antwort.

Wir haben uns bei den anderen Distributoren umgehört und diese nutzen den DW-Lizenzmechanismus. Die Entscheidung von EB wegzugehen liegt dann halt bei uns. Da es keine Anforderung zur Kompatibilität der Lizenzmechanismen gibt, kann sich das aber eben auch jederzeit ändern.

Wegen Patchen im Cache: Wenn man zuverlässig mit Conan arbeiten will, sollte der Cache ReadOnly sein, um eben genau lokale Unterschiede bei den Entwicklern auszuschließen. Das halte ich also für keine gute Idee. Außerdem wissen wir ja, wenn man erstmal mit sowas anfängt, wird dann lokal mit der Zeit hier und da noch mehr 'gepatcht', weil der Entwickler denkt, das löst irgend ein Problem. Und nur weil das Durchschnittslevel der Script-/Tool-Qualität "nicht perfekt" ist, würde ich mich ungern von vorn herein auf das selbe Niveau begeben :)

Problem bei der Fallunterscheidung im conanfile ist doch, dass ein Filter, der mit requires(ADTF@dw) arbeitet, eine andere package-id generiert als mit requires(ADTF@eb). Im Artifactory müssten dann immer beide Varianten von einem Jenkins gebaut werden. Alternativ könnte man das ADTF aus der package-id werfen oder zu einem build_requires() machen, sodass es nicht bei der package-id berücksichtigt wird. Beides sind meiner Meinung nach unsaubere Hacks (funktionieren aber zumindest).

Wenn es ein SDK-Paket ("header&libs") gäbe, was nur zum Bauen gebraucht wird, könnte man zumindest an der Stelle auf das doppelte Bauen oder Patchen der package-id verzichten. Im Moment braucht man ja sogar eine Lizenz, um die plugindescription zu generieren (der nächste Dorn in meinem Auge).

Wer ist denn der Kanal, um das Lizenzmechanismus-Thema und Lizenz-zum-Bauen-Thema einzuspeisen ... Alex?

Hi Falk,

Wegen Patchen im Cache: Wenn man zuverlässig mit Conan arbeiten will, sollte der Cache ReadOnly sein, um eben genau lokale Unterschiede bei den Entwicklern auszuschließen. Das halte ich also für keine gute Idee. Außerdem wissen wir ja, wenn man erstmal mit sowas anfängt, wird dann lokal mit der Zeit hier und da noch mehr 'gepatcht', weil der Entwickler denkt, das löst irgend ein Problem. Und nur weil das Durchschnittslevel der Script-/Tool-Qualität "nicht perfekt" ist, würde ich mich ungern von vorn herein auf das selbe Niveau begeben

Ja, bin ich bei dir, war wie gesagt eine absolute Notlösung aus dem ersten Schuss...

Problem bei der Fallunterscheidung im conanfile ist doch, dass ein Filter, der mit requires(ADTF@dw) arbeitet, eine andere package-id generiert als mit requires(ADTF@eb).

OK das wusst ich nicht

Im Artifactory müssten dann immer beide Varianten von einem Jenkins gebaut werden.

Hol mich mal ab... warum ist das ein Problem ?
In meiner Welt ist doch egal wer den Source Code baut bzw. das binary liefert.
Du definierst eine Abhängigkeit zu einen Produkt, Version und Channel ?

Ich habe den Use Case so verstanden:
Ihr entwickelt gemeinsam Filter oder tauscht binaries aus.
Das ist doch so oder so problemlos möglich ?
Sowohl der Build (mit Schalter im Recipe) als auch die Runtime (Session ohnehin unabhängig).

Vielleicht stehe ich auch auf der Leitung aber ich sehe nirgends einen Hash oder Package ID...

Alternativ könnte man das ADTF aus der package-id werfen oder zu einem build_requires() machen, sodass es nicht bei der package-id berücksichtigt wird. Beides sind meiner Meinung nach unsaubere Hacks (funktionieren aber zumindest).

Gut, wir arbeiten bei uns eigentlich ausschließlich mit build_requirements, das aber nur zur Vollständigkeit.
Demnach ist es bei uns egal, wo was liegt, definiert wird nur ADTF/x.y.z@bla/stable.
Nun kann ich aus X-bla-Quellen das Produkt beziehen, der eine definiert unseren Channel, der andere zb ein bintray, der nächste die CIP...

Wenn es ein SDK-Paket ("header&libs") gäbe, was nur zum Bauen gebraucht wird, könnte man zumindest an der Stelle auf das doppelte Bauen oder Patchen der package-id verzichten.

Versteh ich leider nicht... warum musst du doppelt bauen ?

Im Moment braucht man ja sogar eine Lizenz, um die plugindescription zu generieren (der nächste Dorn in meinem Auge).

Das ist so korrekt ! Der Plugin Description Generator fährt eine Runtime hoch und prüft die Dependencies.
Schau mal in deine Lizenz, natürlich musst du auf dem Build System eine ADTF Developer Lizenz haben.
Das lässt sich auch wunderbar abbilden.
Im Prinzip haben wir nun implizit endlich einen Schutz dafür :-)

Wer ist denn der Kanal, um das Lizenzmechanismus-Thema und Lizenz-zum-Bauen-Thema einzuspeisen ... Alex?

In allen Belangen werdet ihr von Pierre vertreten, ich schlage aber dennoch einen gemeinsamen Termin vor, unabhängig davon, dass er es dann "offiziell einspeist".
Mir sind noch zu viele Fragezeichen und wir brauchen eine gemeinsame Basis wie du siehst, ich sehe das Problem wie versucht zu schildern nicht an der Lösung bzw. warum sie für dich eher unsauber ist.

Technisch werden wir das Lizenz-implmentierungsthema (Mechanismus im Backend ist ja der gleiche) nicht lösen können denke ich, d.h. man müsste das vertraglich ändern.
Ggf. muss man weiter beim Thema open source anstoßen, dann könnte das ja an der ein oder anderen Stelle wegfallen.
Ändert aber nichts daran, dass auch ein SDK only Package einen Schutz braucht.

• Windows -> 350/420 MB
• Linux (Desktop) -> 750/630 MB
• Linux (ARMv8) -> 470/375 MB

Man könnte dann noch ein ADTF_SDK, ADTF_UISDK Package machen aber das sind dann ein paar MB hin oder her...
Werden wir aber bei der neuen Lizenzthematik bzgl. Qt bis zum nächsten Kundenforum aufbereiten.

Absprache am 29.04.2020 (Falk, Ralf, Tobi, Flo):

License/Package-Mismatch

• Kurzfristige Lösung: Falk wird Conan Recipe so anpassen, dass zwischen Lizenzen/Paketen unterschieden werden kann
  • Kontakt EB: Weißert, Thorsten <Thorsten.Weissert@elektrobit.com>
• Mittelfristige Lösung: Falk wird auf EB zugehen, dass deren Liceneser dll/so so angepasst wird, auch die EB Lizenz zu unterstützen (Option 1) bzw. die EB-Lizenz mit dem DW-Paket kompatibel ist (Option 2, bevorzugt)
• Langfristige Lösung: Als Thema im Kufo diskutieren, da in absehbarer sicherlich alle Mitglieder und somit deren Dienstleister davon betroffen sein werden
• Parallel: DW prüft, ob der Licenser als Extra Paket/Abhängigkeit ausgelagert werden kann

Lizenz im (Post)Build benötigt

• Rechtlich benötigt man ein Lizenz zum Build
• Der Plugin Description Generator ist frei von Lizenz, lädt aber u.U. lizenzierte Plugins (je nach Dependency)
• Die Generierung ließe sich umgehen (händisch, eigene Mechanismus), wie raten aber zum CMake Post Build Step um sicherzustellen, dass alles funktioniert (auch dann im CE)
• Unabhängig davon verstößt man wie erwähnt gegen Lizenzvereinbarungen
• Deshalb müssen auch sämtliche Build Maschinen lizenziert werden (technisch, rechtlich)
• Der Use Case des Buildvorgangs in der Cloud/Docker ist bei DW am Schirm und wird im neuen Lizenzmechanismus beachtet

Mit ADTF können nicht alle conan Features genutzt werden

• Fokus von ADTF: Build mit CMake
• Conan derzeit nur Mittel zum Zweck: Dependency Handling, Build Umgebung, Deployment/Artifactory-Anbindung
• Wir stellen es trotzdem bereit und decken so indirekt den geforderten Bedarf, der aber bisher noch nicht ausreichend ist
• Deshalb bringt Pierre das Thema conan (grundsätzlich) ins Kufo
• Parallel: Falk soll bitte Wünsche und Uses aufschreiben, gerne auch mit einem Bsp. Recipe, dann lässt sich das gemeinsam erarbeiten

zum letzten Punkt habe ich die #9404 noch einmal ergänzt.