Programmieren Lazarus oder Qt?

[Yaakoss]

Ganz einfach, du kannst mit QT entwickeln, und deinen Code für dich behalten. Aber sobald du deine Anwendung verbreitest musst du entweder diese OHNE die verwendeten QT-Libraries vertreiben, oder deren Quellcode mitliefern. Dies gilt wenn deine Anwendung dynamisch gegen diese Libraries gelinkt wurde.
Wurde hingegen statisch verlinkt, was bei Windows-Anwendungen durchaus der Fall sein könnte, dann ist der Fall nicht mehr so einfach. In diesem Falle kann es durchaus der Fall sein, dass deine Anwendung selbst zu einer LGPL-Anwendug wird und dann musst du den Code veröffentlichen.
Das steht wie gesagt in dem von mir verlinktem Text und lässt sich auch bei anderen Quellen bezüglich LGPL3 überprüfen.

LGPL bedeutet nicht, dass du mit den Sachen absolute Narrenfreiheit hast, sondern, setzt bestimmte Dinge voraus.

 

[pseudopseudonym]

oder deren Quellcode mitliefern

Das klingt schon ganz anders als deine ursprüngliche Aussage:

immer den Quellcode deiner Programme veröffentlichen

 

[andy_0]

Es ist definitiv ein guter Hinweis die jeweilige Lizenz zu prüfen.

 

[Schwachkopp]

Das Thema hat ein paar Fallstricke... Folgendes ist nur meine Meinung:

1. Die meisten Qt-Bibliotheken / Module verwenden, soweit ich weiß, die LGPL (3). Was ich hier schreibe bezieht sich nur auf diese Lizenz.

2 Standardmäßig benutzt der Qt Creator Dynamic Linking, jedenfalls wenn man ihn von der Offiziellen Seite lädt und unter Windows installiert.

3 Es stimmt nicht, dass man den eigenen Quellcode zur Verfügung stellen muss (so habe ich einen der Kommentare hier verstanden) wenn man Qt-Libraries verwendet und die Software weitergibt. Ausnahme ist wenn man eine Qt-Library nicht nur benutzt sondern verändert. Das sollte aber i.d.R nicht notwendig sein.


Es ist besser dazu ein paar neutralere Quellen zu konsultieren als die Qt-Website, z.B. diese hier

https://embeddeduse.com/2023/01/06/using-qt-5-15-and-qt-6-under-lgplv3/

• We may release our combined work – our software combined with the Qt libraries under LGPL-3.0 – under a license of our choice, if we satisfy the following obligations.
  • (4a) We give prominent notice (e.g., in the user manual) that our software uses Qt under LGPL-3.0.
  • (4b) We provide copies of the LGPL-3.0 and GPL-3.0 to the buyers of the software, where buyers are businesses or consumers (private persons).
  • (4c) We display the copyright notices of Qt and the license texts of LGPL-3.0 and GPL-3.0 prominently in the user interface.
  • (4d) We provide the mechanism of either (4d0) or (4d1) to link our software with a potentially modified but interface-compatible version of the Qt libraries.
    • (4d0) We use any mechanism for linking – including static linking.
    • (4d1) We use dynamic linking to combine our software with the shared Qt libraries.
  • (4e) We provide installation information (according to clause “6. Conveying Non-Source Forms” of the GPL-3.0) how to build a modified version of Qt, how to install Qt on the device, and how to run the software with Qt on the device. This clause only applies to Consumer products.
• Let me spell out the ramifications of the above clause in plain English.
  • We can keep the source code of our software secret (see the first sentence).
  • We can link our software with shared or static Qt libraries (see (4d0) and (4d1)). If we use static linking, we must provide the object files of our software. We don’t have to do that for dynamic linking.

Auch findet man dazu einige Diskussionen auf Stackoverflow, die dies bestätigen. Genannte Object Files (*.obj) werden beim Kompilieren der Software erzeugt.


Hier nochmal etwas Offizielleres:
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)
For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

(2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Das wirkt vielleicht erst einmal abschrecken, ist aber halb so wild und daher würde ich meine Entscheidung nicht davon abhängig machen.

 

[BeBur]

Das wirkt vielleicht erst einmal abschrecken, ist aber halb so wild und daher würde ich meine Entscheidung nicht davon abhängig machen.

Zumal ja nicht geplant ist, das Resultat kommerziell zu verwerten.

(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

Interessant. Das scheint mir ein ziemlich guter Kompromiss zu sein. Hat das für den Ersteller einer Qt Anwendung schwerwiegende Nachteile (im kommerziellen Kontext)? Das sorgt ja erst einmal vor allem dafür, dass die Applikation ggf. mit einer neueren Qt Version verwendet werden könnte, auch wenn es keine Updates mehr für die Applikation gibt.

 

[andy_m4]

Aber sobald du deine Anwendung verbreitest musst du entweder diese OHNE die verwendeten QT-Libraries vertreiben, oder deren Quellcode mitliefern. Dies gilt wenn deine Anwendung dynamisch gegen diese Libraries gelinkt wurde.

Ich hab nichts anderes behauptet.

LGPL bedeutet nicht, dass du mit den Sachen absolute Narrenfreiheit hast, sondern, setzt bestimmte Dinge voraus.

Das war nie meine Behauptung.
Du drehst Dir hier ganz schön was zurecht.
Und der andere Kram von Dir wurde ja bereits widerlegt.

 

[Yaakoss]

Das war nie meine Behauptung.
Du drehst Dir hier ganz schön was zurecht.
Und der andere Kram von Dir wurde ja bereits widerlegt.

Ich denke du interpretierst hier Sachen rein, die ich so nicht gesagt habe, aber gut.

Der Threadersteller hat nach einer Freien Entwicklungsumgebung gefragt. Das trifft auf QT nicht komplett zu. Deswegen habe ich das Thema ins Spiel gebracht.

Die Lizenz welche Lazarus beiliegt ist mMn. freier und erlaubt mehr.

Ich schätze Diskussionen auf Augenhöhe, denn ein Hilfeforum lebt von solchen Dingen. Das vermisse ich bei deinen Antworten. Daher, viel Spass noch. Ich ziehe mich aus dem Thema heraus.

lg
Patricia

 

[andy_m4]

Ich denke du interpretierst hier Sachen rein, die ich so nicht gesagt habe, aber gut.

Jaja.

Ich schätze Diskussionen auf Augenhöhe

Dazu gehört, das man Fehler einräumt (die ja passieren können; ist ja nix Schlimmes) und die nicht einfach auf den anderen abwälzt.
Wie gesagt: Ich bin mit meiner Einschätzung bezüglich der Lizenz ja nicht alleine. Und da könnte man ja dann doch mal ins Nachdenken kommen, ob da nicht was dran ist.

 

[Yaakoss]

@andy_m4
Sorry, das ist echt daneben.

Ja mir ist durchaus ein Fehler in dem geschriebenen unterlaufen, auf den von anderen hingewiesen wurde.
Bei der Weitergabe des Programms müssen aber bestimmte Bedingungen eben erfüllt werden.

Nur unterstelle ich Dir weder irgendwelche Sachen noch wälze ich irgendwelche Fehler auf Dich ab, was du ja behauptest.

Belassen wir es doch einfach dabei. Ich habe wirklich keinerlei Bedarf auf Diskussionen dieser Art mit Dir.

Ich wünsche Dir noch einen entspannten und angenehmen Abend
Patricia

 

[Schwachkopp]

Interessant. Das scheint mir ein ziemlich guter Kompromiss zu sein. Hat das für den Ersteller einer Qt Anwendung schwerwiegende Nachteile (im kommerziellen Kontext)? Das sorgt ja erst einmal vor allem dafür, dass die Applikation ggf. mit einer neueren Qt Version verwendet werden könnte, auch wenn es keine Updates mehr für die Applikation gibt.

Ich vermute die würden zur kommerziellen Lizenz von Qt greifen und hätte daher das Problem nicht, falls es überhaupt eines ist. Sonst kann ich dazu leider nicht viel sagen, da ich Qt bisher nur hobbymäßig nutze.

 

[simpsonsfan]

@BeBur Ein Softwarehersteller könnte u.U. schon daran interessiert sein, dass seine Anwendung nicht gegen die neuesten Versionen aller verwendeten Libraries gelinkt werden kann, wenn er nämlich bspw. diese neuen Version selbst als Feature in der nächsten Version anpreisen möchte. Oder natürlich, um Bugs zu vermeiden, die dann beim Zusammenspiel auftreten können.

Aber ich erinnere mich da bspw. einige Jahre zurück an die Einführung von AVX512. Ein Hersteller einer Simulationssoftware hatte für die neue Programmversion den Speedup beworben. Der kam dabei hauptsächlich von der neueren MathKernelLibrary, die in der neuen Version gelinkt wurde und eben AVX512 unterstützte.
Wenn jemand nun die neuere MKL in der älteren Programmversion linkt, dann hat er den Speedup kostenfrei.

 

[svkra1973]

Also ich würde hier mal Net(c#) mit AvaloniaUI in den Raum werfen. Es ähnelt ein wenig von der Entwicklung an Web-Frontends.

Dazu noch Jet-Brains Rider als Entwicklunsumgebung. Das hat eine gute Unterstützung für Avalonia und das gibt es für nicht kommerzielle Zwecke mittlerweile auch kostenlos sowohl für Linux, wie auch Windows.

Alternativ ginge auch Visual-Studio Code, wobei ich unter Windows klar die Visual Studio Community Edition empfehlen würde.

Für den Datenbank-Part kann man da ja ein Entity-Framework einsetzen. Z.b. für den Anfang mit Sqlite. Das abstrahiert dann einiges von der SQL-Ebene weg.

Ich bin primär C++ Entwickler und würde das als Einstieg nicht empfehlen. Neben Qt würde ich hier noch wxWidgets erwähnen, hat den Vorteil das diese immer das native Look&Feel behält, da es möglichst native GUI-Elemente verwendet.