Von Lizenz nicht frei genug am Sa, 3. März 2018 um 18:10 #
Das gilt insbesondere für Closed Source Software.
Denn damit man eine CS Software die Qt verwendet weiterentwickeln darf, und das schließt das Patchen und schließen von Sicherheitslücken mit ein, muss man dauerhaft eine monatlichen Abogebühr an die Qt Eigentümer bezahlen.
Da kann man sich leicht denken, dass ein kleiner Betrieb das nach 2 Jahren nicht mehr macht, wenn er auf ein anderes GUI Toolkit umgeschwenkt ist und somit das Abo beendet. Dann kann es für seine Qt Anwendungen keine Patches mehr geben.
Die, die jetzt sagen, es gibt ja noch die LGPL, denen sei gesagt, dass das so in der Praxis nicht funktioniert. In der Praxis kann es nämlich durchaus passieren, dass man eine Lib oder Teile davon fester einbinden muss oder dies unbeabsichtigt tut, also statisch und das erlaubt die LGPL nicht. Für die CS Entwicklung benötigt man somit immer eine wirklich freie Lizenz, wie bsp. die BSD Lizenz.
Qt ist nicht frei genug und weil es nicht frei genug ist begünstigt es das Ergebnis, dass Sicherheitslücken nie mehr gestopft werden.
Jedem CS Entwickler muss man daher von Qt abraten.
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.
Jedem Kunden sollte man von CS-Software abraten. Kann man nicht vertrauen und prüfen (lassen), kann man nicht selbst fixen (lassen) falls nötig, sondern ist auf Gedeih und Verderb dem Hersteller verbunden. Und wenn der pleite ist, hurra, Ende im Gelände.
> Für die CS Entwicklung benötigt man somit immer eine wirklich freie Lizenz, wie bsp. die BSD Lizenz.
Für die CS-Entwicklung benätigt man vor allem Skrupellosigkeit, seine Kunden in Abhängigkeit zu nötigen. Aber dazu paßt irgendwie diese dreiste Gier, die Leistungen anderer kostenlos abzugreifen.
Von Software Entwickler am So, 4. März 2018 um 18:29 #
Eigentlich bist du derjenige, der gierig ist, weil du für Software nichts bezahlen willst.
Jeder Mensch weiß, dass OS Lizenz Modelle nicht bei jeder Art von Software funktionieren und der Programmierer muss auch noch seine Familie ernähren können.
Der Ton hier überrascht mich allerdings nicht. Es ist schließlich keine Plattform bei der Softwareentwickler untereinander diskutieren, sondern überwiegend eben nur Open Source Fanboys die Software meist nur nutzen und nicht selbst entwickeln. Daher wird das auch nicht mit dem Linken und den Gefahren dabei verstanden.
OSS muss nicht gratis sein, Du kannst mit OSS gutes Geld verdienen ohne deine Kunden zu verarschen. Deiner Logk zufolge hat das Framework "gratis" zu sein...dein hochehrwuerdige Arbeit ist aber CS??? Schreage Logik... Mit BSD hast Du aber absolut recht
Immerhin konsequent weitergeführte Realitätsverbiegung. Ich schrieb nichts davon, daß ich für "Software nichts bezahlen" will. Was immer das auch heißen soll, "für Software". Das Recht, die Software zu verwenden? Eine harte/weiche Kopie der Software?
Die einzige Artt von Software, die ich als Exemplar des jeder Mensch kenne, bei der CS zwingend für das Geschäftsmodell ist, sind Trojaner.
Meine Fresse auf so viel Bullshit kann ich gar nicht als Ganzes eingehen... Warum verbreitest du wissentlich Lügen?
Die L-GPL ist absolut geeignet für CS Software. Abgesehen davon, dass statisches Linken keinerlei Vorteile bietet, erlaubt die L-GPL sehr wohl das statische Linken. Hast du die Lizenz überhaupt einmal gelesen? Die L-GPL funktioniert wunderbar selbst für Anwendungen in medizinischen-, militärischen oder Automotive Anwendungen, aber für deine Pillepalle ist sie nicht geeignet. Ja, schon recht. Wenn man keine Ahnung hat...
Ist das ein Wettbewerb in Sachen Bullshit? Und dann ist "wissentlich" vielleicht eine wohlmeinende Überschätzung des Diskustanten
Statisches Linken hat einige Vorteile. Befrage die Informatiklehrerin Deines Vertrauens (meine war gut damals). Oder füttere die Suchmaschine Deines Vertrauens mit "statisch linken vorteil" (achte bei den Antworten/Suchergebnissen auf Begriffe wie Startzeit, Größe der ausführbaren Datei, Optimierungen von Codelogik.
Die LGPL fordert für das statische Linken die Bereitstellung von allem, was ein neues Erzeugen und Einbinden des Codes, der unter LGPL steht, verlangt. Also vom proprietären Code mindestens die Objektdateien, wenn nicht sogar den Quellcode im Falle von Kompilaten. Inklusive des Gestattens von Analyse des proprietären Materials, zum Debuggen der Einbindung. Was dem Diskutant vermutlich schon gegen seinen Mein-Code-Voll-Wichtig-Geheim-Strich geht.
Besser als Ahnung ist Wissen. Aber wer weiß schon, daß er nichts weiß.
Danke, ich weiß sehr gut was statisches Linken mit einem Binary anrichtet. Deshalb weiß ich auch, dass es keinerlei praktische Vorteile bringt. Und die theoretischen, die es hat sind ebenso mithilfe von Prelinking zB. erreichbar.
Und zum zweiten Teil gibst du dir ja sogar selbst die Antwort. Bei statisch gelinkten Binaries müsstest du die Object Files liefern + Linkerscript. Aber eben keinen Code. Und die explizite Erlaubnis zum Reverse Engineering ist auch kein Hindernis denn Reverse Engineering kann ohnehin nicht rechtswirksam untersagt werden. Im Gegenteil, diverse EU Richtlinien erlauben RE von Software sogar explizit.
Das mit der Praxis ist so ein Ding, die läßt sich nicht aus eigener Erfahrung verallgemeinern, sondern ist nur mit statistischen Mitteln erfaßbar. Nicht jeder verwendet die volle Breite einer API. Und so mancher Compiler kann Wunder bewirken, wenn er nicht an einer Symbolgrenze Halt machen muß, sondern da weiter den AST vor sich hin optimieren kann. Aus meiner Praxis würde ich eher sagen, daß da so einige Vorteile lungern können. Kommt immer auf den Fall drauf an.
Was den zweiten Teil betrifft, da hatte ich keine Frage. Sondern nur ein wenig Ergänzung gegeben für die, die vielleicht die näheren Umstände wissen sollten, aber nicht motiviert genug sind, nachzulesen. EU-Recht gilt dann aber auch nur für die EU. Sobald man das Vergnügen hat, über die See zu liefern/erwerben, wird der Teil dann auch wieder interessant. Zum Glück nicht mein Ding.
Von Software Entwickler am So, 4. März 2018 um 18:41 #
Die L-GPL ist absolut geeignet für CS Software.
Nur auf dem Papier, in der Praxis linkst du unbeabsichtigt ne Headerdatei dazu, weil du die unbedingt brauchst. Vor allem bei Qt ist die Gefahr groß und schon hast du die LGPL unwissentlich verletzt.
Statisches Linken bietet sehr wohl Vorteile, vor allem wenn es die einzige Software auf der Zielplattform ist, die Qt verwenden soll.
Statisches Linken erlaubt die LGPL bei CS Software nur, wenn du den Objektcode mitlieferst. Also Weltfremd. Die Praxis funktioniert anders.
Den oben verlinkten Artikel solltest du dir durchlesen.
All das ändert übrigens nichts daran, dass das Abomodell von Qt für CS Software Mist ist und in der Tat Sicherheitslücken begünstigt, weil die dann nie mehr gestopft werden, wenn das Projekt zu Ende entwickelt wurde und das Abo beendet wurde. Bei Pauschallizenzen hat man solche Probleme nicht, das gleiche gilt für freie BSD oder zlib artige Lizenzen, da kann man dann das wesentliche in seine CS einbinden, selbst wenn die alte Lib nicht mehr weitergepflegt wird. Für kleine Unternehmen kann letzteres der Todesstoß bedeuten.
Ich empfehle dir einfach mal mit Programmierern und Software Entwickler aus der Praxis, die Closed Source Software entwickeln, über die LGPL zu disktutieren. Es hat seinen Grund, warum praktisch kein CS Projekt LGPL Libs verwendet. Bei Qt kriegt man noch die proprietäre Lizenz im Abo, mit oben erwähnen Nachteile, aber allein die LGPL die rührt da auch niemand für ein CS Projekt an.
Letzten Endes hat es zwei Auswirkungen: 1. Die Softwareentwickler bleiben bei der Plattform bei der sie eine brauchbare GUI Lib haben, die ihnen rechtlich nicht im Weg steht. und 2. Sollten die dann doch Qt wählen, dann gibt's nach 3-4 Jahren keine Patches mehr, wenn das Abo für die propritäre Lizenz beendet wurde.
Von Software Entwickler am So, 4. März 2018 um 18:46 #
Kleine Ergänzung, ich meinte
..., in der Praxis linkst du unbeabsichtigt durch die Header Datei Code hinzu, ....und schon hast du die LGPL unwissentlich verletzt.
Da muss man also höllisch aufpassen. Das kann man beim kommerziellen Coden niemandem empfehlen, vor allen da die Coder in der Regel alle keine Juristen sind.
Das gilt insbesondere für Closed Source Software.
Denn damit man eine CS Software die Qt verwendet weiterentwickeln darf, und das schließt das Patchen und schließen von Sicherheitslücken mit ein, muss man dauerhaft eine monatlichen Abogebühr an die Qt Eigentümer bezahlen.
Da kann man sich leicht denken, dass ein kleiner Betrieb das nach 2 Jahren nicht mehr macht, wenn er auf ein anderes GUI Toolkit umgeschwenkt ist und somit das Abo beendet.
Dann kann es für seine Qt Anwendungen keine Patches mehr geben.
Die, die jetzt sagen, es gibt ja noch die LGPL, denen sei gesagt, dass das so in der Praxis nicht funktioniert. In der Praxis kann es nämlich durchaus passieren, dass man eine Lib oder Teile davon fester einbinden muss oder dies unbeabsichtigt tut, also statisch und das erlaubt die LGPL nicht.
Für die CS Entwicklung benötigt man somit immer eine wirklich freie Lizenz, wie bsp. die BSD Lizenz.
Qt ist nicht frei genug und weil es nicht frei genug ist begünstigt es das Ergebnis, dass Sicherheitslücken nie mehr gestopft werden.
Jedem CS Entwickler muss man daher von Qt abraten.
Lösbar wäre es übrigens durch ein anderes Bezahlmodell für die CS Lizenz das das statische linken erlaubt.
Und zwar ein Bezahlmodell bei dem man einmal pauschal bezahlt und dann so oft seine Software verändern darf wie man will.
Die Lösung mit dem Abomodell ist dafür nicht geeignet.
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.
Jedem Kunden sollte man von CS-Software abraten. Kann man nicht vertrauen und prüfen (lassen), kann man nicht selbst fixen (lassen) falls nötig, sondern ist auf Gedeih und Verderb dem Hersteller verbunden. Und wenn der pleite ist, hurra, Ende im Gelände.
> Für die CS Entwicklung benötigt man somit immer eine wirklich freie Lizenz, wie bsp. die BSD Lizenz.
Für die CS-Entwicklung benätigt man vor allem Skrupellosigkeit, seine Kunden in Abhängigkeit zu nötigen. Aber dazu paßt irgendwie diese dreiste Gier, die Leistungen anderer kostenlos abzugreifen.
Eigentlich bist du derjenige, der gierig ist, weil du für Software nichts bezahlen willst.
Jeder Mensch weiß, dass OS Lizenz Modelle nicht bei jeder Art von Software funktionieren und der Programmierer muss auch noch seine Familie ernähren können.
Der Ton hier überrascht mich allerdings nicht.
Es ist schließlich keine Plattform bei der Softwareentwickler untereinander diskutieren, sondern überwiegend eben nur Open Source Fanboys die Software meist nur nutzen und nicht selbst entwickeln. Daher wird das auch nicht mit dem Linken und den Gefahren dabei verstanden.
OSS muss nicht gratis sein, Du kannst mit OSS gutes Geld verdienen ohne deine Kunden zu verarschen. Deiner Logk zufolge hat das Framework "gratis" zu sein...dein hochehrwuerdige Arbeit ist aber CS??? Schreage Logik...
Mit BSD hast Du aber absolut recht
> weil du für Software nichts bezahlen willst.
Immerhin konsequent weitergeführte Realitätsverbiegung. Ich schrieb nichts davon, daß ich für "Software nichts bezahlen" will. Was immer das auch heißen soll, "für Software". Das Recht, die Software zu verwenden? Eine harte/weiche Kopie der Software?
Die einzige Artt von Software, die ich als Exemplar des jeder Mensch kenne, bei der CS zwingend für das Geschäftsmodell ist, sind Trojaner.
Meine Fresse auf so viel Bullshit kann ich gar nicht als Ganzes eingehen... Warum verbreitest du wissentlich Lügen?
Die L-GPL ist absolut geeignet für CS Software. Abgesehen davon, dass statisches Linken keinerlei Vorteile bietet, erlaubt die L-GPL sehr wohl das statische Linken. Hast du die Lizenz überhaupt einmal gelesen?
Die L-GPL funktioniert wunderbar selbst für Anwendungen in medizinischen-, militärischen oder Automotive Anwendungen, aber für deine Pillepalle ist sie nicht geeignet. Ja, schon recht. Wenn man keine Ahnung hat...
Ist das ein Wettbewerb in Sachen Bullshit? Und dann ist "wissentlich" vielleicht eine wohlmeinende Überschätzung des Diskustanten
Statisches Linken hat einige Vorteile. Befrage die Informatiklehrerin Deines Vertrauens (meine war gut damals). Oder füttere die Suchmaschine Deines Vertrauens mit "statisch linken vorteil" (achte bei den Antworten/Suchergebnissen auf Begriffe wie Startzeit, Größe der ausführbaren Datei, Optimierungen von Codelogik.
Die LGPL fordert für das statische Linken die Bereitstellung von allem, was ein neues Erzeugen und Einbinden des Codes, der unter LGPL steht, verlangt. Also vom proprietären Code mindestens die Objektdateien, wenn nicht sogar den Quellcode im Falle von Kompilaten. Inklusive des Gestattens von Analyse des proprietären Materials, zum Debuggen der Einbindung. Was dem Diskutant vermutlich schon gegen seinen Mein-Code-Voll-Wichtig-Geheim-Strich geht.
Besser als Ahnung ist Wissen. Aber wer weiß schon, daß er nichts weiß.
Danke, ich weiß sehr gut was statisches Linken mit einem Binary anrichtet. Deshalb weiß ich auch, dass es keinerlei praktische Vorteile bringt. Und die theoretischen, die es hat sind ebenso mithilfe von Prelinking zB. erreichbar.
Und zum zweiten Teil gibst du dir ja sogar selbst die Antwort. Bei statisch gelinkten Binaries müsstest du die Object Files liefern + Linkerscript. Aber eben keinen Code. Und die explizite Erlaubnis zum Reverse Engineering ist auch kein Hindernis denn Reverse Engineering kann ohnehin nicht rechtswirksam untersagt werden. Im Gegenteil, diverse EU Richtlinien erlauben RE von Software sogar explizit.
Das mit der Praxis ist so ein Ding, die läßt sich nicht aus eigener Erfahrung verallgemeinern, sondern ist nur mit statistischen Mitteln erfaßbar. Nicht jeder verwendet die volle Breite einer API. Und so mancher Compiler kann Wunder bewirken, wenn er nicht an einer Symbolgrenze Halt machen muß, sondern da weiter den AST vor sich hin optimieren kann.
Aus meiner Praxis würde ich eher sagen, daß da so einige Vorteile lungern können. Kommt immer auf den Fall drauf an.
Was den zweiten Teil betrifft, da hatte ich keine Frage. Sondern nur ein wenig Ergänzung gegeben für die, die vielleicht die näheren Umstände wissen sollten, aber nicht motiviert genug sind, nachzulesen. EU-Recht gilt dann aber auch nur für die EU. Sobald man das Vergnügen hat, über die See zu liefern/erwerben, wird der Teil dann auch wieder interessant. Zum Glück nicht mein Ding.
Nur auf dem Papier, in der Praxis linkst du unbeabsichtigt ne Headerdatei dazu, weil du die unbedingt brauchst. Vor allem bei Qt ist die Gefahr groß und schon hast du die LGPL unwissentlich verletzt.
Statisches Linken bietet sehr wohl Vorteile, vor allem wenn es die einzige Software auf der Zielplattform ist, die Qt verwenden soll.
Statisches Linken erlaubt die LGPL bei CS Software nur, wenn du den Objektcode mitlieferst. Also Weltfremd. Die Praxis funktioniert anders.
Den oben verlinkten Artikel solltest du dir durchlesen.
All das ändert übrigens nichts daran, dass das Abomodell von Qt für CS Software Mist ist und in der Tat Sicherheitslücken begünstigt, weil die dann nie mehr gestopft werden, wenn das Projekt zu Ende entwickelt wurde und das Abo beendet wurde.
Bei Pauschallizenzen hat man solche Probleme nicht, das gleiche gilt für freie BSD oder zlib artige Lizenzen, da kann man dann das wesentliche in seine CS einbinden, selbst wenn die alte Lib nicht mehr weitergepflegt wird.
Für kleine Unternehmen kann letzteres der Todesstoß bedeuten.
Ich empfehle dir einfach mal mit Programmierern und Software Entwickler aus der Praxis, die Closed Source Software entwickeln, über die LGPL zu disktutieren.
Es hat seinen Grund, warum praktisch kein CS Projekt LGPL Libs verwendet.
Bei Qt kriegt man noch die proprietäre Lizenz im Abo, mit oben erwähnen Nachteile, aber allein die LGPL die rührt da auch niemand für ein CS Projekt an.
Letzten Endes hat es zwei Auswirkungen:
1. Die Softwareentwickler bleiben bei der Plattform bei der sie eine brauchbare GUI Lib haben, die ihnen rechtlich nicht im Weg steht.
und
2. Sollten die dann doch Qt wählen, dann gibt's nach 3-4 Jahren keine Patches mehr, wenn das Abo für die propritäre Lizenz beendet wurde.
Kleine Ergänzung, ich meinte
..., in der Praxis linkst du unbeabsichtigt durch die Header Datei Code hinzu, ....und schon hast du die LGPL unwissentlich verletzt.
Da muss man also höllisch aufpassen. Das kann man beim kommerziellen Coden niemandem empfehlen, vor allen da die Coder in der Regel alle keine Juristen sind.