qtforum.de

Hallo zusammen,

Also erstmal ich habe die Suchfunktionen benutzt und auch wirklich tausende threads über Lizenzen gefunden. Ich habe auch viele Infos gefunden nur wurden die teilweise wiederum in anderen Threads widerlegt.

Kurz zumir:
Ich bin ein wirklicher Programmieranfänger, außer einem Taschenrechner und paar Beispielprogrammen aus Büchern, habe ich bis auf mein derzeitiges Projekt nicht viel gewerkelt.

Das aktuelle Projekt:
Ich bin schon seit Ewigkeiten dabei ein kleines Programm für ein Spiel zu entwickeln.

Ich habe das Projekt dynamisch gelinkt, dazu die ganzen dll. Dateien, mingw, qtgui, qsqlite, und die sqltreiber mit ins verzeichnis kopiert.

Nun ist meine Frage ob ich das Programm so "closed Source" weitergeben darf?

Ich habe vor eine Sicherheitfunktion einzubauen, Das Spieler die die Seite wechseln(zu Feinden werden), keinen Zugriff mehr zum Datenbank bekommen. Die Lösung ist noch nicht ganz klar, überlege ob ich ein Server und Client Programm bastel, dass sozusagen die Programmfunktionen verlängern kann.

Das Programm möchte ich nicht verkaufen, sonden sozusagen kostenfrei den Teammitgliedern aushändigen, jedoch wie oben geschrieben jederzeit sperren können.Deshalb wäre für mich closed Source sehr wichtig.


Ich danke euch für Antworten

Vlg Strige

Dann nimmst du die LGPL von Qt:

http://www.gnu.de/documents/lgpl-2.1.de.html
Für dynamisches Linken ist §5 entscheidend:

§5. Ein Programm, das nichts von irgendeinem Teil der Bibliothek Abgeleitetes enthält, aber darauf ausgelegt ist, mit der Bibliothek zusammenzuarbeiten, indem es mit ihr compiliert oder gelinkt wird, nennt man ein „Werk, das die Bibliothek nutzt“. Solch ein Werk, für sich allein genommen, ist kein von der Bibiliothek abgeleitetes Werk und fällt daher nicht unter diese Lizenz.

Fazit:
Dein eingenes Werk (Programm) kannst du unter beliebiger Lizenz verbreiten (auch closed source) und die Qt-DLLs (nicht den Source!) verteilst du einfach mit (das erlaubt Qt). Mehr braucht man nicht beachten.

@softwaremaker
Wenn DU schon sowas qoutest, dann bitte komplett, und nicht wichtige DInge einfach weglassen. Der Text im Orginalwerk der auf deinen Quote folgt, ist alles andere als irrelevant in diesem Fall ...

@strige
Was softmaker vorschlaegt ist "rechtlich ungewisser Raum" in Deinem beschriebenen Umfeld (statische Importlibs unter windows).
Es kaem also auf ein vergleichsurteil an ... was es IMHO noch ned gibt.

Relevant wird das erst, wenn Nokia/TT(ziemlich unwahrscheinlich) oder ein Mitbewerber(konkurrent, zu was ??? ) Dich abmahnt. Und wenn dich dann wehrst, ist der ausgang ungewiss. Ergo auch nen Risiko fuer den Kläger.

Weiterhin musst beachten an wen das Prog verteilst. Wenn von der seite Probleme auszuschliessen sind ...
Wo kein Kläger ...

Auf der anderen Seite, ist was du anfuehrst scheinbar ned wirklich eine Begruendung fuer closed source, bzw ich versteh ned 100% warum "ein Team per software ausschliessen" willst.

Das ausschliessen kannst doch auch regeln über ne "zentrale verwaltung", wo nur du zugriff drauf hasst z.b.
Der code dazu kann öffentlich sein, aber ohne admin rechte aufn server wird keiner die daten aendern koennen z.b.

CLosed source wird eher verwendet, um ideen zu schuetzen, nicht um funktionalitaet zu schuetzen !


Ciao ...

@RHBaum:
Der restliche Text des §5 ist nicht entscheidend für dynamisches Linken!
Absatz 2 bezieht sich auf statisches Linken.
Absatz 3:

Wenn ein „Werk, das die Bibliothek nutzt“, Material aus einer Header-Datei verwendet, die Teil der Bibliothek ist, dann kann der Objektcode für das Werk ein von der Bibliothek abgeleitetes Werk sein, selbst wenn der Quelltext dies nicht ist. Ob dies jeweils zutrifft, ist besonders dann von Bedeutung, wenn das Werk ohne die Bibliothek gelinkt werden kann oder wenn das Werk selbst eine Bibliothek ist. Die genaue Grenze, von der an dies zutrifft, ist rechtlich nicht genau definiert.

Hier hat Qt folgendes festgelegt:
http://doc.qt.nokia.com/4.5/lgpl.html (ganz unten)

Nokia Qt LGPL Exception version 1.0

As a special exception to the GNU Lesser General Public License version 2.1, the object code form of a "work that uses the Library" may incorporate material from a header file that is part of the Library. You may distribute such object code under terms of your choice, provided that the incorporated material (i) does not exceed more than 5% of the total size of the Library; and (ii) is limited to numerical parameters, data structure layouts, accessors, macros, inline functions and templates.

Ist also auch rechtlich sicher (wie ich die max. 5% ermitteln soll weiss ich jedoch nicht

Da Absatz 1 aussagt, dass das eigene Werk nicht unter diese Lizenz (LGPL) fällt, braucht man §6 nicht beachten.
Die Qt-DLLs (unveränderte) gelten als Public Domain und können kostenlos ohne Einschränkung weitergegeben werden (Quelle hab ich jetzt nicht mehr).

Danke euch beiden erstmal für die Antworten,

Also, das mit dem ausschließen und wie ich das löse ist noch etwas unklar, auch weil ich kein eigenen Server habe;) da will ich mich jetzt erst die Tage mal hinsetzen^^. Warum ich das will ist einfach.

Durch das Programm entstehen gewisse Vorteile für die die es nutzen, Vorteile die natürlich auch gegen uns verwendet werden können, sobald jemand die Seiten wechselt^^ Deshalb soll man die Spieler, die zu Feinden werden, denen die Funktionalität nehmen.

Ich selber spiele das Spiel nicht sondern Bastel das Programm für ein Kumpel, dessen wünsche ich versuche so gut wie möglich umzusetzen;)
Das Programm läuft auch schon einwandfrei und bin schon auch etwas stolz auf mich, da es wie schon geschrieben mein erstes großes Projekt ist und bisher alles gewünschte realisieren konnte. .

Aber genau deshalb, wollte ich lizenztechnisch auf der sicheren Seite sein, wenn das Programm fertig ist, bekommts mein Kumpel und er darf/soll(ich will damit nix zutun haben) es verteilen wie er will und möchte dann sicher sein, dass nix auf mich wegen QT zurückfällt.

Leider verstehe ich nicht was es mit den Libs und Headerdateien aufsich hat. Von denen immer weider gesprochen wird wenns um Lizenzen geht .

Bisher habe ich nur verstanden, dass man die Qt.dll dateien dazupacken muss, was ja kein thema ist, aber die 5% in headerdatein, oder hier statische Importlibs?
Ich habe nur mit dem QtFramwork gearbeitet, Von QString bis QVector ist alles dabei, und natürlich deshalb auch hier und da in Headerdateien vertreten.

Ich glaube dass ich hier noch etwas falsch verstanden habe, aber sehe das ich auch noch sehr viel zu lernen habe um da mal richtig durchzusteigen.

Danke

Der restliche Text des §5 ist nicht entscheidend für dynamisches Linken!

und nu preisfrage, wie linkt man dynamisch unter windows ?
mit -lqtcore4 ?

Ich geb dir recht, wenn Du wirklich dynamisch linken wuerdest, waer die LGPL kein Problem, egal ob windows oder linux ... Das werden die Richter auch nicht anfechten.
Wenn wer da angreift, wird sich auf das -lqtcore4 beziehen ... Das grosse Fragezeichen ist halt, ist das rechtlich gesehen doch noch dynamisches linken ? Technisch gesehen ist es das eben nicht.
Und genau dieses Fragezeichen klärt Nokia / TT nicht expliziet.
Headercompilierte Anteile werden expliziet in der QT Version der LGPL geregelt ... und Importlibs unter windows nicht ? Ist das reines Versehen oder Absicht ?

Ciao ...

Also ich verwende das Qt-SDK (MinGW) und kompiliere Qt nicht neu sondern verwende die mitgelieferten, als dynamisch (nicht statisch) kompilierten Qt-Libs.

und im Makefile steht:
LIBS = -L"c:\Qt\2009.03\qt\lib" -lmingw32 -lqtmain -lQtGui4 -lQtCore4

Nachtrag:
Es wird doch kein Code aus den Qt-Libs in die App übernommen, sondern nur die Funktionsnamen etc., Wozu müsste ich sonst die DLL mitliefern.

http://blog.qt.nokia.com/2009/11/30/qt- ... -decision/
siehe "Edgar Crowdy" und Qt-Anwort ganz unten "@Edgar Crowdy".

Es wird doch kein Code aus den Qt-Libs in die App übernommen, sondern nur die Funktionsnamen etc., Wozu müsste ich sonst die DLL mitliefern.

Ja genau, hauptsaechlichst Symbole, Konstanten etc.
Nichtsdestotrotz werden die statisch zu Deiner Exe gelinkt !
Dadurch wird die Austauschbarkeit erheblich eingeschraenkt, da Du nicht einfach nur Funktionenssignaturen nachbauen muesstest um die qt zu ersetzen, sondern auch alles drumherum binaerkompatibel und mit den selben Symbolnamen generieren musst. eigentlich fast unmöglich, ohne teile der QT header einfach zu kopieren.

Fazit: ein Punkt der LGPL, nämlich die Austauschbarkeit der Bib (deswegen ja das dyn. linken) ist nicht mehr so ohne weiteres gegeben. Deshalb mein ich, es ist rechtlich ungewiss !

Weiterhin besteht die Frage, ob symbole, symbolnamen konstanten etc zu schnittstellen oder code gehoeren ? Ob ne Lib, die automatisch generiert wird und keine funktionalitaet beinhaltet, "schuetzenswerten" code beinhaltet ?
Da möcht ich nur an die M$ Aktion erinnern, mit dem DirectX- und "ich nutze nicht den Visual Studio Compiler" problem.
Da ging der "Streit" "nur" um Konstanten (uuids) die man fuer die Schnittstelle brauchte, und die M$ in ne Lib gepackt hat.
Fazit:Irgendwer hatte entschieden, das die lib die nur aus konstanten besteht, schuetzenswert ist .....

Wie gesagt, das ganze Problem dreht sich um die Sache, ist eine dll linken mit importlibs noch dynamisches linken im rechtlichen Sinne ? Und dazu gibts noch keine festen Aussagen. Und auch TT/Nokia reden da um den heissen Brei herum (verstaendlich, weil die Konsequenzen fuer eine Grundsatzentscheidung in Bezug auf andere Bibliotheken nicht absehbar sind)....

The main point of the LGPL is that user of an application can modify the Qt libraries, relink to the application and run the modified program.

und genau das ist nur noch eingeschraenkt möglich. Du brauchst nur was zu aendern, was sich auf die importlib durchschlaegt, und schon musst du die lib neu gegen die exe linken ... was nicht geht da die source der exe nicht hasst.
Prinzipiell hasst dieses Problem bei nem dynamischen dll linken genau so ... aber muss das dynamische Interface genau beschrieben sein.
Bei den Importlibs ist das statische interface beschrieben, du also weisst gar nicht welche symbole wie generiert werden und konstanten etc wo liegen. Also du kennst das interface zwischen lib und dll bei der qt gar nicht. -> ergo du kannst nur eingeschraenkt funktionalitaet an den dlls aendern.
Wuerdest du das interface analysieren und verstehen ... braeuchtest wiederum die importlibs nimmer, und koenntest die QT dll's 100% dynamsich laden .. mit loadlibrary.

Anmerkung:
Auch wenns so klingt ... Ich behaupte nicht das LGPL + importlibs nicht möglich sein sollten/könnten/müssten. Rechtlich weiss ich es eben nicht, und es gibt keinen Fall wo man sich drauf stuetzen kann.
In unserer Firma wird LGPL und GPL sowieso abgelehnt, wegen "rechtlichen" Unsicherheiten. Das meint zumindest unsere Rechtsabteilung ... ergo wir haben sowieso ne kommerzielle Lizenz. Aber ich darf nichts einsetzen was unter LGPL/GPL steht und was nach aussen geht. Aus der Opensource Welt darf ich nur richtig freie Dinge (freeware, public domain) verwenden.

Das ganze ist natzürlich für den TE alles total rein theorethisch.
Praktisch gibts ne ganz andere Sicht :
- Verteilt er sein Programm unter der Hand, isser eh kaum angreifbar.
- geht es hier um keinerlei betraege bei Ihm, es wird sich also niemand finden der richtig klagen will ... maximal die Abmahnkosten wuerde wer im Auge haben koennen
- Recht haben und Recht bekommen ist in DL immer noch nen Unterschied.

Fazit: Nen "privater" Programmierer, hat mehr Risiko weil er wahrscheinlich einen Rechner am "Netz" betreibt, durch andere Dinge in nen Rechtstreit zu geraten und um Abmahnkosten kaempfen zu muessen (bsp. Abo fallen, GEZ relevante dinge, Urheberrechtsklagen ueber dinge die man nie getan hat, weil irgendwer IPs falsch ermittelt hat) .... als mit Rechtlichen konsequenzen zu kaempfen wenn er nen Programm unter GPL verteilt und "ausversehen vergisst" den quellcode mitzuliefern / auf Anfrage zuzustellen .

Ciao ...

Ich hab kein Windows und kenn mich deshalb auch mit dessen ganzen Spezialitäten nicht wirklich aus. Aber ich geh davon aus, dass diese .libs identlisch ausschauen, wenn die Bibliothek binärkompatibel bleibt. Wenn sich nix an der ABI ändert, kann ich problemlos die .dlls austauschen. Und Qt bemüht sich eigentlich, binärkompatibel zu bleiben. Bei mir unter Linux hatte ich noch nie Probleme, wenn ich ein Qt-Update gemacht hab. Erst kürzlich hab ich qt von 4.6.3 auf 4.7.0 aktualisiert (am 23.09.), Probleme mit kde und allen anderen Qt-Programme gab es nicht.
Wenn das unter Windows nicht so ist, kann RHBaum natürlich Recht haben (Austausch nachträglich nicht möglich), dann wäre aber schon längst jemand auf die Idee gekommen und hätte die LGPL um einen entsprechenden Passus erweitert. Ich hab unter Linux noch kein einziges proprietäres Programm installiert, das Qt mit LGPL gelinkt hätte, Proprietäre Applikationen + LGPL sind wohl am meisten unter Win/Mac anzutreffen, deshalb nehme ich dass die LGPL auch unter Windows (mit den normalen Link.Mechanismen) keine Probleme bereitet.

Ich hab unter Linux noch kein einziges proprietäres Programm installiert, das Qt mit LGPL gelinkt hätte, Proprietäre Applikationen + LGPL sind wohl am meisten unter Win/Mac anzutreffen, deshalb nehme ich dass die LGPL auch unter Windows (mit den normalen Link.Mechanismen) keine Probleme bereitet.

Hüstel ...
Also Ich seh das genau andersrum
In der Windows-Welt wird die LGPL von vielen namenhaften Firmen torpediert Ich kenn keine "windows only" Bib, die unter LGPL steht. DIe die ich kenne die unter LGPL und windows verfuegbar sind, haben eine Pendant in nem anderen system. Sei es unix, meist linux ...
Aber sicher gibt es auch welche ...

Unter Linux hingegen iss die LGPL/LGPL ähnliche Lizenzen schon fasst extentiell. Die GPL schliesst eine Nicht-GPL konforme Lizenz in einem von unter GPL stehenden Abhaengigen Lib aus. Und nicht GPL kompatibel heisst nicht immer gleich kommerziell.
Ohne die LGPL/ähnliche Lizenzen duerftest Du Lizenzrechtlich gesehen einige software gar nicht nutzen / bzw wuerde da auch rechtsunsicherheit bestehen.

@franzf
Ich weiss ned was fuer eine Distri du benutzt, aber ich bin mir sicher das du einige LGPL Dinger drauf hasst, grad im Bereich audio/video formate
Freeware, frei verfuegbar, Opensource etc sind halt nicht immer das selbe
Problem war, fuer viele libs war die GPL immer nicht praktikabel / zu hart / zu zwingend. Ergebniss war, das ne Menge eigener Lizenzen entstanden sind ... die LGPL iss nen versuch, ne einheitliche Lizenz fuer solche zu Faelle zu schaffen, mit mehr oder weniger Erfolg

Gaeb es nur windows, gab es kein GNU(linux) keine GPL und erst recht keine LGPL. Unter windows ist entweder rein closed source (der Hersteller bestimmt allein die regeln) oder public domain (eher seltener, aber man bekommt auch fuer manche windows programme den quellcode).
die Regel .

Ciao ...