• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Occupy GPL

C

CrimsonKing

Guest
Themenstarter #1
Oh, jemand hat die heilige GPL tatsächlich mal gelesen:

http://occupygpl.org

Auf reddit wird vermutet, dahinter stecke Oracle, die nur endlich ungestraft Code klauen dürfen wollen. Ach, Linuxer. So putzig manchmal.
 
C

CrimsonKing

Guest
Themenstarter #5
Kurzform: RMS, dem wir echt dankbar sein sollten, immerhin macht er GNU regelmäßig lächerlich (ich als Emacs-Fanboy darf das sagen ... :D)), findet, das Beitragen von Patches zu seinem komischen Softwarezeugs sei "Bombardement durch unfreie Software".
 

darktrym

Fahnenträger
#6
Das einzige Mal, dass ich dankbar war das GPL/GNU Software gab war damals als einige GCC geforkt haben und Leute einen gescheiten C-Compiler für DOS anboten, djgpp.
 

Kamikaze

Warrior of Sunlight
#7
Kennen eigentlich schon alle die Geschichte um Emacs und die Unterstützung von LLVM?
Fefe hat gestern den Original Thread verlinkt. Stallman kommt dort vielfach zu Wort und zwar sehr paranoid und Nutzer-feindlich.

Er fühlt das GCC durch LLVM angegriffen wird. Und da alle Software der Welt unter GPL stehen sollte, sollte man das nicht durch Emacs-Support für LLVM-Tools unterstützen.

Ich sehe das so, dass LLVM einen Mindeststandard für Compiler setzt. Dein Compiler muss (für Deinen Anwendungsfall) mindestens so gut wie LLVM sein, damit man dafür irgend etwas verlangen kann. GCC erfüllt diesen Anspruch einfach nicht. So, dass er auch kostenlos auf dem absteigenden Ast ist. Und das ist eine direkte Folge der GNU-Politik Modularisierung zu verhindern, damit niemand proprietäre Lösungen auf GCC drauf setzen kann.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#8
Ich finde, dass Stallmann speziell und die GCC-Entwickler allgemein sich LLVM hauptsächlich selbst zuzuschreiben haben:
  • Wie Kamikaze sagt, war die GCC mit voller Absicht technisch gesehen verkrüppelt worden, um eine ganze Klasse kommerzieller Anwendungen möglichst wirksam auszusperren. Dazu kam die äußerst harte Merge-Policy, neue Backend oder gar Frontends in die GCC aufgenommen zu bekommen ist sehr schwer. Beides führte dazu, dass LLVM schnell in Fahrt kam, nachdem es erst einmal eine gewisse Reife erreicht und für kommerzielle Nutzer interessant geworden war.
  • Man hat die GCC als politische Waffe genutzt, um die nicht mal im eigenen Lager besonders beliebte GPL3 durchzusetzen. Der Gedanke war, dass praktisch jeder GCC-Nutzer, der nicht ein reiner Anwender ist, sich damit zwangsläufig gegenüber der GPL3 öffnen müsse. Hierin lag wohl der Hauptgrund, dass Apple sich erst LLVM zuwandt und das Projekt erst richtig in Fahrt brachte. Auch die FreeBSDler haben sich hauptsächlich neueren GCC-Versionen verweigert, da man dieser "Friss oder stirb!"-Philosophie nicht folgen wollte. Nicht zuletzt brachte die GPL3 im GCC die Frage auf den Tisch, wie denn wohl eine GPL4 aussehen könnte.
Dazu könnte man als dritten Punkt sicherlich noch die Weigerung oder Unfähigkeit zu echtem Fortschritt in einigen Bereichen nennen. Es musste erst Clang kommen, bevor man bei der GCC überhaupt mal versuchte gute Warnungen zu generieren. Viele falsche Warnungen waren außerdem zuvor mit Argumenten wie z.B. eines zu aufwändigen Fixes ignoriert worden. Letztendlich wird LLVM die GCC aber nicht verdrängen. Idealerweise kommt es zu einer Konkurrenzsituation mit zwei etwa gleichstarken Spielern.
 

Kamikaze

Warrior of Sunlight
#9
Letztendlich wird LLVM die GCC aber nicht verdrängen. Idealerweise kommt es zu einer Konkurrenzsituation mit zwei etwa gleichstarken Spielern.
Das ist eines von zwei Szenarios. GCC hat seine Schlagfertigkeit als strategische Waffe eingebüßt. Darum gibt es keinen Grund mehr an der Verkrüppelung festzuhalten und der Compiler kann nach technisch sinnvollen Kriterien weiterentwickelt werden. Im Moment sieht es danach aus.

LLVM/Clang hat den GCC aber gerade erst mit Vollgas überholt und ich glaube da wird sich jetzt erst mal ein Abstand auftun, bis der GCC da wieder nachzieht. Wobei ich nicht verschweigen will, dass GCC da beim Tempo schon ordentlich angezogen hat.
 

goblin

Dämonenbeschwörer
#11
Das ist eines von zwei Szenarios. GCC hat seine Schlagfertigkeit als strategische Waffe eingebüßt. Darum gibt es keinen Grund mehr an der Verkrüppelung festzuhalten und der Compiler kann nach technisch sinnvollen Kriterien weiterentwickelt werden. Im Moment sieht es danach aus.

LLVM/Clang hat den GCC aber gerade erst mit Vollgas überholt und ich glaube da wird sich jetzt erst mal ein Abstand auftun, bis der GCC da wieder nachzieht. Wobei ich nicht verschweigen will, dass GCC da beim Tempo schon ordentlich angezogen hat.
Aber was ist mit der unglaublichen Menge Legacy-Code im GCC, z.B. der AVR-Unterstützung? Weiß jemand wie es da aussieht? Auch BlackBerry hat momentan nur GCC für QNX im Angebot. Im Embedded-Bereich ist der GCC momentan also noch ziemlich konkurrenzlos und ich frage mich, ob Atmel und BlackBerry wirklich gewillt sind, ihren Code auf LLVM zu portieren. Auch wenn GCC langsam auf dem absteigenden Ast ist, das Portieren und Umstellen kostet Geld und wenn große Firmen etwas hassen, dann Dinge die Geld kosten :) Ist eben die Frage, ob da jemand bald mal ausrechnet, dass nix tun noch teurer wird.
 
#12
Lustig.
Als ich vor zehn Jahren von gpl als ideologisch, fehlgeleitet und insgesamt schädlich sprach, nannte man mich erzürnt "Arschloch" und verdächtigte mich, Open Source feindlich zu sein und Firmen- oder womöglich cia Interessen zu vertreten.
Als ich vor drei Jahren von gpl als ideologisch, fehlgeleitet und insgesamt schädlich sprach, nannte man mich erzürnt einen bösen Mann und verdächtigte mich, Open Source feindlich zu sein und Firmen- oder womöglich cia Interessen zu vertreten.

Und nun bin ich plötzlich kein Arschloch mehr (na ja, in diesem Punkt) und stehe nicht mehr im Verdacht ... zu sein.

Dann mache ich mal den nächsten Schritt: Neben ein bisschem Guten haben linux und GPL gigantische und großflächige Schäden verursacht. BSD, sowohl die OSs wie auch die Lizenz, war schon immer der bessere, der richtige Weg.
Man verschenkt sein Zeug oder man verkauft es - und wird für seine Arbeit ordentlich bezahlt. Verschenkt wurde auch schon vor linux/gpl Zeiten. Und oft richtig gute Sahne. Was haben wir dank gpl? Alle sehen nur linux und gcc, etc. Aber wir haben auch gazillionen "Programme" von hirntoten, inkompetenten Hobbyfraggles, die wichtig wurden, teilweise quasi Standards weil gazillionen anderer hirntoter Blödiane die sooooo geil finden (und das obwohl sie das nicht mal ansatzweise beurteilen können).

Ach und, linux rant des Tages: debian (aber vermutlich auch andere) liefern nach wie vor NSD3 statt das (seit langem verfügbare) NSD4. Wer macht's richtig? FreeBSD, natürlich. In den ports ist v3. für Altinstallationen und v4. Danke FreeBSD!
 

Kamikaze

Warrior of Sunlight
#13
Aber was ist mit der unglaublichen Menge Legacy-Code im GCC, z.B. der AVR-Unterstützung? Weiß jemand wie es da aussieht? Auch BlackBerry hat momentan nur GCC für QNX im Angebot. Im Embedded-Bereich ist der GCC momentan also noch ziemlich konkurrenzlos ...
Ich weiß nicht wie es um QNX steht, aber AVR-GCC ist ein Fork. Ich wüsste nicht, dass das jemals zurückportiert wurde. Für 8-bittrige µCs nehme ich übrigens SDCC. Dann gibt es noch die Compiler von Keil (C51, C251, C166, ARMCC) das inzwischen zu ARM gehört. Da sind zwar genau so viele Fehler drin wie im Open Source Compiler SDCC aber der Vorteil kommerzieller Software schlägt hier schnell durch. Alle Bugs die ich bisher eingereicht habe wurden höflich, kompetent und zügig gefixt.

Jedenfalls ist GCC alles andere als alternativlos.
 

goblin

Dämonenbeschwörer
#14
Ich weiß nicht wie es um QNX steht, aber AVR-GCC ist ein Fork. Ich wüsste nicht, dass das jemals zurückportiert wurde.
Ah, das war mir gar nicht klar. Habe schon eine ziemliche Weile nicht mehr mit Atmels gearbeitet.

Für 8-bittrige µCs nehme ich übrigens SDCC. Dann gibt es noch die Compiler von Keil (C51, C251, C166, ARMCC) das inzwischen zu ARM gehört. Da sind zwar genau so viele Fehler drin wie im Open Source Compiler SDCC aber der Vorteil kommerzieller Software schlägt hier schnell durch. Alle Bugs die ich bisher eingereicht habe wurden höflich, kompetent und zügig gefixt.

Jedenfalls ist GCC alles andere als alternativlos.
Alternativlos nicht, aber auf die volle Bandbreite gesehen bislang dennoch der Platzhirsch.
Und Embedded-Systeme bestehen nicht nur aus 8-bittern, wie wir schon in einem anderen Thread verhandelt haben.

QNX nutzt eine ARM-Variante von GCC, bin mir ziemlich sicher dass das recht nah am Upstream sein duerfte. Zumindest im BlackBerry SDK 10.3 ist ein 4.8 drin, der sich als ganz normaler Cross-GCC identifiziert.
 
#15
Hallo,

bei Popcorn und Radler habe ich gerade mal die Diskussion ein wenig quer gelesen. Besonders bemerkenswert fand ich diese Äußerung vom 10.02.2015, 09:24:59:
> If I had seen it back then, I would not have had the benefit of
> hindsight, but it would clearly have been a real possibility. Nothing
> would have ruled it out.

Has somebody asked Chris Lattner, who seems to the leader on the LLVM
project, if they are willing to change the license now to simplify
coexistence with the GCC project? His answer would be more interesting
than speculations about Apple's intentions.
Verstehe ich das richtig? Da wollte jemand die LLVM-Entwickler dazu bewegen, das Lizenzmodell zu ändern, nur damit es zum Emacs passt?

Was mich an der gesamten Diskussion so richtig aufregt sind
diese hetzende Rhetorik
diese "Wer nicht für uns ist, ist gegen uns"-Metalität
diese mangelnde Kompromissbereitschaft
diese Mentalität ala : Am GPL-Wesen soll die OpenSource-Welt genesen.

Absolut gaga und krank und der OpenSource-Bewegung absolut nicht dienlich... So ein Kindergarten
 

SolarCatcher

Well-Known Member
#16
Was mich an der gesamten Diskussion so richtig aufregt sind
diese hetzende Rhetorik
diese "Wer nicht für uns ist, ist gegen uns"-Metalität
diese mangelnde Kompromissbereitschaft
diese Mentalität ala : Am GPL-Wesen soll die OpenSource-Welt genesen.
Grundsätzlich stimme ich Dir zu. Und ich würde in den allermeisten Fällen eine BSD- oder MIT-Lizenz einer GPL vorziehen.

Andererseits habe ich Verständnis dafür, wo Stallman & Co herkommen. Wird hier im Forum nicht auch heftig über Systemd geredet, als sei es Teufelszeug, das alles kaputt macht, was damit in Berührung kommt? Systemd macht zwar nicht unsere BSD-Software kaputt, aber sehr viele von uns setzen Desktop Environments oder ähnliches ein, die möglicherweise bald ohne Systemd nicht mehr können. Stallmans Angst ist noch fundamentaler, dass wir nämlich irgendwann unsere eignene Computer nicht mehr so nutzen können, wie wir es wollen, z.B. weil uns ein Apple oder Microsoft vorschreiben will, was wir installieren, ändern usw. dürfen. Dem kann man nur entgehen, wenn man komplett auf solche Software verzichtet. Und am besten nicht einmal dazu beiträgt, dass es sie gibt (die BSDs haben ja einen beachtlichen Teil von MacOS X beigesteuert). In eine ähnliche Richtung hatte ja Corey Doctorow in seiner 28C3-Keynote argumentiert: The Coming War on General Purpose Computation
Daher finde ich das nicht alles "Kindergarten", sondern - selbst wenn ich es anders machen würde - auch verständlich.
 

goblin

Dämonenbeschwörer
#17
Aber da du es schon erwähnst, die GPL schützt uns vor so einem Verhalten nicht, systemd selbst ist GPL lizensiert und wirkt dennoch einschränkend.
 

-Nuke-

Well-Known Member
#18
Verstehe ich das richtig? Da wollte jemand die LLVM-Entwickler dazu bewegen, das Lizenzmodell zu ändern, nur damit es zum Emacs passt
Er wurde bereits in der laufenden Unterhaltung darauf hingewiesen, dass die LLVM-Lizenz GPL-Kompatibel ist. Das heißt, wenn die GPL-Jungs in pure Panik verfallen, könnten sie LLVM forken und sämtlichen Code unter die GPL stellen und parallel alleine daran weiterarbeiten.

Das Ganze löst nur "das Problem" der Modularisierung nicht. Die "Grundangst" ist, dass jemand GPL-Software nimmt, Output mit dieser erzeugt und dann mit geschlossener Software diese weiterverarbeitet (oder anders herum, Input erzeugt und diese mit GPL-Software verarbeitet).

Der Grund warum die GCC-Architektur so beschissen ist und GDB und Co. quasi das halbe C/C++ Frontend noch mal selbst implementieren muss. GCC rückt es halt einfach nicht raus.

Prinzipiell ist die Angst von Stallman aber schon begründet, auch wenn sein Umgang mit dem Problem recht dämlich ist. Er weiß ja noch nicht mal in der Diskussion was LLDB überhaupt ist und er konnte sich nicht mal vorstellen, dass es GDB haushoch überlegen ist "they must have been working a long long time"... ohne zu merken, dass eine gute Architektur wunder wirken kann.

Aber es gibt im BSD-ähnlichen Lizenzbereich halt immer schwarze Schafe. Als Beispiel mal Nvidia und Apple die zwar LLVM nutzen, aber bestimmte Komponenten nicht herausrücken. Apple z.B. das Frontend für Swift, Nvidia ihre Frontends für CUDA und OpenCL und ihre Backends für PTX (glaube ich, weiß jetzt nicht). Somit hast'e zwar LLVM, aber damit es in dem Bereich funktioniert, brauchst du Closed-Source Software (z.B. ein Backend für einen Prozessor, siehe NVidia).

Es ist so also möglich, dass man die Arbeit von OpenSource-Software zwar nutzt, aber sämtliche Kernkomponenten abriegelt. Das ist ein anderes Problem als "Ich nehme die Software, klebe mein Label drauf und verkaufe es für 100000 EUR".

Das ist das was Stallman halt nicht will und gerade versucht mit aller Macht zu verhindern, nur leider auf dem Weg, in dem wer GCC schlechter macht xD

Anderes Beispiel war/ist der Raspberry Pi, der ohne ClosedSource Software/Firmware überhaupt so gar nichts macht. Selbst OpenGL-Kommandos wurden einfach an die Firmware weitergeleitet und die Rückgabe verwertet. Hier hast du auch zwar OpenSource Treiber, aber die können nichts anderes tun als ihre Arbeit _komplett_ an geschlossene Firmware weiterzuleiten. Damit kannst'e natürlich nichts anfangen. Das hat sich zwar jetzt dank Doku geändert, aber andere Teile des Systems betrifft es noch.
 

foxit

Well-Known Member
#19
Es ist so also möglich, dass man die Arbeit von OpenSource-Software zwar nutzt, aber sämtliche Kernkomponenten abriegelt.
Und genau darum ist die GPL wichtig! Was haben den Firmen (Apple) an z.B. FreeBSD zurückgegeben, wenn es ihnen nicht selber nützt? Nichts!

Heute ist die Einstellung gegenüber Open Source ganz anderst als vor 20 Jahren. Da hat man sich doch an der "Gratissoftware" bedient und dachte: "Selber Schuld ihr Idioten. Wenn ihr den Code offen legt, habt ihr es nicht anderst verdient!". Die Entwicklung einer Software geht heute viel schneller. Da portieren die Firmen den Code lieber zurück auf Upstream, um sich selber nicht mehr gross darum kümmern zu müssen.

Meiner Meinung muss man ihm Respekt zollen! Ohne die GPL würde Open Source nicht da stehen, wo es heute steht. Natürlich ändern sich auch die Zeiten...
 
#20
Moin,

Für Herrn Stallmans Position habe ich durchaus Verständnis und ich teile die Befürchtungen und Ängste. Aber auch die GPL wird schwarze Schafe nicht stoppen. Ich will nicht wissen, wieviele kommerzielle Compilersysteme auf gcc basieren und deren Anbieter dann gerichtlich gegen "OpenSource" vorgehen, es versuchen oder einfach nix sagen.
Mich nervt halt dieser unnötige Kleinkrieg. Herr Stallman könnte alle Vertreter von OpenSource-Lizenz an einen Tisch holen und eine gemeinsame Strategie gegen die schwarzen Schafe beschließen. Damit wäre allen gedient und würde OpenSource stärken. Dazu braucht es allerdings Persönlichkeiten wie Herrn Stallman oder Herrn de Raadt.
 

-Nuke-

Well-Known Member
#21
Und genau darum ist die GPL wichtig! Was haben den Firmen (Apple) an z.B. FreeBSD zurückgegeben, wenn es ihnen nicht selber nützt? Nichts!
Wobei auch hier ein Unterschied zwischen "Man nimmt BSD-Code und gibt nichts zurück" (wobei FreeBSD von Apple diverse Dinge übernehmen konnte) und "Man nimmt BSD-Code und macht ihn ohne Closed-Blob unbenutzbar".

Das Erste halte ich für weniger Problematisch. Das ist der Geist der BSD-Lizenz... Letzeres sehe ich aber schon als Gefahr an, wo jedoch die GPL keine Lösung ist (da sie es nicht löst). Stallmans Lösung ist, den GCC zu verkrüppeln... und das ist total dämlich.

LLVM zeigt es leider dank der schwarzen Schafe, dass es durchaus geschehen kann. Ist momentan nicht tragisch, da es nur Nvidia und eine Sprache bei Apple betrifft... aber wenn man es weiter spinnt, dann sind durchaus diverse Dinge möglich. "Dieses Feature kriegt du nur mit unserem geschlossenen Backend ****NSA Code included"...
 

darktrym

Fahnenträger
#23
Nvidia nutzt seinen Blob auch mit dem Linux-Kernel, das kann die GPL auch nicht verhindern. Möchte man das nicht, sind beide Lizenzen die falsche Wahl. Die BSDL ist genau dafür entwurfen wurden, Änderungen müssen nicht sofort zurückgegeben werden. Sinnvoller wäre es natürlich, es sei denn man will sich den Stress antun und seinem Kram ständig mit dem Upstream im Sync halten. Es gibt keine schwarzen Schafe bei BSD-lizenzierter Software.
 

ed1949

Well-Known Member
#24
Prinzipiell ist die Angst von Stallman aber schon begründet, ...
Das denke ich auch, bzw ich weiss es aus eigener leidvoller Erfahrung. Gerät gekauft und extra auf die GPL geachtet und am Ende ein für mich wertloses Stück Elektroschrott in den Händen gehalten, weil die Firmware verdongelt war. Sowas ist mehr als nur ärgerlich.

Hätte die Firma BSD Code genommen wäre die Sache wesentlich schmerzfreier ausgegangen - ich hätte den Dreck erst gar nicht gekauft.

Im Prinzip ist es ganz einfach. BSD gibt mir als erstem(!) Entwickler alle möglichen Freiheiten. GPL sollte(!) dem letztendlichen Anwender alle möglichen Freiheiten geben, auch wenn die Firmen das inzwischen sehr gut zu verhindern wissen. Wäre die GPL tatsächlich effektiv, würde ich in als Konsument nur GPL kaufen, da ich sonst meist nur zugedongelten Consumerschrott bekomme, der weit hinter seinen theoretischen Nutzungsmöglichkeiten zurückbleibt. Für private Projekte ist mir die Lizenz fast egal, solange ich den möglichst vollständigen Source Code bekomme. Geschäftlich nehme ich was kommt und regle meine Preisgestaltung entsprechend.
 
#25
Manchmal entsteht der Eindruck, open source code zu nehmen und irgendetwas damit zu machen, was nicht der Beförderung von open source dient, sei fies und bösartig und müsse vermieden werden wie die Pest.

Sorry, nein.

Der Urgedanke von open source war - und zwar schon lange vor linux - ein anderer. Die ursprünglichste Linzenz war eine Art "do what the fuck you want" Lizenz. BSD geht klar in diese Richtung. Die wirkliche Forderung war und ist "Sag nicht, es sei deins!", also die Pflicht anzugeben, dass ein Stück code von x oder y (und nicht von einem selbst) ist.

linux und gpl politisierten und ideologisierten die ganze Kiste bis hin zur Zwangsinfektion. Das ist OK, das kann man machen, aber das ist politisch und nicht technisch; dabei geht es um etwas Politisches und der Code ist nur ein Vehikel dafür. Bei wirklicher open source aber geht es um Technik, um Code. Und so begreift man bei BSD auch, dass es in der Tat sogar gut ist, wenn kommerzielle Produkte den Code verwenden. Ein router mit BSD code drin ist mir doch allemal lieber als einer mit wer-weiss-welchem selbstgebastelten Mist fragwürdiger Qualität. Mehr noch, wenn mein OS code weiter entwickelt oder Bugs behoben werden, sind die Chancen hoch, dass die closed source Version in z.B. einem Router das dann auch übernimmt.

Ich verstehe Stallman, mit dem ich übrigens vor Jahren auch mal persönlich darüber sprach, durchaus. Der kämpft einen *politischen* Kampf, den ich durchaus verstehen kann und den ich auch nicht belächle; der Mann ist sehr intelligent und führt einen Kampf mit edlen Absichten, keine Frage. Was ich aber hinterfrage und kritisiere ist die Unsitte, Code und Coder in Geisselhaft zu nehmen und zu politischen Zwecken - gleich wie edel die intentioniert sein mögen - zu nutzen/missbrauchen.

Ich selbst verwende gpl Zeug nur, wenn unbedingt nötig oder wenn völlig egal. Für eigenen Code auf keinen Fall; da meide ich gpl Zeug wie Pest und Cholera. Manches von dem, was ich baue stelle ich open source oder auch mal closed source zur Verfügung, als frei und/oder kostenlos. Aber vieles auch nicht. Weil ich davon lebe. Weil ich nicht gewillt bin, 25 Jahre mühsam erarbeitete Erfahrung und jede Menge Arbeit zu verschenken. Und weil ich es mir ebenso wenig leisten kann, wie Anwälte, Bäcker oder Autohersteller, die Früchte meiner Arbeit zu verschenken.

Und trotzdem kann ich mein Schärflein beitragen und *möchte* das auch. Indem ich Studenten helfe, indem ich Wissen weitergebe, indem ich öfter mal Kauf-Software verschenke oder fast verschenke, indem ich so einiges open source stelle, usw.