News Arch Linux 2021.03.01: Neuer Kernel 5.11 unterstützt AMD Navi 23 und Van Gogh

[foo_1337]

Ich vermute das es bei BSD öfter vorkommt, weil es 100% legal ist.

Ist das schlimm? Der Entwickler hat sich bewusst dazu entschieden. Wenn das ein Problem wäre, wäre mittlerweile nicht der Großteil der beliebten Software im OSS Umfeld BSD, MIT oder Apache2 (oder etwas eigenes was sich daran orientiert).

Das ist mir als Backendentwickler durchaus bewusst, allerdings sind die meisten FOSS Projekte Software Bibliotheken und/oder Frameworks hier bevorzuge ich auch MIT, Apache, BSD.

Siehst du

Ergänzung (2. März 2021)

Ich sehe den Erfolg von Linux teils doch auch durch die GPL. Auf der einen Seite macht es einem Entwickler (insbesondere in der HW-Ecke) das Leben schwer, weil er die Änderungen, die er machte, um Linux auf seiner HW laufen zu lassen, dokumentieren muss (bzw. müsste). Auch bei Software-Projekten ist es natürlich einfacher, einen Sourcecode zu nehmen, seinen Kram drumherum zu packen und so auszu

Die GPL zwingt dich zu überhaupt keiner Dokumentation. Schau dir doch mal den Source Code von Linux und auch dem GNU Zeugs aus den Anfängen an. Das war katastrophal. Auch heute noch häufig, siehe z.B. die glibc doku oder auch den Linux sourcetree. Und zu allem Überfluss wollte das GNU Projekt damals noch info(1) durchdrücken. Ist aber grandios damit gescheitert.
Und wie gesagt: Der Erfolg von GNU/Linux ist maßgeblich dem AT&T Lawsuit gegen die CSRG geschuldet. Leider.

Aber jetzt kommt eben das "auf der anderen Seite". Denn da wäre Linux heute nicht da, wo sie sind. BSD gab es lange. Und die *BSDs hatten lange die Möglichkeit, wirklich "groß" zu werden.

Lies dir bitte den im vorcomment verlinkten Wikipedia Artikel durch. Das war wirklich ein riesen Problem damals.

Die sehen die Vorteile, die eine "upstream"-Integration bringt. Aber viele tun das nicht. Ich hab z.B. nirgends gesehen, dass Sony ihre PS4-Anpassungen an BSD publik gemacht hätten.

Sony hat sehr viel an BSD contributed. Siehe z.B. KAME oder ALTQ. Und das war weit vor der PS4 Bei Olive gab es kaum Änderungen, die für die Allgemeinheit wichtig wären.

Erinnert sich noch jemand an die Diskussion, dass CSS-Grafiktreiber besser sind als gar keine und in wie weit CSS-Treiber im Kernel erlaubt werden sollten? Es hat 10 Jahre gedauert, bis AMD verstanden hat, dass es ein Vorteil sein kann, nicht (nur) CSS - fglrx anyone?

Ja, fglrx war wirklich übel.

In der reinen Software-Welt wird der Vorteil von GPL sogar noch größer. Wo wäre MariaDB ohne die GPL? Oder eines der anderen großen Tools?

Apache, nginx, redis, elasticsearch, kubernetes, docker, postgresql, node.js, PHP... Soll ich weiter machen?
Gegenfrage: Welche großen und wichtigen Tools gibt es denn noch so außer MySQL (was übrigens nur aufgrund der damaligen Unfähigkeit der PHP "Entwickler" so groß wurde)? Python? Perl? Go? InfluxDB? Unbound? XFree86? X.org? Wayland? Fehlanzeige. Das einzige was mir so aus dem Stehgreif noch einfällt wäre PowerDNS und Exim, wobei letzterer mittlerweile auch kaum noch eine Rolle spielt.

Die GPL spielt im heutigen Internetz Hipster Ökosystem, bis auf GNU/Linux, keine wirkliche Rolle mehr. Und sie hat es noch nie.

Verloren haben nur die, die das Prinzip dieser OFFENEN Software ausnutzen wollten, ohne etwas zurückzugeben. Die durften sie nicht nutzen.

Nein, die GPL ist innovationsverhindernd. Deshalb wird die GPL auch so selten genutzt (siehe voriger Absatz). Und wenn, dann oft in einer Variante, dass man via Münzeinwurd eine befriete Variante bekommt.

Ergänzung (2. März 2021)

Lustigerweise kommen sehr viele Beiträge für FreeBSD von Firmen. Auch das kommende 13er Release ist wieder bis unters Dach vollgestopft mit Third-Party-Contributions.

Genau so ist es. Und das war schon immer der Fall. Der prominenteste damals war Yahoo.
Und selbst Apple hat gut dazu beigetragen, denn sonst wäre FreeBSD heute nicht GPL frei (s/gcc/llvm/).

 

[andy_m4]

aber wenn ein Unternehmen sein eigenes Dateisystem aufbauen möchte und kostenpflichtig anbieten möchte dann kann es das jederzeit tun, ohne irgendetwas zurückzugeben.

Da fällt mir spontan iX-Systems ein mit ihrem TrueNAS. :-)

Ich vermute das es bei BSD öfter vorkommt, weil es 100% legal ist.

Schwer zu sagen.

Das habe ich auch nicht angezweifelt. Bei Linux ist es nebenbei auch so, das meiste kommt von Unternehmen (Logisch schließlich wollen diese das ihre Hardware funktioniert)

Gerade das spricht ja eher dagegen das sowas wie der Kernel GPL sein muss. Weil halt Hardwarehersteller ein natürliches Interesse daran haben das ihre Hardware funktioniert. Die verkaufen nämlich Hardware und nicht den Treiber.

Mir geht es darum das Bestimmt Projekte wie z.B. Betriebssysteme bzw. die grundlegenden Elemente (Kernel, initsystem, filesystem ..) meiner Meinung nach mit der GPL zu einer besseren Akzeptanz und Kollaboration gelangen.

Filesystem. Soso. :-)
Dabei ist doch gerade OpenZFS ein Paradebeispiel wie gut das ohne GPL funktionieren kann.
Andererseits ist Systemd GPL aber auch gleichzeitig ziemlich umstritten. :-)

 

[foo_1337]

Was schon witzig ist, jede Playstation 4 und neuer hat ein FreeBSD Derivat und AMD Grafik und das scheint ganz gut zu funktionieren. Schade nur, dass nichts zurück in Richtung Upstream wandert.

Naja, der AMD Code ist ja nicht von Sony geschrieben.

Genauso Apple, über Jahre bei BSD inspirieren lassen und AMD GPUs verbaut und nur wenig in diesem Bereich zurück gegeben.

Auch hier: Der Treiber kommt von AMD. Zumal die kexts in dem Fall für XNU (Mach) sind. Davon hätte FreeBSD nichts. Der FreeBSD Teil in macOS beschränkt sich auf das Networking, Multiuser (Kernel) und das Userland

 

[andy_m4]

Und heute? Ist der OSS-Code mitunter meist schneller als die CSS-Referenzimplementierung. Gutes Beispiel ist der CSS-Code zu Vulkan. Die Referenz-Implementierung mag zwar ein paar Spezialfälle mehr abdecken als der OSS-Code, aber stabiler/schneller läuft letzterer. - Nachweislich. Und warum? Weil eben nicht nur die Nasen von AMD draufgeguckt haben sondern auch ein paar Code-Junkies rund um die Welt, die sich auf Speed-Hacks verstehen.

Und welcher Vorteil wird hier durch die GPL ermöglicht?

Wenn ich Treiber offen lege (und damit optimiert, portiert whatever wird) verkauft sich meine Hardware besser. Wenn dann irgendwelche "Trottel" für mich dann noch Optimierungen vornehmen ohne dasich selbst dafür Ressourcen verschwenden muss, umso besser.
Das demonstriert also sehr schön den Vorteil von Open-Source aber nicht den Vorteil der GPL.

Warum die (Grafikkarten)-Hersteller dann trotzdem ungern den Quelltext zu den Treibern veröffentlichen liegt eher darin begründet, das Treiber-Internas auch halt bestimmte Tricks an die Konkurrenz verraten.
Interessant ist daher auch der Trend, das man bestimmte Dinge gar nicht mehr in den Treiber packt sondern in die Firmware. Ja. Du hast zwar einerseits nen offenen AMD-Treiber. Gleichzeitig hast Du da auch nen großen Firmware-BLOB (aka Closed-Source!) beiliegen.

Ja. Das ist immer noch besser als die Situation früher. Aber das hier als großen Siegeszug der GPL zu verkaufen der den Code befreit hat, ist dann vielleicht doch ein bisschen übertrieben. :-)

Wo wäre MariaDB ohne die GPL?

Keine Ahnung. Ich weiß nur, das ich MariaDB und MySQL möglichst versuche zu meiden und stattdessen auf PostgreSQL setze. Die ist nämlich in allen Belangen überlegen (gut; hast Du halt nicht auf nen Feld-, Wald- und Wiesenhoster; aber wen interessiert das?).
Und PostgreSQL ist nicht GPL, sondern so eher BSD-like. :-)

 

[JustAnotherTux]

Die Hersteller müssen, wenn sie einen Treiber für z.B. FreeBSD bereitstellen, eben nicht die GPL wählen. Sie sind sehr frei in der Lizenzwahl.

Der Hersteller hat zumindest zum Veröffentlichungszeitpunkt die Urheberrechte also kann die Software unter mehreren Lizenzen veröffentlicht werden, daher könnte ein Treiber sowohl mit GPLv3 als auch BSD lizenziert werden z.B. einmal für Linux und einmal für BSD.

Sie müssen auch nicht einen GPL hook bereitstellen, wie nvidia es macht.

Der Nivida Treiber ist aber nicht Teil des Kernels, vermutlich ist das ein Workaround von Nvidia um ihr geschlossenes Kernel Treiber Modul lauffähig zu machen.

So ist es z.B. nicht möglich, ZFS oder Dtrace im Linux Kernel zu haben, da diverse GPL fetischisten die CDDL nicht als GPL kompatibel ansehen.

Ich glaube da geht es eher um die Angst vor Oracle, Falls die Anwälte von Oracle beweisen könnten das CDDL und GPLv2 nicht kompatibel sind könnte es ggf. Strafzahlungen geben.
Jedenfalls wird ZFS inzwischen unabhängig von Oracle weiterentwickelt, das Ganze wäre aber kein Problem, wenn Oracle einfach den ZFS code GPLv2 lizenziert hätte (das könnten sie noch immer). Das ganze macht noch weniger Sinn, wenn man bedenkt, das das Linux equivalent für ZFS, BTRFS von Oracle entwickelt wird.

Treiber von Herstellern will eigentlich in der OSS OS Welt keiner. Wir wollen offene Dokumentation.

Das befürworte ich ebenfalls.

Weil? Linux ist durch den Hype groß geworden, nicht durch die Lizenz. Nimm mal andere FOSS Projekte, die seit Jahren angesagt sind. Fast keines davon nutzt die GPL.
Und wie gesagt: Wenn die Stallman fraktion ihre eigene Ideologie ernst gemeint hätte, gäbe es die LGPL nicht und die glibc wäre GPL. Viel Spaß beim Linken.

Klar gibt es andere große FOSS Projekte aber ich beziehe mich hauptsächlich auf die unteren Ebenen eines OS, hier macht meiner Meinung GPL mehr Sinn, damit garantiert ist das der code offen bleibt.

Ja, der Linux Kernel profitiert auch unglaublich von den ganzen China Routerherstellern oder auch AVM.
Kommerziellen Support sowie Code gibt es bei FreeBSD schon sehr lange. Und das ganz ohne GPL. Selbst von Intel

Bei BSD, MIT, Apache gibt es sicherlich auch viele welche die Regeln nicht beachten z.B. gar kein attribution geben. Kommerziellen Support gibt es bei RHEL, SUSE und Ubuntu Server doch auch, keine Ahnung was das mit GPL zu tun hat bzw. was du mir sagen willst.

Weil sie Freiheiten nimmt. Und der Zwang zurückzucontributen bzw den Code zu veröffentlichen bringt in der Realität fast nichts. Die wesentlichen Achievements hier waren custom Firmwares wie z.B. DD-WRT, die es tatsächlich nur aufgrund der GPL gibt. Mit Contributen hat das aber nichts zu tun.

Ja das stimmt, GPL nimmt die dir Freiheit, die Freiheit der anderen wegzunehmen, ob man das gut findet, ist allen selbst überlassen.
In der Linux Welt wird sehr viel wieder zu Upstream zurückgegeben, das es nichts bringt glaube ich nicht aber ich vermute einmal das es dazu auch keine aussagekräftige Untersuchungen gibt.

Ist das schlimm? Der Entwickler hat sich bewusst dazu entschieden. Wenn das ein Problem wäre, wäre mittlerweile nicht der Großteil der beliebten Software im OSS Umfeld BSD, MIT oder Apache2 (oder etwas eigenes was sich daran orientiert).

Es behindert die Weiterentwicklung, wenn weniger zurückgegeben wird IMO.
Wir verwenden z.B. fast immer die MIT Lizenz aber eben für libs, natürlich darf jeder Entwickler entscheiden unter welchen Lizenzen der Code veröffentlicht werden soll, dagegen habe ich auch nichts einzuwenden.
Wie bereits gesagt, ich beziehe mich nicht auf die ganzen libs und frameworks hier bevorzuge ich ebenfalls MIT, Apache.

Ergänzung (2. März 2021)

Gerade das spricht ja eher dagegen das sowas wie der Kernel GPL sein muss. Weil halt Hardwarehersteller ein natürliches Interesse daran haben das ihre Hardware funktioniert. Die verkaufen nämlich Hardware und nicht den Treiber.

Müssen natürlich nicht. Die anderen zwei Sätze verstehe ich nicht, sowohl bei Linux als auch FreeBSD funktioniert die Software gut das hat nichts mit der Lizenz zu tun.

Filesystem. Soso. :-)
Dabei ist doch gerade OpenZFS ein Paradebeispiel wie gut das ohne GPL funktionieren kann.
Andererseits ist Systemd GPL aber auch gleichzeitig ziemlich umstritten. :-)

Das war offensichtlich ein Beispiel. Natürlich geht es auch ohne GPL, das bezweifle ich auch nicht.
Systemd hat viel Kritik bekommen funktioniert aber einwandfrei, ich weiß nicht, was das mit der GPL zu tun hat.

 

[RalphS]

diverse GPL fetischisten die CDDL nicht als GPL kompatibel ansehen.

du hast die cddl aber gelesen, oder?
https://opensource.org/licenses/CDDL-1.0

3.1
Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License.

Abgesehen von allem anderen ist dies bereits Totschlagargument.

Nicht daß ich dir nicht ansonsten beipflichten würde. Lizenztechnisch steht sich Gpl selbst im Weg.

 

[foo_1337]

Der Hersteller hat zumindest zum Veröffentlichungszeitpunkt die Urheberrechte also kann die Software unter mehreren Lizenzen veröffentlicht werden, daher könnte ein Treiber sowohl mit GPLv3 als auch BSD lizenziert werden z.B. einmal für Linux und einmal für BSD.

GPLv3 ist sowieso ein riesen mist Aber ja, Dual Licensing ist nicht selten. Das Problem ist nur, dass sich der Hersteller, wenn er sich für die GPLv3 entscheidet, sich einen ziemlichen Klotz ans Bein bindet.

Der Nivida Treiber ist aber nicht Teil des Kernels, vermutlich ist das ein Workaround von Nvidia um ihr geschlossenes Kernel Treiber Modul lauffähig zu machen.

Korrekt. Macht aber nicht nur nvidia so. Das Problem ist ein re-linking.

Ich glaube da geht es eher um die Angst vor Oracle, Falls die Anwälte von Oracle beweisen könnten das CDDL und GPLv2 nicht kompatibel sind könnte es ggf. Strafzahlungen geben.
Jedenfalls wird ZFS inzwischen unabhängig von Oracle weiterentwickelt, das Ganze wäre aber kein Problem, wenn Oracle einfach den ZFS code GPLv2 lizenziert hätte (das könnten sie noch immer). Das ganze macht noch weniger Sinn, wenn man bedenkt, das das Linux equivalent für ZFS, BTRFS von Oracle entwickelt wird.

Oracle ist hier erstmal auszuklammern. Die CDDL kommt von Sun. Wenn Sun sich für die GPLv2 entschieden hätte, wäre ZFS weder unter Solaris, noch unter FreeBSD (oder macOS) möglich gewesen. Das Problem hier ist ganz alleine Linux mit GPLv2. Und ich gebe Schily hier recht mit seiner Aussage, dass es kein Problem wäre, CDDL Code mit dem Linux Kernel zu verheiraten.

Klar gibt es andere große FOSS Projekte aber ich beziehe mich hauptsächlich auf die unteren Ebenen eines OS, hier macht meiner Meinung GPL mehr Sinn, damit garantiert ist das der code offen bleibt.

Warum? Bei (Free|Net|Open)BSD wird der Code auch immer offen bleiben. Das ist er seit den 70ern.

Bei BSD, MIT, Apache gibt es sicherlich auch viele welche die Regeln nicht beachten z.B. gar kein attribution geben.

Du musst lediglich (je nach Lizenz) den Author nennen, that's it. Wird auch in der Regel so eingehalten.

Kommerziellen Support gibt es bei RHEL, SUSE und Ubuntu Server doch auch, keine Ahnung was das mit GPL zu tun hat bzw. was du mir sagen willst.

Mit Support hat das alles gar nichts zu tun. Da ist die Lizenz völlig wurscht.

Ja das stimmt, GPL nimmt die dir Freiheit, die Freiheit der anderen wegzunehmen, ob man das gut findet, ist allen selbst überlassen.
In der Linux Welt wird sehr viel wieder zu Upstream zurückgegeben, das es nichts bringt glaube ich nicht aber ich vermute einmal das es dazu auch keine aussagekräftige Untersuchungen gibt.

Ich habe kA, ob du jemals selbst Code geschrieben und veröffentlich hast. Aber jemanden dazu zu zwingen ist IMHO immer der falsche Weg. Mein AG ist ein Unternehmen (wer hätte es gedacht ) und wir haben uns bewusst dazu entschieden, unseren Code niemals unter die GPL zu stellen. Und das obwohl Mitbewerber den Code nutzen könnten und erweitern ohne backcontributions? Warum? Weil es bullshit ist. Wenn jemand unseren Code nutzt, hat er interesse, seine contributions upstream zu reporten. Warum? Weil er sonst bei jedem Patch seitens Upstream ein Problem hätte.

Es behindert die Weiterentwicklung, wenn weniger zurückgegeben wird IMO.

Nein, tut es nicht. Bitte nenne relevante Projekte neben Linux oder von mir aus MySQL, die GPLed sind. Ich hab oben genug Gegenbeispiele genannt, die nicht GPLed sind.

Wir verwenden z.B. fast immer die MIT Lizenz aber eben für libs

Sehr gut. Wenn ihr ein Unternehmen seid, empfehle ich euch aber wegen des Patentmists, zu überlegen, richtung Apache2 zu gehen

Ergänzung (2. März 2021)

du hast die cddl aber gelesen, oder?
https://opensource.org/licenses/CDDL-1.0

Jop, ich hatte damals mit Schily relativ lange Diskussionen darüber, weil ich das ursprünglich auch so gesehen hatte. Er hatte damals, weil er seine eigene Software (cdrecord, star etc.) auch unter die CDDL stellte, wohl anwältlich prüfen lassen. Ich kann mich aber leider nicht mehr an die Details erinnern.

Lizenztechnisch steht sich Gpl selbst im Weg.

Genau so ist es.

 

[JDK]

Gegenfrage: Welche großen und wichtigen Tools gibt es denn noch so außer MySQL (was übrigens nur aufgrund der damaligen Unfähigkeit der PHP "Entwickler" so groß wurde)?

Sind Ansible, gcc, Git, Emacs und Wordpress nicht groß genug für deine Auflistung oder ist das die Software/FOSS-Lizenz Rant-Versionen von AMD vs NVIDIA, PS vs XBOX und iOS vs Android?

Anyway, Arch Linux Build mit neuem Kernel.

 

[foo_1337]

Sind Ansible, gcc, Git, Emacs und Wordpress nicht groß genug für deine Auflistung

gcc ja, aber mittlerweile nicht mehr. Der Wechsel von gpl v2 auf gpl v3 bei gcc war ein riesiges Problem. Und DER Grund, llvm/clang so schnell zu entwickeln. Und übrigens bleibt aus genau diesem Grund auch Linus bei Linux und git bei der GPLv2.
Der Rest ist, was die Wichtigkeit betrifft, nicht mit der von mir genannten Software zu vergleichen, auch wenn git und ansible natürlich fester Bestandteil meiner täglichen Toolchain sind. Aber darum ging es bei meiner Argumentation nicht. Der Claim war, dass nur die GPL dafür sorgen kann, dass die Fixes nach Upstream wandern "Wo wäre MariaDB ohne die GPL? Oder eines der anderen großen Tools?" Und das ist schlicht falsch, denn dafür gibt es mehr als genug Beispiele, die dann auch von mir genannt wurden.

 

[karuso]

Der Wechsel von gpl v2 auf gpl v3 bei gcc war ein riesiges Problem.

Die GPLv3 ist ja auch ein schlechter Witz. "Don't use it for evil" - so ein Schmarrn hat in einer Lizenz nichts zu suchen.
Generell ist mir die MIT Lizenz lieber als die GPL - aber ich bezweifle dass Linux mit einer anderen Lizenz als der GPL so erfolgreiche geworden wäre.
Menschen sind nun mal im generellen sehr egoistisch und teilen nicht gerne, Firmen sind da noch viel schlimmer. Altruismus ist da eher selten. Genau deswegen ist die GPL ein notwendiges Übel. Es zwingt die Firmen dazu ihre Arbeit mit den anderen zu teilen genauso wie die Anderen es vorher gemacht haben - jeder der nimmt muss auch geben. Microsoft, Apple und Google zeigen dass mit der MIT oder BSD Lizenz sich nur an dem kostenlosen Code bedient wird ohne jemals etwas zurück zu geben. Getreu dem Motto "nimm was du kriegen kannst und gib nichts wieder her".
Das ganze zeigt sich auch in unserer restlichen Gesellschaft. Wir brauchen Gesetze die Regeln dass man nicht töten oder stehlen darf. Würden wir uns alle so verhalten wie es richtig wäre bräuchten wir das alles nicht.
Generell zeigt sich aber derzeit ein Wandel bei den Firmen die immer mehr einsehen dass Open Source kein Problem sondern eine Erleichterung ist. Insofern wird die GPL hoffentlich immer unwichtiger werden. Würde mir auch wünschen dass zB Redox OS mehr Unterstützung erfahren würde - das wäre mir vom Konzept, Aufbau und Lizenz lieber. Aber das ist alles Wunschdenken..

 

[JustAnotherTux]

@foo_1337

[...]Der Claim war, dass nur die GPL dafür sorgen kann, dass die Fixes nach Upstream wandern[...]

Nein das war nicht meine Behauptung, ich vermute lediglich, dass es durch die GPL zu mehr Upstreaming kommt mehr nicht.

Oracle ist hier erstmal auszuklammern. Die CDDL kommt von Sun. Wenn Sun sich für die GPLv2 entschieden hätte, wäre ZFS weder unter Solaris, noch unter FreeBSD (oder macOS) möglich gewesen. Das Problem hier ist ganz alleine Linux mit GPLv2. Und ich gebe Schily hier recht mit seiner Aussage, dass es kein Problem wäre, CDDL Code mit dem Linux Kernel zu verheiraten.

Oracle ist allerdings der aktuelle Eigentümer und könnte den ZFS code dual Lizenzieren, was zu diesem Zeitpunkt doch das Beste für beide Welten wäre, dann könnte auch OpenZFS zwei Lizenzen verwenden
und niemand hätte bedenken ZFS direkt in den linux kernel zu integrieren. Ich habe auch kein Problem CDDL code mit GPL code zu kombinieren aber anscheinend fast alle (bis auf Ubuntu) Linux Distros also ist es ein Problem, wobei das in Zukunft wohl einfach dazu führen wird, das ZFS in der BSD Welt bleibt und BTRFS in der Linux Welt ZFS verdrängt.

Warum? Bei (Free|Net|Open)BSD wird der Code auch immer offen bleiben. Das ist er seit den 70ern.

Ich meine darauf aufbauende/abgeleitete Projekte.

Du musst lediglich (je nach Lizenz) den Author nennen, that's it. Wird auch in der Regel so eingehalten.

Ja das ist mir bekannt , ich meine nur auch hier kann man einfach die Lizenz mischten aber ich verstehe deine Argumentation, GPL konform zu sein ist deutlich aufwendiger und wird vermutlich auch deshalb öfter missachtet.

Mit Support hat das alles gar nichts zu tun. Da ist die Lizenz völlig wurscht.

Ich habe lediglich auf deine Aussage geantwortet, dass es bei BSD kommerziellen Support gibt, welchen es aber auch bei Linux gibt also verstehe ich nicht, was du mit dem Satz gemeint hast.

Ich habe kA, ob du jemals selbst Code geschrieben und veröffentlich hast. Aber jemanden dazu zu zwingen ist IMHO immer der falsche Weg. Mein AG ist ein Unternehmen (wer hätte es gedacht ) und wir haben uns bewusst dazu entschieden, unseren Code niemals unter die GPL zu stellen. Und das obwohl Mitbewerber den Code nutzen könnten und erweitern ohne backcontributions? Warum? Weil es bullshit ist. Wenn jemand unseren Code nutzt, hat er interesse, seine contributions upstream zu reporten. Warum? Weil er sonst bei jedem Patch seitens Upstream ein Problem hätte.

Bei libs und frameworks stimme ich dir zu, bei Systemrelevanter Software sehe ich es anders aber das ist eben meine Meinung . Ich sehe es nicht als Zwang, wenn sich jemand für GPL entscheidet, war das eine freie Entscheidung und niemand ist gezwungen diesen code zu verwenden. Wenn jemand den code verwenden will, dann muss dieser sich an die Lizenz halten das hat meiner Meinung nach nichts mit Zwang zu tun. Ansonsten ist jede Proprietäre Lizenz eine Zwangslizenz.

Nein, tut es nicht. Bitte nenne relevante Projekte neben Linux oder von mir aus MySQL, die GPLed sind. Ich hab oben genug Gegenbeispiele genannt, die nicht GPLed sind.

IMO habe ich geschrieben, bzw. das ist meine Meinung.
Es gibt soweit ich weiß weder für meine noch für deine Meinung wissenschaftlich aussagekräftigen Belege.
Git, HAproxy, Python(2/3), GTK, gzip, gnu tar, glibc, gcc, systemd, gnome, KDE plasma, btrfs, ext4, XFS, Ansible, MariaDB, bash, fish, emacs, mediawiki ....

 

[andy_m4]

Jedenfalls wird ZFS inzwischen unabhängig von Oracle weiterentwickelt

Ja siehste. Ein weiteres Beispiel das man nicht unbedingt ne GPL braucht damit sich Open-Source gut entwickelt.
Du bringst die Beispiele selber aber hältst trotzdem an Deinem Standpunkt fest. :-)

wenn man bedenkt, das das Linux equivalent für ZFS, BTRFS von Oracle entwickelt wird.

Ja. Und Btrfs ist heute da, wo ZFS schon vor 10 Jahren war.
Und das trotz GPL. Komisch, oder? :-)

Klar gibt es andere große FOSS Projekte aber ich beziehe mich hauptsächlich auf die unteren Ebenen eines OS, hier macht meiner Meinung GPL mehr Sinn, damit garantiert ist das der code offen bleibt.

Das tut es aber auch bei Non-GPL-Open-Source-Lizenzen. Ganz einfach weil wenn der Author auf die Idee kommt daraus Closed-Source zu machen Du den Kram einfach forken kannst.

Klar könnte man argumentieren das wenn Du ein copylefted-Projekt hast und Beiträge von außen annimmst, das es dann schwerer wird den Source-Code zu schließen da ja die Beiträge alle weiterhin einer Copyleft-Lizenz unterliegen und man sie dann erst entfernen müsste.

Andererseits ist halt die Frage, wie oft das in der Praxis bisher überhaupt ein Problem war. BSD gibts schon länger als Linux und das trotz Non-Copyleft-Lizenz.
Und irgendwelche anderen Systeme die davon betroffen waren? Hast Du da ein Beispiel parat? Oder führen wir hier ein Phantomdiskussion um ein theoretisches Problem was bisher in der Praxis nie relevant war? :-)

Es behindert die Weiterentwicklung, wenn weniger zurückgegeben wird IMO.

Wobei Rückgegebenes auch Dir nur dann hilft, wenn es in die Projektausrichtung passt. Irgendwelcher Kram der vielleicht nur für ein Bruchteil der Leute relevant ist willst Du eigentlich nicht im Mainline haben. Weils den Code aufbläht und Du dann das Komplexitätsproblem erhöhst (mit Bugs und Sicherheitslücken die Du Dir an einfängst) ohne das ein Großteil der Anwender davon überhaupt was hat.
Und wo wir schon bei Bugs sind: Auch die Codequalität sollte stimmen. Sonst willst Du das auch eher nicht in Dein Projekt haben.

Hast Du übrigens auch ganz oft beim Linux-Kernel. Wie oft werden da Patches abgelehnt weil die gewissen Anforderungen nicht entsprechen.

Anyway. Die GPL hilft Dir hier nur begrenzt. Jemand der partout sein Code nicht freigeben will der wird es auch nicht bei einem GPL-Projekt. Der wird dann halt entweder nicht auf ein GPL-Projekt aufbauen oder er wird die GPL-Lizenz kreativ umgehen.

Schönes Beispiel ist hier der Software-as-a-Service-Krempel. Dadurch, das der Code nur auf Deinen Server läuft und Du gar nicht Deine Software direkt lizenziert kannst Du GPL-Code fröhlich mit Deinem proprietären Code mischen. Und das völlig legal.

In der Linux Welt wird sehr viel wieder zu Upstream zurückgegeben, das es nichts bringt glaube ich nicht aber ich vermute einmal das es dazu auch keine aussagekräftige Untersuchungen gibt.

Ja. Mir ist da auch nix bekannt.
Ich sehe GPL-Projekte die wunderbar gedeihen aber auch Non-GPL-Projekte die wunderbar gedeihen. Deswegen tue ich mich etwas schwer damit, wenn Du da versuchst anhand der Lizenz da irgendwas herzukonstruieren.
Klar kann man sich diese Gedanken mal machen. Aber wenn eine solche Theorie sich partout nicht mit der beobachteten Praxis in Übereinstimmung bringen lässt, könnte es möglicherweise daran liegen das die Theorie nicht stimmt oder zumindest der Einfluss der Lizenz kleiner ist, als man glaubt.

Müssen natürlich nicht. Die anderen zwei Sätze verstehe ich nicht, sowohl bei Linux als auch FreeBSD funktioniert die Software gut das hat nichts mit der Lizenz zu tun.

Du beginnst zu verstehen. :-)

Das war offensichtlich ein Beispiel. Natürlich geht es auch ohne GPL, das bezweifle ich auch nicht.

Worüber streiten wir dann? :-)

 

[JustAnotherTux]

Ja siehste. Ein weiteres Beispiel das man nicht unbedingt ne GPL braucht damit sich Open-Source gut entwickelt.
Du bringst die Beispiele selber aber hältst trotzdem an Deinem Standpunkt fest. :-)

Nein ich habe nie behauptet, dass es ohne GPL nicht möglich ist. Ich behaupte lediglich, dass es mit GPL bei bestimmten Projekten zu mehr Upstreaming kommt.

Ja. Und Btrfs ist heute da, wo ZFS schon vor 10 Jahren war.
Und das trotz GPL. Komisch, oder? :-)

ZFS ist deutlich älter, BTRFS ist von scratch entwickelt, zudem kann man beide nicht 1:1 vergleichen da teilweise andere Features verwendet werden.
Jedenfalls hat das nichts mit der GPL zu tun.

Oder führen wir hier ein Phantomdiskussion um ein theoretisches Problem was bisher in der Praxis nie relevant war? :-)

Ja im Prinzip schon, wir haben beide keine handfesten Belege für unsere Standpunkte.

 

[Piktogramm]

Vollzitat entfernt - so gehts richtig

Das Interesse bei BSD und vergleichbaren Lizenzen Code in Richtung Upstream zu geben ist nur solang da, wie es (wirtschaftlich) sinnvoll ist den Aufwand für Maintaince (an euch) zu externalisieren. Sowas kann funktionieren, kann aber auch nach hinten losgehen, wenn irgendwer aggressive Marktverdrängung fahren will (und kann). Ein Beispiel wie sowas schiefgehen kann gab es ja gerade mit Elasticsearch und Amazon.
Ansonsten hoffe ich, dass nicht jeder Patch in Upstream eure APIs derart kaputt macht, dass es Probleme gibt..
Und dieses "Meine Lieblinslizenz ist viel besser, weil es viel mehr (von mir als relevant angesehene) Softwareprojekte mit ihr gibt", das geht etwas Richtung Kindergarten wie: "VWs sind viel besser als BMWs, denn davon gibt es viel mehr und deswegen sind Trabis auch tausendfach besser als der Ferrari 599."

Und wenn wir schon bei Meinungen sind: Das schlimmste an der BSD-Lizenz sind dessen Fans, die fanatisch ihre libertären Ansichten diskutieren wollen. Dagegen wirkt selbst R. Stallman auf seine alten Tage recht differenziert..

 

[andy_m4]

Menschen sind nun mal im generellen sehr egoistisch und teilen nicht gerne, Firmen sind da noch viel schlimmer. Altruismus ist da eher selten.

Hättest Du den Thread gelesen, dann wüsstest Du das es dazu keine GPL braucht.
Firmen geben Code an Open-Source-Projekte vor allem deshalb zurück, damit die selbst nicht die Arbeit haben alles selbst nachzupflegen wenn vom Upstream-Projekt ne neue Version rauskommt.
Mit anderen Worten: Diese miese egoistische Denke sorgt für Contributions. :-)

wobei das in Zukunft wohl einfach dazu führen wird, das ZFS in der BSD Welt bleibt und BTRFS in der Linux Welt ZFS verdrängt.

Sag das mal den ZFSonLinux-Leuten die relativ führend bei der ZFS-Entwicklung sind. Sogar FreeBSD baut ab der kommenden Version ganz auf den ZFSonLinux-Code.
ZFS auf Linux ist also lebendig wie nie zu vor.

Ob Btrfs sich jemals auf breiter Basis durchsetzen wird, bleibt fraglich. Da kommen kaum noch wirkliche Impulse her. Gleichzeitig funktionieren viele Dinge auch noch nicht. Nicht vergessen. Btrfs wird seit über 10 Jahren als der große Nachfolger gehandelt. Als neues Standarddateisystem.
Btrfs scheint inzwischen viel zu verbastelt zu sein. Sozusagen das Xorg unter den Dateisystemen. :-)

Da sehe ich die Zukunft eher in bcachefs. Die Entwicklung dort ist sehr viel dynamischer. Was schon allein daher kommt, das die halt aus dem was es schon gab lernen konnten und dazu ne sauberere Code-Basis haben.

 

[RalphS]

Ich finde das ja alles wahnsinnig faszinierend, aber können wir uns vielleicht darauf einigen, daß das mit dem “gpl und bsdl sind inkompatibel” schon so begründet ist - bis runter zu den Anwendungsfällen — weil sie einfach grundsätzlich verschieden voneinander sind?

Freiheit des Codes einerseits und Freiheit des Programmierers andererseits mag ähnlich klingen, ist es aber nicht. Beides hat seine Daseinsberechtigung. Auch wenn beide nicht immer optimal eingesetzt werden.

Gpl ist nun mal viral. Und Bsdl erlaubt es nun mal, Geld damit zu verdienen.

Lebt damit.

 

[foo_1337]

Sowas kann funktionieren, kann aber auch nach hinten losgehen, wenn irgendwer aggressive Marktverdrängung fahren will (und kann). Ein Beispiel wie sowas schiefgehen kann gab es ja gerade mit Elasticsearch und Amazon.

Das ist ein sehr schlechtes Beispiel, denn die GPL hätte daran nichts geändert. AWS bietet schon lange GPLed Software wie z.B. MySQL mit RDS/Aurora an und nichts kann sie davon abhalten. Die GPL zwingt dich dazu, den Code bereitszustellen. Sie hält dich aber nicht davon ab, mit der Software Geld zu verdienen, insbesondere im SaaS Bereich. Und genau mit letzterem hat Elastic nun ein Problem, weil sie gerne mit ihrem eigenen SaaS Service Geld verdienen würden.

Ansonsten hoffe ich, dass nicht jeder Patch in Upstream eure APIs derart kaputt macht, dass es Probleme gibt..

Was meinst du denn mit "eure API"? Ist die Bekannt, wie das Entwicklungsmodell von z.B. FreeBSD funktioniert? Solche breaking Changes, wie sie bei Linux an der Tagesordnung sind, gibt es bei FreeBSD in der Form nicht, solange man im gleichen RELENG Zweig bleibt. Ein Treiber für FreeBSD 4.0 funktionierte binärkompatibel mit 4.10. Das wäre bei Linux nie möglich gewesen und ist es auch heute nicht.

Und dieses "Meine Lieblinslizenz ist viel besser, weil es viel mehr (von mir als relevant angesehene) Softwareprojekte mit ihr gibt", das geht etwas Richtung Kindergarten wie: "VWs sind viel besser als BMWs, denn davon gibt es viel mehr und deswegen sind Trabis auch tausendfach besser als der Ferrari 599."

Es ging hier um kein "Meiner ist länger als deiner", sondern um eine Gegenargumentation zu "Nur die GPL sorgt dafür, dass meine Software frei bleibt und 3rd Party Patches kommen"

Ergänzung (3. März 2021)

Gpl ist nun mal viral. Und Bsdl erlaubt es nun mal, Geld damit zu verdienen.

Zum Rest deines Beitrages stimme ich dir zu. Aber auch die GPL erlaubt es, Geld damit zu verdienen

 

[RalphS]

Das ist erklärte Absicht, ja. Aber funktioniert in der Praxis nicht, weil wenn ich meinen gpl Code an dich verkaufe, dann kannst du ihn forken und der Welt kostenfrei zugänglich machen. Ich selber bekomme so exakt einmal Holz.

Geht, aber unwirtschaftlich und insbesondere auch den Ansprüchen der gpl eher entgegenstehend, die ja insbesondere NICHT für die Wirtschaft gedacht ist.

 

[foo_1337]

Naja, es gibt sehr viele Beispiele, wo das wunderbar funktioniert. Es kommt halt auf das Geschäftsmodell an. Frag doch mal Wordpress oder RedHat

 

[andy_m4]

Nein ich habe nie behauptet, dass es ohne GPL nicht möglich ist. Ich behaupte lediglich, dass es mit GPL bei bestimmten Projekten zu mehr Upstreaming kommt.

Ohne das aber belegen zu können. Ohne das sich das in der Praxis ein klarer Trend beobachten lässt.
Klar. Man kann natürlich alle möglichen Behauptungen aufstellen. Ich kann auch einfach wild behaupten, das bei zunehmenden Mond geschriebener Code grundsätzlich besser ist.

Jedenfalls hat das nichts mit der GPL zu tun.

Achnee. Genau das ist doch meine Argumentation.

Du bist doch derjenige der versucht allen möglichen Quatsch als Erfolg der GPL zu verkaufen. Und wählst dann irgendwelche Beispiele selektiv aus, um das dann zu "belegen".
Wenn man Dir dann Beispiele rauskramt die das Gegenteil "belegen", dann hat das plötzlich alles nix mehr mit der Lizenz zu tun.

Ja im Prinzip schon, wir haben beide keine handfesten Belege für unsere Standpunkte.

Ich behaupte ja nix. Ich widerspreche nur Deiner Behauptung.

Solche breaking Changes, wie sie bei Linux an der Tagesordnung sind, gibt es bei FreeBSD in der Form nicht, solange man im gleichen RELENG Zweig bleibt.

Wobei man fairerweise sagen muss, das es tatsächlich auch bei FreeBSD innerhalb einer Hauptversion Brüche gibt (insbesondere die Kernel ABI).
Erst neulich wieder bei 12.1 auf 12.2
Grafiktreiber kaputt. lsof kaputt. Gut. Ließ sich mit neukomplieren beheben. Nichtsdestotrotz kommt es halt durchaus öfter vor und ist nervig (u.a. weil die betreffenden latest-Packages 3 Monate lang unbrauchbar sind).

Nichtsdestotrotz ist bei Linux aber üblicherweise mehr Bewegung drin. Vor allem lässt das sich nicht immer durch neukompilieren fixen. Das ist auch der Grund, warum alle ihren Kram im offiziellen Kernel haben wollen. Weil es dann die Kernel-Maintainer nachziehen.
Besser wäre freilich eine stabiliere (interne) API. Dann lässt sich auch mehr Kram "out-of-tree" entwickeln und man muss das Kernel-Repository mit lauter Zeug vollstopfen, den dann vielleicht letztlich nur wenige brauchen.

Das ist erklärte Absicht, ja. Aber funktioniert in der Praxis nicht, weil wenn ich meinen gpl Code an dich verkaufe, dann kannst du ihn forken und der Welt kostenfrei zugänglich machen.

Ja. Open-Source oder gar GPL-Software stumpf zu verkaufen in der Hoffnung auf diese Weise Geld zu verdienen ist eher ... ungeschickt. :-)