Von The_Roadrunner123 am So, 4. März 2018 um 22:12 #
CS Proramme, die mit einer LIB, welche unter LGPL steht, gelinkt wurden, können sehr wohl andere LIBS statisch linken. Das wird nirgends verboten; auch nicht in der LGPL.
Und Probleme mit anderen Qt-Versionen umgehe ich im schlimmsten Fall mit .bat-File, bei dem ich einfach mein Verzeichnis anspringe bzw. die Path-Variable innerhalb meiner Shellumgebung anpasse.
Alles, was du deinem Kunden nur zur Verfügung stellen musst, ist die Möglichkeit, dass er die LIBS selbst übersetzt und zur Software packen können muss. Thatäs it. Ich habe bei mir in der Software ein Verweis auf die LGPL und bisher hat mich noch nie ein Kunde nach dem Source gefragt. Ich ändere auch nichts an den offiziellen Source, so dass ich genüsslich auf das Qt-Projekt "zeigen" kann.
Macht euch das Leben nicht schwerer, als es ohnehin nicht ist.
Von Zusammenfassung am Di, 6. März 2018 um 04:17 #
Auf folgenden Kommentaren bringt es jemand auf den Punkt:
Link 1
Sowie hier: Link 2
Die Essenz daraus ist für einen Chef einer kleinen Softwarefirma für kommerzieller Closed Source Software:
1. Benutze nicht eine Lib die auf der LGPL aufbaut, denn das wäre ein rechtliches Minenfeld. Anwälte haben kleine Softwarefirmen nicht inhouse.
2. Wenn es die Lib auch unter einer anderen Lizenz gibt, z.b. einer kostenpflichtigen proprietären Lizenz, dann nutze lieber die, damit ist Rechtssicherheit geschaffen.
3. Da nun die proprietäre Lizenz erworben wird und das Projekt irgendwann fertig ist und man sich das Lizenz Abo nach der Entwicklung sparen kann, endet der Support.
4. Nun greifen die Sicherheitslücken mit denen der Endnutzer dann leben muss.
5. Andere Systeme werden zur Zielscheibe, weil das System des Endnutzers kompromittiert ist.
Dabei könnte alles so einfach sein: A) Entweder man ändert die Lizenz zu einer wirklich freien Lizenz. Z.b. BSD, MIT usw. oder B) Man bietet die proprietäre Lizenz zu einem Pauschalbetrag an, damit die Sicherheitslücken auch noch später gestopft werden können.
Von Zusammenfassung am Di, 6. März 2018 um 04:19 #
Auf folgenden Kommentaren bringt es jemand auf den Punkt:
Link 1
Sowie hier: Link 2
Die Essenz daraus ist für einen Chef einer kleinen Softwarefirma für kommerzieller Closed Source Software:
1. Benutze nicht eine Lib die auf der LGPL aufbaut, denn das wäre ein rechtliches Minenfeld. Anwälte haben kleine Softwarefirmen nicht inhouse.
2. Wenn es die Lib auch unter einer anderen Lizenz gibt, z.b. einer kostenpflichtigen proprietären Lizenz, dann nutze lieber die, damit ist Rechtssicherheit geschaffen.
3. Da nun die proprietäre Lizenz erworben wird und das Projekt irgendwann fertig ist und man sich das Lizenz Abo nach der Entwicklung sparen kann, endet der Support.
4. Nun greifen die Sicherheitslücken mit denen der Endnutzer dann leben muss.
5. Andere Systeme werden zur Zielscheibe, weil das System des Endnutzers kompromittiert ist.
Dabei könnte alles so einfach sein: A) Entweder man ändert die Lizenz zu einer wirklich freien Lizenz. Z.b. BSD, MIT usw. oder B) Man bietet die proprietäre Lizenz zu einem Pauschalbetrag an, damit die Sicherheitslücken auch noch später gestopft werden können.
CS Proramme, die mit einer LIB, welche unter LGPL steht, gelinkt wurden, können sehr wohl andere LIBS statisch linken. Das wird nirgends verboten; auch nicht in der LGPL.
Und Probleme mit anderen Qt-Versionen umgehe ich im schlimmsten Fall mit .bat-File, bei dem ich einfach mein Verzeichnis anspringe bzw. die Path-Variable innerhalb meiner Shellumgebung anpasse.
Alles, was du deinem Kunden nur zur Verfügung stellen musst, ist die Möglichkeit, dass er die LIBS selbst übersetzt und zur Software packen können muss. Thatäs it.
Ich habe bei mir in der Software ein Verweis auf die LGPL und bisher hat mich noch nie ein Kunde nach dem Source gefragt. Ich ändere auch nichts an den offiziellen Source, so dass ich genüsslich auf das Qt-Projekt "zeigen" kann.
Macht euch das Leben nicht schwerer, als es ohnehin nicht ist.
Auf folgenden Kommentaren bringt es jemand auf den Punkt:
Link 1
Sowie hier:
Link 2
Die Essenz daraus ist für einen Chef einer kleinen Softwarefirma für kommerzieller Closed Source Software:
1. Benutze nicht eine Lib die auf der LGPL aufbaut, denn das wäre ein rechtliches Minenfeld. Anwälte haben kleine Softwarefirmen nicht inhouse.
2. Wenn es die Lib auch unter einer anderen Lizenz gibt, z.b. einer kostenpflichtigen proprietären Lizenz, dann nutze lieber die, damit ist Rechtssicherheit geschaffen.
3. Da nun die proprietäre Lizenz erworben wird und das Projekt irgendwann fertig ist und man sich das Lizenz Abo nach der Entwicklung sparen kann, endet der Support.
4. Nun greifen die Sicherheitslücken mit denen der Endnutzer dann leben muss.
5. Andere Systeme werden zur Zielscheibe, weil das System des Endnutzers kompromittiert ist.
Dabei könnte alles so einfach sein:
A) Entweder man ändert die Lizenz zu einer wirklich freien Lizenz. Z.b. BSD, MIT usw.
oder
B) Man bietet die proprietäre Lizenz zu einem Pauschalbetrag an, damit die Sicherheitslücken auch noch später gestopft werden können.
Auf folgenden Kommentaren bringt es jemand auf den Punkt:
Link 1
Sowie hier:
Link 2
Die Essenz daraus ist für einen Chef einer kleinen Softwarefirma für kommerzieller Closed Source Software:
1. Benutze nicht eine Lib die auf der LGPL aufbaut, denn das wäre ein rechtliches Minenfeld. Anwälte haben kleine Softwarefirmen nicht inhouse.
2. Wenn es die Lib auch unter einer anderen Lizenz gibt, z.b. einer kostenpflichtigen proprietären Lizenz, dann nutze lieber die, damit ist Rechtssicherheit geschaffen.
3. Da nun die proprietäre Lizenz erworben wird und das Projekt irgendwann fertig ist und man sich das Lizenz Abo nach der Entwicklung sparen kann, endet der Support.
4. Nun greifen die Sicherheitslücken mit denen der Endnutzer dann leben muss.
5. Andere Systeme werden zur Zielscheibe, weil das System des Endnutzers kompromittiert ist.
Dabei könnte alles so einfach sein:
A) Entweder man ändert die Lizenz zu einer wirklich freien Lizenz. Z.b. BSD, MIT usw.
oder
B) Man bietet die proprietäre Lizenz zu einem Pauschalbetrag an, damit die Sicherheitslücken auch noch später gestopft werden können.