Für die CS Entwicklung benötigt man somit immer eine wirklich freie Lizenz, wie bsp. die BSD Lizenz. Qt ist nicht frei genug
Ich ärgere mch auch immer warum Typen wie du nicht umsonst für mich arbeiten. Du könntest deine Arbeit ja unter die BSD-Lizenz stellen und mir dann das Geld zukommen lassen.
Von Lizenz nicht frei genug am Sa, 3. März 2018 um 19:34 #
Nein, du ärgerst dich nicht, du schreibst nur unqualifizierten Müll und hast in deinem Leben noch nie eigenen Code geschrieben.
Es geht nämlich nicht um das Geld, sondern um die Freiheit. Das Abomodell ist das Problem, eine für die CS Entwicklung geeignete Qt Lizenz bekommt man nämlich schon jetzt, nur eben im Abo, nicht als Pauschalbetrag. Einem Unternehmen kann es allerdings egal sein, wenn der Kunde die Software gekauft hat, warum sollte es das Abo weiterbezahlen, nur um in der Lage zu sein Sicherheitslücken zu stopfen? Das macht kein unternehmen, also kriegt der User langfristig seine Sicherheitslücken.
Richtig freie Lizenzen sind da besser und in der professionellen Softwareentwicklung auch üblich. Du kannst gerne mal deine Windows Partition nach der zlib Lizenz durchsuchen, du wirst dutzende Einträge finden, eben weil die zlib unter einer richtig freien Lizenz steht. Genauso lag die SDL 1.0 wie Blei im Regal, eben weil kein Unternehmen bei Verstand die LPGL anrührt. Damit gab es keine Rückmeldungen aus dem professionellen Bereich und die Entwicklung der SDL stagnierte. Deswegen hat man das bei der SDL 2.0 besser gemacht, man hat die Lizenz geändert und jetzt tragen professionelle Entwickler aktiv zur Entwicklung bei, da sie diese Version unter der freieren Lizenz auch nutzen.
Lies dazu vor allem auch mal folgenden Artikel durch, als Nichtprogrammierer wirst du zwar nur die Hälfte verstehen, aber dann kannst du wenigstens nicht mehr sagen, dass du davon nichts gewusst hast:
Es geht nämlich nicht um das Geld, sondern um die Freiheit.
Um die "Freiheit" die Software anderer in deinen eigenen Closed Source Projekten verwenden zu dürfen?
Lies dazu vor allem auch mal folgenden Artikel durch, als Nichtprogrammierer wirst du zwar nur die Hälfte verstehen
"Link is expiered". Das einem "Programmierer" wie dir so etwas passieren kannn, tststs...
Eein Vorschlag: Warum setzt du dich als "Programmierer" nicht hin, programmierst etwas ähnliches wie Qt und stellst das dann unter deine geliebte "freie" BSD Lizenz? Dann können Typen wie du nach herzenslust Cloed Source Software mit deinem Code bauen?
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.
Von Lizenz nicht frei genug am Sa, 3. März 2018 um 19:39 #
Auch solltest du dich nicht beschweren, wenn die Entwickler bei Windows bleiben und für dein Linux gar nichts entwickeln. Denn die GUI APIs bei Windows kann man mit ausreichender Freiheit nutzen und jederzeit Sicherheitslücken der eigenen Software stopfen, eben weil man die Lizenz für die API nicht teuer abonnieren muss.
Ich ärgere mch auch immer warum Typen wie du nicht umsonst für mich arbeiten. Du könntest deine Arbeit ja unter die BSD-Lizenz stellen und mir dann das Geld zukommen lassen.
Nein, du ärgerst dich nicht, du schreibst nur unqualifizierten Müll und hast in deinem Leben noch nie eigenen Code geschrieben.
Es geht nämlich nicht um das Geld, sondern um die Freiheit.
Das Abomodell ist das Problem, eine für die CS Entwicklung geeignete Qt Lizenz bekommt man nämlich schon jetzt, nur eben im Abo, nicht als Pauschalbetrag.
Einem Unternehmen kann es allerdings egal sein, wenn der Kunde die Software gekauft hat, warum sollte es das Abo weiterbezahlen, nur um in der Lage zu sein Sicherheitslücken zu stopfen?
Das macht kein unternehmen, also kriegt der User langfristig seine Sicherheitslücken.
Richtig freie Lizenzen sind da besser und in der professionellen Softwareentwicklung auch üblich.
Du kannst gerne mal deine Windows Partition nach der zlib Lizenz durchsuchen, du wirst dutzende Einträge finden, eben weil die zlib unter einer richtig freien Lizenz steht.
Genauso lag die SDL 1.0 wie Blei im Regal, eben weil kein Unternehmen bei Verstand die LPGL anrührt.
Damit gab es keine Rückmeldungen aus dem professionellen Bereich und die Entwicklung der SDL stagnierte.
Deswegen hat man das bei der SDL 2.0 besser gemacht, man hat die Lizenz geändert und jetzt tragen professionelle Entwickler aktiv zur Entwicklung bei, da sie diese Version unter der freieren Lizenz auch nutzen.
Lies dazu vor allem auch mal folgenden Artikel durch, als Nichtprogrammierer wirst du zwar nur die Hälfte verstehen, aber dann kannst du wenigstens nicht mehr sagen, dass du davon nichts gewusst hast:
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.html
Um die "Freiheit" die Software anderer in deinen eigenen Closed Source Projekten verwenden zu dürfen?
"Link is expiered". Das einem "Programmierer" wie dir so etwas passieren kannn, tststs...
Eein Vorschlag: Warum setzt du dich als "Programmierer" nicht hin, programmierst etwas ähnliches wie Qt und stellst das dann unter deine geliebte "freie" BSD Lizenz? Dann können Typen wie du nach herzenslust Cloed Source Software mit deinem Code bauen?
Oder geht's dir etwa garnicht um die "Freiheit"?
Also bei mir geht der Link.
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.
Beschwere dich bitte auch nicht, wenn du mehr Spam E-Mails bekommst und deine Server ständig von Botnetzen angegriffen werden
Du bist schließlich gegen das Stopfen von Sicherheitslücken und für die Verbreitung von Software mit solchen Lücken.
Auch solltest du dich nicht beschweren, wenn die Entwickler bei Windows bleiben und für dein Linux gar nichts entwickeln.
Denn die GUI APIs bei Windows kann man mit ausreichender Freiheit nutzen und jederzeit Sicherheitslücken der eigenen Software stopfen, eben weil man die Lizenz für die API nicht teuer abonnieren muss.
Der Vorteil von Windows ist, daß der Kunde die Lizenzgebühren für die GUI API direkt an Microsoft abdrückt. Aber klar, steht nicht in Deiner Rechnung.
Hoffentlich sit solche Milchmädchen Logik nicht auch in Deiner Software verbrreitet. Das kommt den Kunden dann noch teurer zu stehen kommen.
Tut es eben nicht...MS-Lizenzgebühren sind Stinkbillig im vergleich zu den Entwicklungskosten eines Programms.