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. FRISTO GETRÄNKEMARKT GmbH, Buchloe
  2. Flughafen Hamburg GmbH, Hamburg
  3. Dr. August Oetker Nahrungsmittel KG, Bielefeld
  4. Ingolstädter Kommunalbetriebe AöR, Ingolstadt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 32,25€ (5% Extra-Rabatt mit Gutschein GRCCIVGS (Uplay-Aktivierung))
  2. 32,99€
  3. 39,95€
  4. für 2€ (nur für Neukunden)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Magnetfeld: Wenn der Nordpol wandern geht
Magnetfeld
Wenn der Nordpol wandern geht

Das Erdmagnetfeld macht nicht das, was Geoforscher erwartet hatten - Nachjustierungen am irdischen Magnetmodell sind erforderlich.
Ein Bericht von Dirk Eidemüller

  1. Emotionen erkennen Ein Lächeln macht noch keinen Frohsinn
  2. Ökostrom Wie Norddeutschland die Energiewende vormacht
  3. Computational Periscopy Forscher sehen mit einfacher Digitalkamera um die Ecke

Enterprise Resource Planning: Drei Gründe für das Scheitern von SAP-Projekten
Enterprise Resource Planning
Drei Gründe für das Scheitern von SAP-Projekten

Projekte mit der Software von SAP? Da verdrehen viele IT-Experten die Augen. Prominente Beispiele von Lidl und Haribo aus dem vergangenen Jahr scheinen diese These zu bestätigen: Gerade SAP-Projekte laufen selten in time, in budget und in quality. Dafür gibt es Gründe - und Gegenmaßnahmen.
Von Markus Kammermeier


    Radeon VII im Test: Die Grafikkarte für Videospeicher-Liebhaber
    Radeon VII im Test
    Die Grafikkarte für Videospeicher-Liebhaber

    Höherer Preis, ähnliche Performance und doppelt so viel Videospeicher wie die Geforce RTX 2080: AMDs Radeon VII ist eine primär technisch spannende Grafikkarte. Bei Energie-Effizienz und Lautheit bleibt sie chancenlos, die 16 GByte Videospeicher sind eher ein Nischen-Bonus.
    Ein Test von Marc Sauter und Sebastian Grüner

    1. Grafikkarte UEFI-Firmware lässt Radeon VII schneller booten
    2. AMD Radeon VII tritt mit PCIe Gen3 und geringer DP-Rate an
    3. Radeon Instinct MI60 AMD hat erste Grafikkarte mit 7 nm und PCIe 4.0

    1. 5G: Großbritannien entscheidet sich gegen Huawei-Verbot
      5G
      Großbritannien entscheidet sich gegen Huawei-Verbot

      In Großbritannien wird es kein Verbot von Huawei geben. Das Mitglied des Five-Eyes-Geheimdienstpaktes konnte von der NSA nicht überzeugt werden, sondern bleibt laut MI5 "souverän".

    2. Niantic: Maßnahmen gegen Massenaufläufe bei Pokémon Go beschlossen
      Niantic
      Maßnahmen gegen Massenaufläufe bei Pokémon Go beschlossen

      Eigenheimbesitzer haben ein Recht auf 40 Meter Abstand zum nächsten Pokéstop, ab zehn Trainern am gleichen Ort blendet die App einen Hinweis ein. Niantic hat einer Reihe von Maßnahmen bei AR-Games zugestimmt, die wegweisend für die Branche sein dürften.

    3. Security: Wireguard-VPN für MacOS erschienen
      Security
      Wireguard-VPN für MacOS erschienen

      Die freie VPN-Technik Wireguard steht nun auch für Apples Desktop-System MacOS bereit. Der Code basiert zu großen Teilen auf der iOS-App. Das Team hatte bei der Entwicklung Probleme mit den Regularien des Mac-App-Stores.


    1. 11:11

    2. 10:57

    3. 10:23

    4. 10:07

    5. 09:00

    6. 08:29

    7. 07:48

    8. 07:35