Abo
  1. Foren
  2. Kommentare
  3. Politik/Recht
  4. Alle Kommentare zum Artikel
  5. › Oracle vs. Google: Dieses Urteil…

Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


  1. Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: JarJarThomas 10.04.18 - 12:14

    Ich verstehe viele Argumente des Authors und kann denen grundsätzlich zustimmen.

    Aber die Lösung kann nicht sein API's dann vollkommen frei zu halten.
    API's sind aus mehreren Gründen schützenswert.

    Zum einen ist natürlich eine gute API die man entwickelt ein wettbewerbsvorteil.
    Hat man die bessere API dann hat man das bessere Produkt.
    Klar ein anderer kann sein Produkt NICHT an meine API anpassen ohne dass ich es ihm erlaube, aber warum sollte er das Recht haben meine teuer entwickelte API nachzubauen ?

    Zum anderen natürlich ist eine API nicht nur ein Alleinstellungsmerkmal sondern natürlich auch ein Produktfeature.
    Wenn Produkt X das Feature Y entwickelt, sprich zb. ein Cad hersteller eine bessere, schnellere und genauere Lösung zur Simulation von Stress und Erwärmung, dann ist das genauso ein schützenswertes Feature wie wenn er eine API bereitstellt mit der er zb dieses Feature automatisieren kann.

    Das RECHT wie die API genutzt wird, hat der Entwickler der API.
    Genauso wie er das Recht hat zu bestimmen wie der ordnungsgemäße Einsatz seiner Software ist. Dies geschieht über Lizenzen die erteilt werden.

    Wenn der Entwickler denkt "es macht Sinn meine Lizenz zu öffnen" dann kann er das gerne tun.
    Aber wenn er für die API, da sie der Hauptaufwand der Entwicklung ist wie zb. bei Java, keine kostenfreie Lizenz zur Verfügung stellen will, so ist das sein gutes Recht.

    Daher nein.
    Das Gericht hat hier vollkommen Recht.
    APIs sind schützenswert, genau wie Software einen Uhrheberrechtsschutz hat und die Tatsache dass man sich selbst Geld und Aufwand sparen würde wenn man eine bestehende API kopiert ändert nichts an der Tatsache.



    1 mal bearbeitet, zuletzt am 10.04.18 12:21 durch JarJarThomas.

  2. Re: Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: Nikolai 10.04.18 - 12:24

    > Zum einen ist natürlich eine gute API die man entwickelt ein
    > wettbewerbsvorteil.
    > Hat man die bessere API dann hat man das bessere Produkt.
    > Klar ein anderer kann sein Produkt NICHT an meine API anpassen ohne dass
    > ich es ihm erlaube, aber warum sollte er das Recht haben meine teuer
    > entwickelte API nachzubauen ?

    Eine API ist aber nur ein Interface. Es geht _NICHT_ um den Code.

  3. Über was reden wir hier?

    Autor: Marentis 10.04.18 - 12:25

    Nur das USA-Recht? Oder soll das eher eine allgemeingültige Aussage sein? Meines Wissens sind Schnittstellen im deutschen Urheberrecht zum Beispiel nicht schützenswert und so wie es sich im Artikel liest, auch nicht im Rest der EU.

  4. Re: Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: JarJarThomas 10.04.18 - 12:29

    Nikolai schrieb:
    --------------------------------------------------------------------------------
    > > Zum einen ist natürlich eine gute API die man entwickelt ein
    > > wettbewerbsvorteil.
    > > Hat man die bessere API dann hat man das bessere Produkt.
    > > Klar ein anderer kann sein Produkt NICHT an meine API anpassen ohne dass
    > > ich es ihm erlaube, aber warum sollte er das Recht haben meine teuer
    > > entwickelte API nachzubauen ?
    >
    > Eine API ist aber nur ein Interface. Es geht _NICHT_ um den Code.

    Natürlich ist sie nur ein Interface. Aber auch das Interface ist aufwand und schützenswert.
    Nein es geht mir hier NICHT um Verfahren "eine funktion um die Anzahl von Elementen abzufragen und eine um das ite Element zu bekommen"
    sondern um eine wortwörtliche syntaktisch 1:1 Kopie.

    Wie man auf die Idee kommen kann das das NICHT schützenswert ist kann ich mir nicht mal im Ansatz vorstellen (abgesehen eben von es passt für mich dass ich den Aufwand nicht machen muss).

    Ich verstehe wie gesagt Interoperabilität usw.
    Aber wenn eine API nicht 1:1 nachgebaut werden darf weil der Entwickler der API das nicht erlaubt, dann ist das so. Dann kann man gerne selbst Aufwand investieren in eine offene API die jeder nachbauen darf.

  5. Re: Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: wasdeeh 10.04.18 - 12:31

    > APIs sind schützenswert, genau wie Software einen Uhrheberrechtsschutz hat

    Jo eh. Schaun ma mal, was der EUGH sagt:
    https://curia.europa.eu/jcms/upload/docs/application/pdf/2012-05/cp120053de.pdf

    Programmiersprachen und Dateiformate sind schon mal *nicht* schützenswert. Warum?

    "Ließe man nämlich zu, dass die Funktionalität eines Computerprogramms urheberrechtlich
    geschützt wird, würde man zum Schaden des technischen Fortschritts und der industriellen
    Entwicklung die Möglichkeit eröffnen, Ideen zu monopolisieren."

    Würd ich 1:1 auch so für APIs unterschreiben.

    (Zur Klarstellung: Schützen kann man nur die *Implementierung*, nicht die *Funktionalität*)

  6. Re: Über was reden wir hier?

    Autor: JarJarThomas 10.04.18 - 12:31

    Nach deutschem Recht sind APIs Sourcecode und damit uhrheberrechtlich geschützt.

    Nebenbei ist es ein Unterschied ob ich eine Applikation oder ein System habe dass eine API anbietet um es zu steuern oder eine Programmiersprache die zu 90% aus API besteht und das kopiere wie auch noch in diesem Fall.

  7. Re: Über was reden wir hier?

    Autor: Marentis 10.04.18 - 12:32

    JarJarThomas schrieb:
    --------------------------------------------------------------------------------
    > Nach deutschem Recht sind APIs Sourcecode und damit uhrheberrechtlich
    > geschützt.
    >
    Dann hast Du ja sicher irgendwo eine Quelle griffbereit. Dem Gesetzestext kann ich das jedenfalls nicht entnehmen, da scheint sich nichts geändert zu haben.

    Ps: kann es sein, dass wir aneinander vorbeireden? Afaik darf ich tatsächlich nicht einfach fremde Schnittstellen offen legen (z.B. header oder so einfach veröffentlichen, je nach Lizenz). Der Urheber ist aber nicht vor kompatiblen Nachbauten geschützt.



    4 mal bearbeitet, zuletzt am 10.04.18 12:40 durch Marentis.

  8. Re: Über was reden wir hier?

    Autor: somedudeatwork 10.04.18 - 12:33

    >Nach deutschem Recht sind APIs Sourcecode und damit uhrheberrechtlich geschützt.
    Quelle.

  9. Re: Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: a user 10.04.18 - 12:46

    Nikolai schrieb:
    --------------------------------------------------------------------------------
    > > Zum einen ist natürlich eine gute API die man entwickelt ein
    > > wettbewerbsvorteil.
    > > Hat man die bessere API dann hat man das bessere Produkt.
    > > Klar ein anderer kann sein Produkt NICHT an meine API anpassen ohne dass
    > > ich es ihm erlaube, aber warum sollte er das Recht haben meine teuer
    > > entwickelte API nachzubauen ?
    >
    > Eine API ist aber nur ein Interface. Es geht _NICHT_ um den Code.

    Bei der Frage von Urheberrecht ist das vollkommen irrelevant. Das der Author das immer wieder und als eines von zwei Argumenten anbringt, macht es nicht richtiger.

    Der Golemartikel argumentiert mit zwei, meiner Meinung nach vollkommen absurden Argumenten:
    1. API =/= Code Was tut das bei Urheberrecht zur Sache? Bei Patentrecht spielt das eine Rolle, aber beim Urheberrecht?
    2. Es ist allgemein bisher so gehandhabt worden, dass APIs nachgebaut wurden. So what? Nur weil bisher keiner dies per Klage in Frage gestellt hat und deswegen bisher so gemacht wurde ist es noch lange nicht rechtens.

    Ich finde das nicht gut, aber ich kann die Argumentation des Gerichts nachvollziehen und sehe im Golemartikel KEIN Gegenargument, nur "aber so haben wir das doch immer gemacht" und "Interface ist doch kein Code". Das sind keine Argumente.

  10. Re: Über was reden wir hier?

    Autor: a user 10.04.18 - 12:49

    somedudeatwork schrieb:
    --------------------------------------------------------------------------------
    > >Nach deutschem Recht sind APIs Sourcecode und damit uhrheberrechtlich
    > geschützt.
    > Quelle.
    Diese Frage macht keinen Sinn. Es bedarf einer Quelle, die APIs als Ausnahme von der Regel bestätigt.
    Das Urheberrecht definiert nicht alles wie eine Whitelist. Es gibt Urteile, die bestätigen, das Software davon betroffen ist und solange es kein Urteil gibt, dass APIs davon ausnimmt, gilt es erst einmal dafür.

    Also bring du erst einmal eine Quelle, die APIs davon ausnimmt.

  11. Re: Über was reden wir hier?

    Autor: Astorek 10.04.18 - 12:55

    JarJarThomas schrieb:
    --------------------------------------------------------------------------------
    > Nach deutschem Recht sind APIs Sourcecode und damit uhrheberrechtlich geschützt.
    Hast du eine Quelle zur Hand? Soweit ich weiß, ist in DE alles schützenswert, was über genügend "geistige Schöpfungshöhe" verfügt. Was genau darunter verstanden wird, ist zwar Auslegungssache, simple "Hallo Welt"-Programme und sehr wahrscheinlich auch das bloße Übernehmen von Interfaces werden davon jedoch nicht betroffen sein.

    (Alles IMHO)

  12. Re: Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: a user 10.04.18 - 12:56

    wasdeeh schrieb:
    --------------------------------------------------------------------------------
    > > APIs sind schützenswert, genau wie Software einen Uhrheberrechtsschutz
    > hat
    >
    > Jo eh. Schaun ma mal, was der EUGH sagt:
    > curia.europa.eu
    >
    > Programmiersprachen und Dateiformate sind schon mal *nicht* schützenswert.
    > Warum?
    >
    > "Ließe man nämlich zu, dass die Funktionalität eines Computerprogramms
    > urheberrechtlich
    > geschützt wird, würde man zum Schaden des technischen Fortschritts und der
    > industriellen
    > Entwicklung die Möglichkeit eröffnen, Ideen zu monopolisieren."
    Hierbei geht es um die Funktion. Der Ausdruck selbst ist aber Urheberrechtlich geschützt und der Ausdruck ist der konkrete Text, der Quellcode.
    >
    > Würd ich 1:1 auch so für APIs unterschreiben.
    Das wäre sehr gewagt.
    >
    > (Zur Klarstellung: Schützen kann man nur die *Implementierung*, nicht die
    > *Funktionalität*)
    Nein, der Text/Code und die API besteht nur aus diesem, aus Text ohne eine Funktion.

    Ich will nicht behaupten, dass ich mit meiner Interpretation 100% richtig liege, aber so einfach wie du dir das aus dem Urteil reimst ist es auch wieder nicht. Klar ist da nichts.

  13. Re: Über was reden wir hier?

    Autor: a user 10.04.18 - 12:57

    Astorek schrieb:
    --------------------------------------------------------------------------------
    > JarJarThomas schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Nach deutschem Recht sind APIs Sourcecode und damit uhrheberrechtlich
    > geschützt.
    > Hast du eine Quelle zur Hand? Soweit ich weiß, ist in DE alles
    > schützenswert, was über genügend "geistige Schöpfungshöhe" verfügt. Was
    > genau darunter verstanden wird, ist zwar Auslegungssache, simple "Hallo
    > Welt"-Programme und sehr wahrscheinlich auch das bloße Übernehmen von
    > Interfaces werden davon jedoch nicht betroffen sein.
    Hast du dafür eine Quelle? Solange es nicht ausgenommen worden ist durch ein Urteil ist es nicht ausgenommen. Das Gesetz stellt hier keine White-List dar!

  14. Re: Über was reden wir hier?

    Autor: somedudeatwork 10.04.18 - 12:58

    Er hat die Aussage gemacht, er muss sie belegen. Alles andere interessiert mich nicht.

  15. Re: Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: elgooG 10.04.18 - 13:00

    Danke!

    Ich denke, dass hier einige nicht die Auswirkungen begreifen. Eine API urheberrechtlich zu schützen wäre absolut fatal. Eine API exakt nachbauen zu können ist absolut essentiel um Software untereinander kompatibel machen zu können. Entstünde hier eine rechtliche Unsicherheit, wären die Konsequenzen gar nicht abzusehen. Es gibt unzählige Uraltsysteme die auf diesem Wege weiterverwendet und mit neuen Technologien verbunden wurden.

    Ich erinnere hier nur an Microsoft, dass von der EU gezwungen wurde unzählge APIs und Protokolle freizugeben um der Konkurrenz Zugang zu gewähren. Inzwischen arbeiten die selber bei neuen Produkten sehr stark mit offenen APIs, die sich nachbauen liesen und setzen wiederum stark auf Produkte die Fremd-APIs emulieren. Man betrachte hier nur ein .NET, insbesondere ASP.NET Core, dass dadurch zu unzähligen Fremd-Frameworks kompatibel ist.

    wasdeeh schrieb:
    --------------------------------------------------------------------------------
    > (Zur Klarstellung: Schützen kann man nur die *Implementierung*, nicht die
    > *Funktionalität*)
    Es sollte wohl heißen nicht dessen *Deklaration*. Eine API bietet nun mal keinerlei Funktionalität.

    Kann Spuren von persönlichen Meinungen, Sarkasmus und Erdnüssen enthalten. Ausdrucke nicht für den Verzehr geeignet. Ungelesen mindestens haltbar bis: siehe Rückseite

  16. Re: Über was reden wir hier?

    Autor: Astorek 10.04.18 - 13:21

    Ich weiß nicht wo es die "offiziellen" Quellen gibt, aber es reicht eigentlich, Google nach "Software Schöpfungshöhe" zu befragen, um z.T. aus Anwalt- und Gerichts-Webseiten entsprechende Ausarbeitungen zu finden.

    Beispiel:
    http://kanzlei-lachenmann.de/software-urheberrechte-schutzumfang/

    Den Satz über "Hallo Welt"-Programme habe ich so von einer recht alten c't-Ausgabe übernommen...

  17. Re: Über was reden wir hier?

    Autor: a user 10.04.18 - 13:23

    somedudeatwork schrieb:
    --------------------------------------------------------------------------------
    > Er hat die Aussage gemacht, er muss sie belegen. Alles andere interessiert
    > mich nicht.
    Die Aussage ist dann schon durch das Gesetz belegt. Denn solange keine Ausnahme gerichtlich entschieden wurde gilt es auch für APIs. Ich wiederhole: das Gesetz ist keine White-List. Also kannst du auch keine weitere Quelle dafür verlangen.

    Das solltest du doch verstehen können.

  18. Re: Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: a user 10.04.18 - 13:24

    Das das schlimm ist steht hier eigentlich nicht zur Debatte und sehe ich genau so. Hier steht aber die Auswirkung des Urheberrechts zur Debatte.

  19. Re: Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: Allandor 10.04.18 - 13:27

    elgooG schrieb:
    --------------------------------------------------------------------------------
    > Danke!
    >
    > Ich denke, dass hier einige nicht die Auswirkungen begreifen. Eine API
    > urheberrechtlich zu schützen wäre absolut fatal. Eine API exakt nachbauen
    > zu können ist absolut essentiel um Software untereinander kompatibel machen
    > zu können. Entstünde hier eine rechtliche Unsicherheit, wären die
    > Konsequenzen gar nicht abzusehen. Es gibt unzählige Uraltsysteme die auf
    > diesem Wege weiterverwendet und mit neuen Technologien verbunden wurden.
    >
    > Ich erinnere hier nur an Microsoft, dass von der EU gezwungen wurde
    > unzählge APIs und Protokolle freizugeben um der Konkurrenz Zugang zu
    > gewähren. Inzwischen arbeiten die selber bei neuen Produkten sehr stark mit
    > offenen APIs, die sich nachbauen liesen und setzen wiederum stark auf
    > Produkte die Fremd-APIs emulieren. Man betrachte hier nur ein .NET,
    > insbesondere ASP.NET Core, dass dadurch zu unzähligen Fremd-Frameworks
    > kompatibel ist.
    >
    > wasdeeh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > (Zur Klarstellung: Schützen kann man nur die *Implementierung*, nicht
    > die
    > > *Funktionalität*)
    > Es sollte wohl heißen nicht dessen *Deklaration*. Eine API bietet nun mal
    > keinerlei Funktionalität.

    Das zu tun oder nicht, liegt aber weiterhin beim Urheber (den Oracle nunmal gekauft hat). Es hätte wohl kein Richter darüber gemeckert wenn jetzt ein paar API Funktionen übernommen worden wären, aber hier wurde sehr viel übernommen um etwas nachzubilden.
    Wenn der Urheber damit nicht einverstanden ist (bzw. es gibt ja die Möglichkeit per OpenJDK) dann ist das Googles problem.

    Aber ich will es mal so sagen, spätestens als Oracle Java (bzw. Sun) übernommen hat ist das eigentliche Java an sich tot. Oracle hatte von Anfang an vor an Java selbst zu verdienen. Ich kann verstehen warum Google sich damals an Java orientiert hat und es nachimplementiert hat, aber sie hätten lieber etwas machen sollen was nur ähnlich ist und z.B. mittels compiler Java-Code interpretieren und übersetzen sollen. Dann hätten sie das Problem jetzt nicht.

    Btw, im Handwerk kennen kämpfen wir doch ständig mit Schnittstellen die irgendwie genormt und Patentiert sind. Warum sollte das hier nun anders sein?
    Egal ob es irgendein Rohr/Brett, ... ist das auf irgendeine Art & Weise gebogen oder verziert ist oder etwas in der Richtung, das es genau passt. Ruck zuck ist sowas patentiert.



    1 mal bearbeitet, zuletzt am 10.04.18 13:29 durch Allandor.

  20. Re: Ich stimme dem Autor nicht zu. Auch APIs sind Uhrhebergeschützt

    Autor: twothe 10.04.18 - 13:27

    Als jemand der beruflich seit Jahren APIs entwickelt kann ich dem nur teilweise zustimmen.

    Eine API die sehr gut gemacht ist hat viel Zeit (und damit Geld) gekostet. Oft stecken dann sehr tiefgreifende Überlegungen darin um dem Nutzer der API dies möglichst einfach zu machen, während gleichzeitig evtl. weitere Interessen wie Sicherheit, Performance, Kompatibilität, o.Ä. gewahrt bleiben. So was fällt nicht vom Himmel sondern ist das Ergebnis sehr langer und guter Arbeit und sollte demnach eigentlich geschützt sein. Es wäre dann unfair, wenn einer der Großen Player sich dann denkt "Hey, das is ja schon fertig", dann die geleistete Arbeit "klaut" und in Geld umwandelt, ohne das der eigentliche Autor was davon abbekommt.

    Andererseits ist eine API die sehr gut ist bestens geeignet um ein Standard zu sein und sollte demnach frei verfügbar sein, denn ansonsten wären ja andere Hersteller gezwungen eine schlechtere Anbindung anzubieten um evtl. rechtliche Konsequenzen zu vermeiden. Anders ausgedrückt: es ist im Interesse aller, wenn APIs kopiert und ggf. im Detail verbessert werden dürfen.

    Ich würde im Allgemeinen dafür stimmen, das APIs kopiert werden dürfen, aber eine kleine/faire Urheberrechtsabgabe verlangt werden darf, damit sich die rein gesteckte Arbeit auch lohnt.

  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Dataport, Altenholz bei Kiel, Hamburg
  2. AKKA GmbH & Co. KGaA, München
  3. Versicherungskammer Bayern, Saarbrücken
  4. 10X Innovation GmbH & Co. KG, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,99€
  2. 32,99€
  3. 53,99€ statt 69,99€
  4. 54,99€ mit Vorbesteller-Preisgarantie (Release 05.10.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Pixel 3 XL im Test: Algorithmen können nicht alles
Pixel 3 XL im Test
Algorithmen können nicht alles

Google setzt beim Pixel 3 XL alles auf die Kamera, die dank neuer Algorithmen nicht nur automatisch blinzlerfreie Bilder ermitteln, sondern auch einen besonders scharfen Digitalzoom haben soll. Im Test haben wir allerdings festgestellt, dass auch die beste Software keine Dual- oder Dreifachkamera ersetzen kann.
Ein Test von Tobias Költzsch

  1. Dragonfly Google schweigt zu China-Plänen
  2. Nach Milliardenstrafe Google will Android-Verträge offenbar anpassen
  3. Google Android Studio 3.2 unterstützt Android 9 und App Bundles

Künstliche Intelligenz: Wie Computer lernen
Künstliche Intelligenz
Wie Computer lernen

Künstliche Intelligenz, Machine Learning und neuronale Netze zählen zu den wichtigen Buzzwords dieses Jahres. Oft wird der Eindruck vermittelt, dass Computer bald wie Menschen denken können. Allerdings wird bei dem Thema viel durcheinandergeworfen. Wir sortieren.
Von Miroslav Stimac

  1. Innotrans KI-System identifiziert Schwarzfahrer
  2. USA Pentagon fordert KI-Strategie fürs Militär
  3. KI Deepmind-System diagnostiziert Augenkrankheiten

Shine 3: Neuer Tolino-Reader bringt mehr Lesekomfort
Shine 3
Neuer Tolino-Reader bringt mehr Lesekomfort

Die Tolino-Allianz bringt das Nachfolgemodell des Shine 2 HD auf den Markt. Das Shine 3 erhält mehr Ausstattungsdetails aus der E-Book-Reader-Oberklasse. Vor allem beim Lesen macht sich das positiv bemerkbar.
Ein Hands on von Ingo Pakalski

  1. E-Book-Reader Update macht Tolino-Geräte unbrauchbar

  1. Wübben-Stiftung: Hälfte der Lehrer sieht digitale Medien skeptisch
    Wübben-Stiftung
    Hälfte der Lehrer sieht digitale Medien skeptisch

    Kinder und Eltern sind für den Einsatz von IT in den Schulen, 50 Prozent der Lehrer und Schulleiter sind eher dagegen. Sie halten die digitale Bildung im Unterricht für überbewertet.

  2. Palantir in Deutschland: Wo die Polizei alles sieht
    Palantir in Deutschland
    Wo die Polizei alles sieht

    Hessens Polizei arbeitet als erste in Deutschland mit Software des US-Unternehmens Palantir. Das spart Ermittlern enorm viel Zeit und Aufwand. Politiker der Linken und FDP kritisieren die Verbindung von Polizei-Datenbanken.

  3. IMFT: Micron will Intels Flash-Speicher-Geschäft übernehmen
    IMFT
    Micron will Intels Flash-Speicher-Geschäft übernehmen

    Das Joint Venture ist zu Ende: Micron kauft Intels Anteile für 1,5 Milliarden US-Dollar und betreibt die Fabriken dann alleine. Intel produziert künftig ebenfalls selbst, vor allem aber wird 3D Xpoint fortgeführt.


  1. 16:01

  2. 16:00

  3. 15:20

  4. 15:00

  5. 14:09

  6. 13:40

  7. 13:13

  8. 12:58