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. State Street Bank International GmbH, München
  2. Bosch-Gruppe, Salzgitter
  3. netvico GmbH, Stuttgart
  4. comemso GmbH, Ostfildern bei Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. auf ausgewählte Corsair-Netzteile
  2. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Stromversorgung: Das Märchen vom Blackout durch Elektroautos
Stromversorgung
Das Märchen vom Blackout durch Elektroautos

Die massenhafte Verbreitung von Elektroautos stellt das Stromnetz vor neue Herausforderungen. Doch verschiedenen Untersuchungen zufolge sind diese längst nicht so gravierend, wie von Kritikern befürchtet.
Ein Bericht von Friedhelm Greis

  1. Ladekabel Startup Ubitricity gewinnt Klimaschutzpreis in New York
  2. TU Graz Der Roboter als E-Tankwart
  3. WLTP VW kann Elektro- und Hybridautos 2018 nicht mehr verkaufen

Disenchantment angeschaut: Fantasy-Kurzweil vom Simpsons-Schöpfer
Disenchantment angeschaut
Fantasy-Kurzweil vom Simpsons-Schöpfer

Mit den Simpsons ist er selbst Kult geworden, und Nachfolger Futurama hat nicht nur Sci-Fi-Nerds mit einem Auge für verschlüsselte Gags im Bildhintergrund begeistert. Bei Netflix folgt nun Matt Groenings Cartoonserie Disenchantment, die uns trotz liebenswerter Hauptfiguren in Märchenkulissen allerdings nicht ganz zu verzaubern weiß.
Eine Rezension von Daniel Pook

  1. Promotion Netflix testet Werbung zwischen Serienepisoden
  2. Streaming Wachstum beim Pay-TV dank Netflix und Amazon
  3. Videostreaming Netflix soll am Fernseher übersichtlicher werden

HDR-Capture im Test: High-End-Streaming von der Couch aus
HDR-Capture im Test
High-End-Streaming von der Couch aus

Was bringen all die schönen neuen Farben auf dem 4K-HDR-TV, wenn man sie nicht speichern kann oder während des Livestreams nicht mehr selber sieht? Avermedia bietet mit den Capture-Karten Live Gamer 4K und Live Gamer Ultra erstmals bezahlbare Lösungen an. PC-Spieler sehen mit ihnen sogar bis zu 240 Bilder pro Sekunde.
Von Michael Wieczorek

  1. DisplayHDR Vesa veröffentlicht erstes Testwerkzeug für HDR-Standard
  2. HDMI 2.0 und Displayport HDR bleibt Handarbeit
  3. Intel Linux bekommt experimentelle HDR-Unterstützung

  1. Anno 1800 angespielt: Von Kartoffelbauern, Großkapitalisten und rosa Delfinen
    Anno 1800 angespielt
    Von Kartoffelbauern, Großkapitalisten und rosa Delfinen

    Gamescom 2018 Wir bauen eine Klassengesellschaft: In Anno 1800 müssen wir auf die Zusammensetzung der Gesellschaft achten - was gar nicht so einfach ist, wie Golem.de beim Anspielen des Aufbauspiels festgestellt hat. Als Ausgleich gibt es eine neue, ebenso gelungene wie simple Komfortfunktion.

  2. Flensburg: IBM-Standort in Deutschland bleibt
    Flensburg
    IBM-Standort in Deutschland bleibt

    Ein früherer Service Desk der Lufthansa ist nicht mehr von der Schließung bedroht. IBM Watson soll den Standort IBM AIWS aufwerten, Leiharbeiter sollen fest eingestellt werden.

  3. Charge 3: Fitbit stellt neuen Fitness-Tracker für 150 Euro vor
    Charge 3
    Fitbit stellt neuen Fitness-Tracker für 150 Euro vor

    Fitbit hat seinem neuen Fitness-Wearable Charge 3 ein neues Design verpasst. Außerdem soll der Bildschirm heller und schärfer als bei den Vorgängern sein. Der Akku soll sieben Tage lang durchhalten - bei GPS-Nutzung dürfte dieser Wert aber sinken.


  1. 18:10

  2. 17:47

  3. 17:10

  4. 16:55

  5. 15:55

  6. 13:45

  7. 13:30

  8. 13:00