Abo
  1. Foren
  2. Kommentare
  3. Politik/Recht
  4. Alle Kommentare zum Artikel
  5. › Linux: Mit Ignoranz gegen die GPL

Umdenken auch bei Kernel-Entwicklern erforderlich

  1. Thema

Neues Thema Ansicht wechseln


  1. Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: irisquelle 20.03.18 - 04:55

    Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv. Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen Linzenzverstößen mit Prozessen zu überziehen. Hier allein auf die "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen, reicht nicht aus. Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die Hersteller von Geräten, die den Linux-Kernel einsetzen, ihre Erweiterungen nicht offenlegen können. Daher sollten sich die GPL-Verfechter darüber klar werden, dass man nicht beides haben kann: die massenhafte kommerzielle Verbreitung des Linux-Kernels lässt sich schwerlich damit vereinbaren, wenn jeder Hersteller gezwungen wird seine Geschäftsgeheimnisse zu offenbaren.

    Eher schon kann ich mir eine Partitionierung des Linux-Kernels in zwei unterschiedlich lizensierte Bereiche vorstellen. Zum einen einen echten "Kern", wo hardware-übergreifende Funktionen realisiert wird (also Scheduler, Memory Management, Netzwerkstack usw.), der weiterhin unter der GPL lizensiert ist. Und einen "Randbereich", wo Hersteller etwa Hardware-nahe Features wie Treiber umsetzen und vor der zwangsweisen Offenlegung ihres geistigen Eigentums geschützt sind. Eine weitere Alternative sind Karenzfristen, während derer die Hersteller ihren Code zurückhalten dürfen. Nach fünf Jahren dürfte es für den Hersteller eines Android-Geräts weniger schmerzhaft sein, wenn die programmierten Treiber zum Allgemeingut werden. Noch besser wäre es, wenn der Linux-Kernel perspektivisch die GPL aufgibt und zu einer liberaleren Lizenz wechselt. Übergangsweise ist auch eine Dual-Lizensierung denkbar, bei der Verwender des Linux-Kernels sich ggf. für eine alternative Lizenz entscheiden könnten. Das kann auch gegen Lizenzgebühren erfolgen, die dann per Verteilungsschlüssel an die Kernel-Programmierer ausgeschüttet werden.

  2. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: wilima 20.03.18 - 06:33

    Ich hoffe, du machst Witze! Eine Lizenz ist eine Lizenz ist eine Lizenz! Wenn ein Hersteller Geschäftsgeheimnisse hat, muss er eben ein eigenes Betriebssystem entwickeln oder könnte z. B. ein kommerzielles lizensieren.

    Die massenhafte Verbreitung des Linux-Kernels wurde überhaupt erst durch die GPL ermöglicht! Denn jeder Hersteller, der eine Erweiterung benötigt, muss diese öffentlich machen. Dadurch entwickelt sich der Kernel weiter und wird für mehr Leute interessant, die dann wieder eine Erweiterung benötigen und diese öffentlich machen müssen ...

    Alles andere ist kommerzielles Ausbeuten der Kernel-Entwickler, die genau deshalb zu ihrem Schutz unter der GPL entwickeln.

  3. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: irisquelle 20.03.18 - 08:27

    Ausgebeutet werden viele Kernel-Entwickler schon jetzt. Ich sehe jedenfalls nicht, dass die vielen Freizeit-Programmierer auch nur eine geringfügige wirtschaftliche Entschädigung für ihre Beiträge erhalten würden. Und andere Software ist beispielsweise BSD, MIT oder Apache-lizensiert und trotzdem erfolgreich. Meine These ist, dass Linux trotz, aber nicht wegen der GPL erfolgreich ist.

    Man sollte das Thema Lizensierung grundsätzlich ideologiefrei betrachten. Vor allem sollten die Protagonisten der Community regelmäßig überprüfen, inwiefern die GPL noch zweckmäßig ist. Es kann ja sein, dass die GPL in den Anfangsjahren von Linux die richtige Wahl war. Inzwischen wäre aber eine Dual-Lizensierung in vielen Fällen zeitgemäßer.

    Als Beispiel einmal ein fiktives Szenario: ein SaaS-Anbieter passt GPL-lizensierte Software für seine Zwecke an. Dann setzt er diese Software ohne Veröffentlichung des Quellcodes in seiner Cloud ein. Das ist zwar auch eine Lizenzverletzung, lässt sich aber praktisch nicht nachweisen.

    Demgegenüber müssen Hersteller von Hardware mit Linux-basierter Firmware oder Programmierer von installierter Software mit GPL-lizensierten Komponenten ihre Firmware/Software offen legen - allein weil der Nachweis einer Lizenzverletzung ungleich einfacher ist. Diese Unterscheidung ist nicht nur unfair - vor allem zeigt es, wie die GPL aus der Zeit gefallen ist. Der Gedanke der Offenlegung des Quelltextes ergibt im Zeitalter von Cloud-basierten Diensten immer weniger Sinn.

  4. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: a user 20.03.18 - 13:35

    irisquelle schrieb:
    --------------------------------------------------------------------------------
    > Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv.
    > Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity
    > beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen
    > Linzenzverstößen mit Prozessen zu überziehen. Hier allein auf die
    > "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen, reicht
    > nicht aus.

    Doch!
    > Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die
    > Hersteller von Geräten, die den Linux-Kernel einsetzen, ihre Erweiterungen
    > nicht offenlegen können.
    Nein gibt es nicht. Ich abreite in einer Firma die sich genau damit schwer tut und es ist EINZIG UND ALLEINE UNSERER DUMMHEIT und FAULHEIT geschuldet. Denn es wurde nicht einmal einn erstnhafter Versuch unternommen dem Folge zu leisten.

    Es sieht nämlich so aus:
    A : "Was kostet uns das?"
    B: "Nix. Aber du musst da paar Kleinigkeiten erfüllen. Und zwar..."
    A: "Ah ne, dann lassen wir das. Zu aufwändig und wer weiß was da schief gehen kann."
    > Daher sollten sich die GPL-Verfechter darüber klar
    > werden, dass man nicht beides haben kann: die massenhafte kommerzielle
    > Verbreitung des Linux-Kernels lässt sich schwerlich damit vereinbaren, wenn
    > jeder Hersteller gezwungen wird seine Geschäftsgeheimnisse zu offenbaren.
    Darüber sind sich die GPL Verfechter im Klaren. Denn wenn du dich einmal mit der GPL beschäftigt hättest, dann wüstest du, dass sie das gar nicht zum Ziel hat. Das Ziel ist mithilfe guter Software über diese Lizenz Software frei für alle zu erzwingen.
    Was du mit unserem Zeug machst, musst du allen frei zugänglich machen. Das hat mit Nichten das Ziel diese Software weit zu verbreiten.

    Andersurm wird ein Schuh draus: man versucht die Verbreitung, weil es gute und freie Software ist dazu zu nutzen, damit immer mehr Software frei wird.

  5. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: Thaodan 20.03.18 - 21:16

    irisquelle schrieb:
    --------------------------------------------------------------------------------

    > Als Beispiel einmal ein fiktives Szenario: ein SaaS-Anbieter passt
    > GPL-lizensierte Software für seine Zwecke an. Dann setzt er diese Software
    > ohne Veröffentlichung des Quellcodes in seiner Cloud ein. Das ist zwar auch
    > eine Lizenzverletzung, lässt sich aber praktisch nicht nachweisen.
    Nein wäre es nicht, nur bei AGPL.

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

  6. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: Silberfan 29.03.18 - 09:42

    irisquelle schrieb:
    --------------------------------------------------------------------------------
    > Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv.
    > Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity
    > beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen
    > Linzenzverstößen mit Prozessen zu überziehen. Hier allein auf die
    > "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen, reicht
    > nicht aus. Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die
    > Hersteller von Geräten, die den Linux-Kernel einsetzen, ihre Erweiterungen
    > nicht offenlegen können. Daher sollten sich die GPL-Verfechter darüber klar
    > werden, dass man nicht beides haben kann: die massenhafte kommerzielle
    > Verbreitung des Linux-Kernels lässt sich schwerlich damit vereinbaren, wenn
    > jeder Hersteller gezwungen wird seine Geschäftsgeheimnisse zu offenbaren.

    Die Schwierigkeit liegt im Risiko des Betreibers. Wenn er nun also kein Geld für Software Zahlen muss,dann ist es auch klar das er kein Geld verlangen kann und darf beim Kunden. Ebenso muss der Quellcode Offengelegt werden. Es reicht im allgemeinen aus die Ansprech-Adressen der Hardware korrekt aufzulisten und eine entsprechende Dokumentation dazu mitzugeben. die meisten Hersteller scheuen aber die Kosten die dabei entstehen. Wobei die Kostenpflichtige Closed Version im Vergleich zur Open Source teurer wäre. Man muss aber auch aus Firmensicht selbst entscheiden. Will man kosten in der Software Welt einsparen dann muss ich auch die Folgen die dadurch entstehen können mit in Betracht ziehen(Offenlegung des Quellcodes ,saubere Dokumentation ,etc.) . Oder ich betreibe Closed Source und kann so keine Umsatzzahlen oder geringere generieren und muss Möglicherweise auch den Support zur Software ( Treiber ,etc. ) dann auch noch Übernehmen.


    > Eher schon kann ich mir eine Partitionierung des Linux-Kernels in zwei
    > unterschiedlich lizensierte Bereiche vorstellen. Zum einen einen echten
    > "Kern", wo hardware-übergreifende Funktionen realisiert wird (also
    > Scheduler, Memory Management, Netzwerkstack usw.), der weiterhin unter der
    > GPL lizensiert ist. Und einen "Randbereich", wo Hersteller etwa
    > Hardware-nahe Features wie Treiber umsetzen und vor der zwangsweisen
    > Offenlegung ihres geistigen Eigentums geschützt sind. Eine weitere
    > Alternative sind Karenzfristen, während derer die Hersteller ihren Code
    > zurückhalten dürfen. Nach fünf Jahren dürfte es für den Hersteller eines
    > Android-Geräts weniger schmerzhaft sein, wenn die programmierten Treiber
    > zum Allgemeingut werden. Noch besser wäre es, wenn der Linux-Kernel
    > perspektivisch die GPL aufgibt und zu einer liberaleren Lizenz wechselt.
    > Übergangsweise ist auch eine Dual-Lizensierung denkbar, bei der Verwender
    > des Linux-Kernels sich ggf. für eine alternative Lizenz entscheiden
    > könnten. Das kann auch gegen Lizenzgebühren erfolgen, die dann per
    > Verteilungsschlüssel an die Kernel-Programmierer ausgeschüttet werden.

    Die Problematik gestaltet sich in 2 ebenen. Kostenpflichtig und kostenfrei. nimmt man kostenpflichtig will keiner was damit zu tun haben. Kostenfrei nutzt somit jeder. Es gibt zig andere Methoden und Möglichkeiten die Kosten der Softwareentwicklung wieder einzuspielen. Man muss nicht stur auf die eine oder andere Möglichkeit sein Geschäftsmodell setzten. Man kann auch z.B. durch Zusatz Modulen oder extras die es so gibt auch einen weiteren Zweig für Finanzielles einsetzten.
    Beispiel: jemand hat Grafikkarte X in Benutzung ,zockt aber nicht ,brauch als das geblubber für die Treiber im Gaming Bereich nicht. Ihm reichen Standard Treiber ,also zahlt er nix. Jemand anderes Zockt gerne und brauch den Kram. Also einmalig sich registrieren, 5¤ im Jahr für den Treiber Kram Bezahlen lassen, fertig. Wenn das z.B. 500.000 Leute das machen so könnte man mit dem Geld Locker 2 Programmierer ( evtl. mehr) finanzieren die Bugs oder Probleme beheben und diese dann Zeitnah auch fixen.
    Einfacher Dargestellt, für Standard zahlt man nix. Für Extras sollte man einen kleinen Betrag hinlegen. Das Denkbar Schlechtestes Beispiel im Kostenpflichtigen Bereich wäre Crossover von Cedega das schon 50-60¤ Pro Jahr Verlangt. Würden die z.B. auf 5¤ runter gehen , würden auch viel mehr Leute Ihre Software nutzten.

  7. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: Hello_World 03.04.18 - 17:32

    Es ist wenig sinnvoll, darüber zu diskutieren, ob der Kernel mit einer liberaleren Lizenz besser dran wäre, da es ohnehin nicht dazu kommen wird. Tausende Leute haben mittlerweile daran mitgearbeitet. Einige dürften sich schlicht weigern, ihren Code unter eine andere Lizenz zu stellen, andere sind unauffindbar oder tot.

    Zudem ist ohnehin zweifelhaft, ob es wirklich besser und technisch machbar wäre. Wäre der AMD-Grafiktreiber heute Open Source, wenn die GPL nicht wäre? Wie sieht es mit den Android-Features aus, die in den Mainline-Kernel gemerged wurden? Ich glaube nicht, dass der Kernel heute so weit wäre, wie er ist, wenn er unter einer liberaleren Lizenz gestanden hätte.
    Ganz zu schweigen davon, dass das auch ein stabiles Kernel-ABI nötig machen würde, was die Weiterentwicklung erschwert.

  8. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: metux 18.10.18 - 18:23

    > Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv.
    > Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity
    > beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen
    > Linzenzverstößen mit Prozessen zu überziehen.

    Im Gegenteil: es ist wichtig, daß sich einige Leute intensiv darum kümmern und
    zumindest mit den großen Raubkopierern hart ins Gericht (im wörtlichen Sinne) gehen.
    Sie beschützen damit unsere Interessen.

    > Hier allein auf die "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen,
    > reicht nicht aus.

    Oft ist es ja nichtmal Dummheit, sondern klarer Vorsatz. Betrug. Und das brauchen
    wir uns nicht bieten lassen - vorallem nicht von Schmarotzern, die sonst an jeder
    Ecke ihre Lizenzansprüche durchboxen.

    > Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die Hersteller von Geräten,
    > die den Linux-Kernel einsetzen, ihre Erweiterungen nicht offenlegen können.

    Na und ? Deren Problem, nicht unseres. Dann sollen sie halt irgendwas kommerzielles
    nehmen - gibts doch 'nen Haufen Angebote, wo man einfach nur viele Münzen einwerfen
    muß. Wir sind doch nicht die kostenlosen Handlanger für irgendwelche Firmen, die nichtmal
    ein vernünftiges Lizenzmanagement auf die Reihe bekommen.

    > Daher sollten sich die GPL-Verfechter darüber klar werden, dass man nicht beides
    > haben kann: die massenhafte kommerzielle Verbreitung des Linux-Kernels lässt sich
    > schwerlich damit vereinbaren, wenn jeder Hersteller gezwungen wird seine
    > Geschäftsgeheimnisse zu offenbaren.

    Mir persönlich ist die *kommerzielle* Verbreitung mal komplett scheißegal.

    Und wer ein paar Interface-Specs, die nötig sind, um ein bissl Treiber zu schreiben,
    ernsthaft als großes "Geschäftsgeheimnis" betrachtet, der hat von professioneller
    Software-Entwicklung schonmal gar keine Ahnung - und genau das bekommen wir
    von dem kaputten proprietären Gerümpel immer wieder bestätigt. Ich erinnere mich
    zB. spontan an Freescale-Code (mx5->adreno), dessen Autor(en) ganz offentsichtlich
    nichtmal die essentiellen C-Grundlagen beherrschen - und sowas soll dann auch noch
    für mission-critical-Dinge wie zB. Medizinprodukte eingesetzt werden. Solche Leute
    gehören doch besser in unkritische Jobs, wie zB. Straße fegen, wo sie nicht so viel
    Schaden anrichten können.

    > Eher schon kann ich mir eine Partitionierung des Linux-Kernels in zwei
    > unterschiedlich lizensierte Bereiche vorstellen. Zum einen einen echten
    > "Kern", wo hardware-übergreifende Funktionen realisiert wird (also
    > Scheduler, Memory Management, Netzwerkstack usw.), der weiterhin unter der
    > GPL lizensiert ist.

    Aha, und wo genau soll da die Grenzlinie sein ? Wie genau soll das praktisch umgesetzt
    und durchgehalten werden ? Abgesehen davon: warum sollten wir uns überhaupt
    sowas antun ? Was haben wir davon ? (by the way: bei mir sind alle neuen Symbole
    stets GPL_ONLY, basta.)

    > Und einen "Randbereich", wo Hersteller etwa Hardware-nahe Features wie Treiber

    Dieser "Randbereich" ist schon da: Userland. Ja, da kann man auch allerhand tun.
    Und wir sehen ja schon seit Jahren, was dabei rauskommt: Schrott.

    > umsetzen und vor der zwangsweisen Offenlegung ihres geistigen Eigentums geschützt sind.

    Und wir Nutzer der Willkür des Herstellers (zB. "geplante Obsoleszenz" = Eingehungsbetrug,
    Digital Restriction Management, Backdoors, usw) ausgesetzt sind. Nein, solchen Müll will
    ich garnicht - und ich werde auch keinen Finger krumm manchen, sowas irgendwie für
    irgendwen einfacher zu machen. Im Gegenteil.

    > Eine weitere Alternative sind Karenzfristen, während derer die Hersteller ihren Code
    > zurückhalten dürfen.

    Ahja, wird ja noch komplizierter. Wer genau soll die nach welchen Kriterien genau
    definieren ? Wie irrsinnig komplex soll der ganze juristische Unterbau - mit allen
    Konsequenzen für die rechtliche Durchsetzung werden ?

    Die GPL hier ist völlig klar (das einzige Manko war die Tivoization-Bug - der wurde aber
    mit v3 behoben). Deal or no deal. Wem das nicht paßt, der soll einfach fern bleiben.
    Und wer den Vertrag eingeht und dann bricht, der soll auch ordentlich dafür haften.

    Bisher war die Rechtsdurchsetzung ja noch *sehr* milde. Hier und da mal ein Verkaufs-
    Verbot für ein paar Geräte ist noch harmlos. Nähme man die Lizenz wirklich ernst,
    müßten die verletzenden Firmen sofort *ALLE* Linux-basierten Geräte *ABSCHALTEN*.

    > Nach fünf Jahren dürfte es für den Hersteller eines
    > Android-Geräts weniger schmerzhaft sein, wenn die programmierten Treiber
    > zum Allgemeingut werden.

    Warum so lange warten - wenn die Geräte bis dahin eh schon kaputt sind ?
    Das ist doch eine Lachnummer !

    > Noch besser wäre es, wenn der Linux-Kernel perspektivisch die GPL aufgibt und zu
    > einer liberaleren Lizenz wechselt.

    Die Wahrscheinlichkeit nähert sich asymptotisch an Null an. Und zwar von unten.

    > Übergangsweise ist auch eine Dual-Lizensierung denkbar, bei der Verwender
    > des Linux-Kernels sich ggf. für eine alternative Lizenz entscheiden
    > könnten. Das kann auch gegen Lizenzgebühren erfolgen, die dann per
    > Verteilungsschlüssel an die Kernel-Programmierer ausgeschüttet werden.

    Aha, also einen Irrsinn a la GEMA (war ja mal eine Nazi-Erfindung) bauen ?
    Total absurd.

    --mtx

  9. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: metux 18.10.18 - 18:29

    > Man sollte das Thema Lizensierung grundsätzlich ideologiefrei betrachten.

    Hier zeigt sich genau faustische Problem - viele Techniker scheren sich überhaupt
    nicht um die gesellschaftlichen und politischen Konsequenzen ihre Werke.
    Genau das macht die GPL anders.

    > Inzwischen wäre aber eine Dual-Lizensierung in vielen Fällen zeitgemäßer.

    Entscheided wer ? Du etwa ?

    > Als Beispiel einmal ein fiktives Szenario: ein SaaS-Anbieter passt
    > GPL-lizensierte Software für seine Zwecke an. Dann setzt er diese Software
    > ohne Veröffentlichung des Quellcodes in seiner Cloud ein. Das ist zwar auch
    > eine Lizenzverletzung, lässt sich aber praktisch nicht nachweisen.

    Früher oder später bekommen wir das raus - und dann kann das schnell
    mal das Aus für den Anbieter sein. Zu Recht.

    > Demgegenüber müssen Hersteller von Hardware mit Linux-basierter Firmware
    > oder Programmierer von installierter Software mit GPL-lizensierten
    > Komponenten ihre Firmware/Software offen legen - allein weil der Nachweis
    > einer Lizenzverletzung ungleich einfacher ist.

    Tja, Pech. Manche Betrüger fallen halt schneller auf als andere.

    > Diese Unterscheidung ist nicht nur unfair -

    Viele Mörder bleiben unerkannt. Wie bitter unfair für jene, die gefaßt und
    verurteilt werden ... mir kommen die Tränen.

    > vor allem zeigt es, wie die GPL aus der Zeit gefallen ist.

    SaaS ist genau was die GPL eben *NICHT* will. Der User soll die Hoheit über seine
    Datenverarbeitung haben. Genau deshalb engagieren sich GNU, FSF, etc, stark
    gegen den ganzen SaaS-Wahnsinn.

    > Der Gedanke der Offenlegung des Quelltextes ergibt im Zeitalter von
    > Cloud-basierten Diensten immer weniger Sinn.

    Doch, jetzt umso mehr.


    --mtx

  10. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: metux 18.10.18 - 19:15

    > Die Schwierigkeit liegt im Risiko des Betreibers. Wenn er nun also kein
    > Geld für Software Zahlen muss,dann ist es auch klar das er kein Geld
    > verlangen kann und darf beim Kunden.

    Man darf sogar Geld verlangen (machen die kommerziellen Distro ja).
    Muß aber trotzdem den Sourcecode kostenlos zur Verfügung stellen.

    > Es reicht im allgemeinen aus die Ansprech-Adressen der Hardware
    > korrekt aufzulisten und eine entsprechende Dokumentation dazu mitzugeben.
    > die meisten Hersteller scheuen aber die Kosten die dabei entstehen.

    Die Kosten wären garnicht so hoch. Genau genommen fällt das bei halbwegs
    professioneller Entwicklung von selbst ab. Problem ist nur, daß die meisten
    Hardware-Hersteller (auch die sehr teuren, wie zB. in der Bahntechnik) alles
    andere als professionell sind und oft nichtmal selbst brauchbare Specs haben.

    Genau das erlebe ich regelmäßig bei meinen Kunden. Besonders bei Embedded.
    (ja, dort wo's wirklich auf Korrektheit, Robustheit und langfristige Wartung ankommt)

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. M-net Telekommunikations GmbH, München
  2. McService GmbH, München
  3. KÖNIGSTEINER AGENTUR GmbH, Stuttgart
  4. TUI InfoTec GmbH, Hannover

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 55€ + 1,99€ Versand
  2. 55€ + 1,99€ Versand
  3. (aktuell u. a. QPAD DX-5 Maus 9,99€, NZXT Kraken X62 AM4 ready, Wasserkühlung 139,90€)
  4. 5€ inkl. FSK-18-Versand


Haben wir etwas übersehen?

E-Mail an news@golem.de


Datenleak: Die Fehler, die 0rbit überführten
Datenleak
Die Fehler, die 0rbit überführten

Er ließ sich bei einem Hack erwischen, vermischte seine Pseudonyme und redete zu viel - Johannes S. hinterließ viele Spuren. Trotzdem brauchte die Polizei offenbar einen Hinweisgeber, um ihn als mutmaßlichen Täter im Politiker-Hack zu überführen.

  1. Datenleak Bundestagsabgeordnete sind Zwei-Faktor-Muffel
  2. Datenleak Telekom und Politiker wollen härtere Strafen für Hacker
  3. Datenleak BSI soll Frühwarnsystem für Hackerangriffe aufbauen

Elektroauto: Eine Branche vor der Zerreißprobe
Elektroauto
Eine Branche vor der Zerreißprobe

2019 wird ein spannendes Jahr für die Elektromobilität. Politik und Autoindustrie stehen in diesem Jahr vor Entwicklungen, die über die Zukunft bestimmen. Doch noch ist die Richtung unklar.
Eine Analyse von Dirk Kunde

  1. Softwarefehler Lime-Tretroller werfen Fahrer ab
  2. Hyundai Das Elektroauto soll automatisiert parken und laden
  3. Kalifornien Ab 2029 müssen Stadtbusse elektrisch fahren

IT-Sicherheit: 12 Lehren aus dem Politiker-Hack
IT-Sicherheit
12 Lehren aus dem Politiker-Hack

Ein polizeibekanntes Skriptkiddie hat offenbar jahrelang unbemerkt Politiker und Prominente ausspähen können und deren Daten veröffentlicht. Welche Konsequenzen sollten für die Sicherheit von Daten aus dem Datenleak gezogen werden?
Eine Analyse von Friedhelm Greis

  1. Datenleak Ermittler nehmen Verdächtigen fest
  2. Datenleak Politiker fordern Pflicht für Zwei-Faktor-Authentifizierung
  3. Politiker-Hack Wohnung in Heilbronn durchsucht

  1. Graswang: Ein Dorf in Bayern will keinen Mobilfunkmast
    Graswang
    Ein Dorf in Bayern will keinen Mobilfunkmast

    Zuerst hatten die Bürger sich über die schlechte Mobilfunkversorgung beschwert. Nun will die Telekom bauen, doch die Mehrheit in Graswang will das nicht.

  2. ProArt PA90: Asus' Zylinder fährt den Deckel aus
    ProArt PA90
    Asus' Zylinder fährt den Deckel aus

    Der ProArt PA90 ist eine tonnenförmige Workstation mit Hexacore-CPU und Quadro-Grafikkarte. Asus kühlt einen Teil der Komponenten per Wasser, den anderen per Luft - und oben hebt sich die Kappe an.

  3. Magenta Zuhause Surf: Telekom stellt Internet ohne Telefonie wieder ein
    Magenta Zuhause Surf
    Telekom stellt Internet ohne Telefonie wieder ein

    Ein spezieller Tarif für DSL ohne Telefonie soll abgeschafft werden. Bereits ab Februar soll es das Angebot für junge Leute von der Deutschen Telekom nicht mehr geben.


  1. 19:23

  2. 19:11

  3. 18:39

  4. 18:27

  5. 17:43

  6. 16:51

  7. 16:37

  8. 15:57