Von Kruzituerken am Mi, 16. Oktober 2019 um 14:03 #
Ziff 6 I LGPLv2 sieht hier vor, dass dem Anwender eine Anpassung der verlinkenden Software an eigene Bedürfnisse sowie ein reverse engineering zur Beseitigung von Fehlern erlaubt werden müsse. Dies ist als Abweichung von den üblichen deutschen Regelungen im Softwareurheberrecht bemerkenswert.
Ferner muss auf das Vorhandensein der Bibliothek und Geltung der LGPL für die Bibliothek hingewiesen werden, ferner ist der Lizenztext der LGPL beizufügen.
Daneben muss eine der Bedingungen der Ziff. 6 II a.) – e.) LGPLv2 erfüllt werden. Der in der Praxis am meisten verbreitete Fall ist gem. Ziff. 6 II b.) LGPL v2 die Verwendung eines geeigneten ,, shared library mechanism“, wenn etwa die Bibliotheksdatei bereits auf dem Computer/Betriebssystem des Anwenders vorhanden ist.
Andernfalls müssen gem. Ziff. 6 II a.) LGPL v2 die Quellcodes der Programmbibliothek sowie der Objektcode oder der Quellcode des verlinkenden Programms in einer Weise beigefügt werden, die es dem Anwender erlaubt, die Bibliothek zu verändern und mit dem zugreifenden Werk neu zu verlinken, so dass ein neues executable erstellt werden kann. Alternativ kann gem. Ziff. 6 II c.) und d.) LGPL v2 auch ein 3 Jahre gültigen Angebots zur Lieferung der in a) aufgeführten Materialien abgegeben werden, auch durch Zurverfügungstellen über das Internet auf der gleichen Website.
Von Kruzituerken am Mi, 16. Oktober 2019 um 16:12 #
Korrektur, gerade gecheckt: Offensichtlich haben sich die Entwickler für embedded devices die LGPL doch durchgelesen. Kommerzielle embedded Projekte verwenden die glibc nämlich nicht.
Wie kann es dann sein dass es überhaupt kommerzielle Software gibt die unter Linux läuft? Ist nämlich alles gegen die glibc gelinkt
Diese Aussage ist falsch. Alpine Linux und OpenWrt unterstützen musl (MIT), während Void Linux mehrere C-Standard-Bibliotheken unterstützt (aktuell glibc and musl). Android verwendet Bionic (BSD) und RedHat pflegt Newlib (BSD 3-clause), welches u.a. von ARM Limited mitentwickelt wird.
Die Problematik der LGPL für glibc auf eingebetteten Systemen ist also durchaus bekannt.
Wer redet von embedded devices wenn er kommerzielle software sagt?
Der Artikel:
Wayland Compositor und Application Manager werden laut Qt Company hauptsächlich in komplexen eingebetteten Systemen mit mehreren Prozessen eingesetzt. In Desktop- oder Mobilanwendungen kommen sie nicht zum Einsatz, und in der Mehrzahl der einfachen eingebetteten Systeme ebenfalls nicht.
Wenn Sie sich allerdings nicht auf den Artikel beziehen, dann frage ich mich warum Sie den Artikel kommentieren?
Von Verfluchtnochmal_5987108 am Do, 17. Oktober 2019 um 00:47 #
Was genau hast du am deutschen Wort "hauptsächlich" nicht verstanden und was hat das mit der Lizenz, speziell der von gtk zu tun um welches im Artikel so gar nicht geht?
und was hat das mit der Lizenz, speziell der von gtk zu tun um welches im Artikel so gar nicht geht?
LGPL-Bibliotheken ermöglichen die Entwicklung geschlossener, kommerzieller Software auf Systemen, wo die erforderlichen LGPL-Bibliotheken entweder bereits vorhanden sind, oder per Paketmanager nachinstalliert werden können (also z.B. auf üblichen Linux-Distributionen). Bei statisch gelinkten Anwendungen oder Binärpaketen ist das aufgrund der Bedingungen Ziff. 6 II a.) LGPL v2 so gut wie unmöglich (Es sei denn, man stellt den Quell- oder Objekt-Code für Neukompilierungen durch den Kunden zur Verfügung und sorgt dafür das der Kunde das neue Binary auch installieren kann).
Die weiter oben stehende Aussage, (verkürzt): "GTK+ / LGPL / open source oder kommerziell-geschlossen / alles ist möglich", ist also falsch. Google hat das z.B. bei Android erkannt und verwendet deshalb keine LGPL-Bibliotheken, für die Hersteller von eingebetteten Systemen gilt das analog (man stelle sich nur vor, ein Autohersteller wäre aufgrund der Verwendung von LGPL-Bibliotheken dazu gezwungen dafür zu sorgen, dass der Kunde seinen Instrumenten-Cluster mit einer vom Kunden geänderten LGPL-Bibliothek neu kompilieren und installieren kann).
Fazit: LGPL-Bibliotheken sind in vielen Fällen also keineswegs eine Alternative zu einer kommerziellen Lizenz und deshalb ist GTK+ auch keine Alternative zu Qt (da es GTK+ weder unter einer kommerziellen Lizenz, noch unter der BSD- oder MIT-Lizenz gibt).
Ja richtig, der Kunde startet ganz einfach den Paketmanager auf dem Instrumenten-Cluster seines Autos und kann dann so alle von ihm geänderten LGPL-Bibliotheken installieren. Damit entspricht dann alles den Bestimmungen der LGPL. Warum ich daran nicht gedacht habe weiss ich selbst nicht. Gut das es einen Spezialisten wie dich gibt, der die Leute hier im Forum auf so etwas hinweist. Vielen Dank!
VW, Toyota, BMW, Sony, FIAT/Chrysler, Mazda, Mitsubishi, Fanuc, Daimler, Heidenhain, General Motors, Matsushita und Ford machen das so? Wo denn? Ich bitte eine Quellenangabe.
Nun, gtk steht ausschließlich unter einer freien Lizenz du Genie, zwischen lesen können und sinnerfassend lesen können liegen Welten
Wie soll dann die Entwicklung der freien Version eingestellt werden?
Was soll denn an der LGPL unfrei sein?
Wie kann es dann sein dass es überhaupt kommerzielle Software gibt die unter Linux läuft? Ist nämlich alles gegen die glibc gelinkt
Weil sich niemand die Bedingungen der LGPL wirklich durchgelesen hat vielleicht?
Korrektur, gerade gecheckt: Offensichtlich haben sich die Entwickler für embedded devices die LGPL doch durchgelesen. Kommerzielle embedded Projekte verwenden die glibc nämlich nicht.
Diese Aussage ist falsch. Alpine Linux und OpenWrt unterstützen musl (MIT), während Void Linux mehrere C-Standard-Bibliotheken unterstützt (aktuell glibc and musl). Android verwendet Bionic (BSD) und RedHat pflegt Newlib (BSD 3-clause), welches u.a. von ARM Limited mitentwickelt wird.
Die Problematik der LGPL für glibc auf eingebetteten Systemen ist also durchaus bekannt.
Wer redet von embedded devices wenn er kommerzielle software sagt?
Der Artikel:
Wenn Sie sich allerdings nicht auf den Artikel beziehen, dann frage ich mich warum Sie den Artikel kommentieren?
Was genau hast du am deutschen Wort "hauptsächlich" nicht verstanden und was hat das mit der Lizenz, speziell der von gtk zu tun um welches im Artikel so gar nicht geht?
LGPL-Bibliotheken ermöglichen die Entwicklung geschlossener, kommerzieller Software auf Systemen, wo die erforderlichen LGPL-Bibliotheken entweder bereits vorhanden sind, oder per Paketmanager nachinstalliert werden können (also z.B. auf üblichen Linux-Distributionen). Bei statisch gelinkten Anwendungen oder Binärpaketen ist das aufgrund der Bedingungen Ziff. 6 II a.) LGPL v2 so gut wie unmöglich (Es sei denn, man stellt den Quell- oder Objekt-Code für Neukompilierungen durch den Kunden zur Verfügung und sorgt dafür das der Kunde das neue Binary auch installieren kann).
Die weiter oben stehende Aussage, (verkürzt): "GTK+ / LGPL / open source oder kommerziell-geschlossen / alles ist möglich", ist also falsch. Google hat das z.B. bei Android erkannt und verwendet deshalb keine LGPL-Bibliotheken, für die Hersteller von eingebetteten Systemen gilt das analog (man stelle sich nur vor, ein Autohersteller wäre aufgrund der Verwendung von LGPL-Bibliotheken dazu gezwungen dafür zu sorgen, dass der Kunde seinen Instrumenten-Cluster mit einer vom Kunden geänderten LGPL-Bibliothek neu kompilieren und installieren kann).
Fazit: LGPL-Bibliotheken sind in vielen Fällen also keineswegs eine Alternative zu einer kommerziellen Lizenz und deshalb ist GTK+ auch keine Alternative zu Qt (da es GTK+ weder unter einer kommerziellen Lizenz, noch unter der BSD- oder MIT-Lizenz gibt).
Ich hoffe, damit ist Deine Frage beantwortet.
Und weiter? Niemand zwingt dich statisch zu Linken
Ja richtig, der Kunde startet ganz einfach den Paketmanager auf dem Instrumenten-Cluster seines Autos und kann dann so alle von ihm geänderten LGPL-Bibliotheken installieren. Damit entspricht dann alles den Bestimmungen der LGPL. Warum ich daran nicht gedacht habe weiss ich selbst nicht. Gut das es einen Spezialisten wie dich gibt, der die Leute hier im Forum auf so etwas hinweist. Vielen Dank!
Sag mal hast du getrunken oder warum kommst du permanent mit embedded angeschissen?
Die Bedingungen der LGPL gelten auch für Embedded Devices.
Du lieferst die scheiss library gegen die du dynamisch links mit, haben fertig, so macht das jeder kommerzielle Hersteller
VW, Toyota, BMW, Sony, FIAT/Chrysler, Mazda, Mitsubishi, Fanuc, Daimler, Heidenhain, General Motors, Matsushita und Ford machen das so? Wo denn?
Ich bitte eine Quellenangabe.
VMware und viele andere machen das so als Fallback wenn auf dem Zielsystem keine kompatible Version vorhanden ist