Abo
  1. Foren
  2. Kommentare
  3. Politik/Recht
  4. Alle Kommentare zum Artikel
  5. › Scott McNealy: "Ohne Copyright…

Kann mir einer das Problem einfach erklären? Ich versteh' es nicht...

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Kann mir einer das Problem einfach erklären? Ich versteh' es nicht...

    Autor: berritorre 28.02.13 - 22:10

    Wir haben eine offene Programmiersprache.

    Eine verwenden eine eigene API, andere verwenden die Java-eigene API. So, und jetzt? Warum brauchen wir hier Copyright. Ich sehe im Moment kein echtes Problem, aber vermutlich übersehe ich irgendwas.

  2. Das ist nicht so schwer.

    Autor: 486dx4-160 01.03.13 - 01:20

    Sun/Oracle hat Java entwickelt und dabei, wie in Amiland üblich, sich einen Haufen Patente zusprechen lassen.
    Android/Google hat Dalvik entwickelt und sich dabei stark an Java orientiert.
    Oracle sagt, dass Google dabei Java-Patente verletzt habe.

    Scott McNealy (Sun/Oracle) sagt halt jetzt, dass Sun die Java-Entwicklung nicht finanziert hätte wenn sich da jeder bei den Entwicklungsergebnissen bedienen könne.
    Google dagegen sagt dass nur Sachen übernommen worden wären, die keine besondere Erfindungshöhe hätten und daher nicht schützenswert seien.

    Und diesen Streit klärt ein Gericht.
    Verliert Google muss Google eine schöne Stange Geld an Oracle zahlen.

    Dass Java Open Source ist hat mit der Streiterei nichts zu tun. Es geht, wie so oft, um Patente.

  3. Re: Das ist nicht so schwer.

    Autor: thomas001le 01.03.13 - 02:56

    Aber Google hat doch nur die API kopiert und nicht die eigentlichen Implementierungen?
    Worauf will Oracle da Patente anmelden, oder gibt es so tolle Patente wie "A method for passing two arguments instead of three to a method which sets the current time zone"? oO

  4. Re: Das ist nicht so schwer.

    Autor: Astorek 01.03.13 - 08:03

    thomas001le schrieb:
    --------------------------------------------------------------------------------
    > Aber Google hat doch nur die API kopiert und nicht die eigentlichen
    > Implementierungen?
    > Worauf will Oracle da Patente anmelden, oder gibt es so tolle Patente wie
    > "A method for passing two arguments instead of three to a method which sets
    > the current time zone"? oO

    Wäre nicht gerade unwahrscheinlich. Meines Wissens gibts auch ein gültiges Patent für den Doppelklick, den derzeit Microsoft innehat...

  5. Re: Das ist nicht so schwer.

    Autor: wasdeeh 01.03.13 - 11:19

    486dx4-160 schrieb:
    --------------------------------------------------------------------------------
    > Sun/Oracle hat Java entwickelt und dabei, wie in Amiland üblich, sich einen
    > Haufen Patente zusprechen lassen.
    > Android/Google hat Dalvik entwickelt und sich dabei stark an Java
    > orientiert.
    > Oracle sagt, dass Google dabei Java-Patente verletzt habe.

    In diesem Fall gehts nicht um Patente, sondern ums Copyright. Oracle sagt: Google hat die Java-API kopiert und damit ihr Copyright verletzt.
    Und das ist ja das Perfide an der Klage. Wenn die durchgeht, dann sind (API-kompatible) freie Implementierungen von proprietären Standards schwer gefährdet.

    > Scott McNealy (Sun/Oracle) sagt halt jetzt, dass Sun die Java-Entwicklung
    > nicht finanziert hätte wenn sich da jeder bei den Entwicklungsergebnissen
    > bedienen könne.
    > Google dagegen sagt dass nur Sachen übernommen worden wären, die keine
    > besondere Erfindungshöhe hätten und daher nicht schützenswert seien.



    1 mal bearbeitet, zuletzt am 01.03.13 11:23 durch wasdeeh.

  6. Re: Das ist nicht so schwer.

    Autor: Otto d.O. 01.03.13 - 12:25

    wasdeeh schrieb:
    --------------------------------------------------------------------------------
    > Und das ist ja das Perfide an der Klage. Wenn die durchgeht, dann sind
    > (API-kompatible) freie Implementierungen von proprietären Standards schwer
    > gefährdet.

    Genau, und das ist wohl auch der Grund, warum MS in diesem Fall Oracle unterstützt. Ein durchsetzbares Urheberrecht auf APIs schafft künstliche Monopole, die anders als Patente keine besondere Kosten verursachen, besondere Hürden zu überwinden haben und eine sehr viel längere, dank regelmässigem Lex Disney vermutlich unbeschränkte, Laufzeit aufweisen.

  7. Re: Das ist nicht so schwer.

    Autor: bstea 01.03.13 - 13:41

    Wieso brauchst du zur Implemenation prop. Standard eine komplette API Kompatibilität? Mal von Wine/ReactOS etc. abgesehen, gibts kaum Projekte die das unbedingt benötigen.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  8. Spielt das 'ne Rolle?

    Autor: fratze123 01.03.13 - 13:50

    Hat doch wenig mit dem Thema zu tun, ob man das wirklich braucht.

  9. Re: Spielt das 'ne Rolle?

    Autor: bstea 01.03.13 - 14:02

    Bis auf Unternehmen, die von Investionen und Leistungen anderer profitieren, braucht kaum einer API-Kom., darauf wollte ich hinaus.
    Wenn ich mich recht entsinne, sah damals SUN Geschäftsmodell vor, Lizenzen an Embedded und Handyerzeuger für ihr Java zu verkaufen. Google hat das Geschäftsmodell obsolete gemacht.
    Wundert mich also auch nicht, dass einer der Gegner dieser API-Copyright Auslegung, jener Typ(Schwartz) ist, der den Karren erst richtig in den Sand gesetzt hat mit Fehlinvestionen , Rekordverlust und Großzügigkeit ggü. Google.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  10. Jeder Entwickler freut sich, wenn er nur eine statt 2 APIs lernen muss.

    Autor: fratze123 01.03.13 - 14:05

    und damit auf 2 Plattformen entwickeln kann.

  11. Re: Das ist nicht so schwer.

    Autor: Otto d.O. 01.03.13 - 14:26

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Wieso brauchst du zur Implemenation prop. Standard eine komplette API
    > Kompatibilität? Mal von Wine/ReactOS etc. abgesehen, gibts kaum Projekte
    > die das unbedingt benötigen.

    Selbst wenn man "Wine/ReactOS etc." als nicht verteidigungswürdig ansieht, sollte man trotzdem nicht außer Acht lassen, dass das, was für die API in Sachen Copyright gilt, für Dateiformate, Netzwerkprotokolle u.ä. genauso anwendbar ist. Wenn McNealy heute jammert "wir haben soviel Arbeit in die API" gesteckt, warum sollte nicht Ballmer morgen jammern "das Office-Dateiformat hat uns soviel Zeit gekostet" oder "wir haben so lange am SMB-Netzwerkprotokoll gearbeitet"?

    Ein Copyright auf Schnittstellenspezifikationen ist der Tod der Interoperabilität.

  12. Re: Das ist nicht so schwer.

    Autor: bstea 01.03.13 - 14:31

    Nö, das Format ist spezifiziert, du kannst gerne eine eigene API ausdenken aber eben nicht eine klauen, weil so schneller geht und weitere Vorteile mit sich bringt.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  13. Re: Das ist nicht so schwer.

    Autor: Dadie 01.03.13 - 14:42

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Wieso brauchst du zur Implemenation prop. Standard eine komplette API
    > Kompatibilität? Mal von Wine/ReactOS etc. abgesehen, gibts kaum Projekte
    > die das unbedingt benötigen.

    Mir fällt auf Anhieb noch LibreOffice/OpenOffice ein. Ich kenne leider genug Programme dir irgendwelche API Aufrufe von Microsoft Office nutzen. Wir haben bei uns auf der Arbeit aktuell ein Kooperations-Projekt und müssen dafür "GAMS (General Algebraic Modeling System)" nutzen. Jetzt hat die Partner Universität leider ein Plugin benutzt welches die Microsoft Office 2007 API benutzt.

    Wir hatten also die Wahl uns Office 2007 zu kaufen, mit der Partner Universität eine endlose Diskussion anzufangen wie man das ganze ohne dieses Plugin lösen könnte, oder aber entsprechend die API von Office 2007 nach zu bauen. (Wir entschieden uns neben Office 2010,Office 2013 nun auch Office 2007 auf den Rechnern installiert zu haben),

    Ich weiß hier leider nicht LibreOffice/OpenOffice diese APIs schon nachgebaut haben, noch dabei sind oder ob sie es überhaupt jemals vorhaben. Fakt ist aber dass ein Copyright auf eine API hier große Probleme erzeugen würde.

    Selbst wenn es technisch ginge wäre es dann rechtlich nicht mehr möglich einfach so von Microsoft Office zu z.B. LibreOffice zu wechseln.

  14. Re: Das ist nicht so schwer.

    Autor: wasdeeh 01.03.13 - 16:41

    Ich glaube, du solltest dich nochmal über die Bedeutung des Begriffes "API" informieren.

  15. Re: Das ist nicht so schwer.

    Autor: mag 01.03.13 - 20:11

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Wieso brauchst du zur Implemenation prop. Standard eine komplette API
    > Kompatibilität?

    Die Frage ist einfach zu beantworten: API- bzw. generell Schnittstellenkompatibilät muss eingehalten werden, damit Software, die auf diese Schnittstelle aufsetzt, funktioniert. Wenn du willst, dass ein Button eine Funktion in deiner Software auslöst, musst du die entsprechende Schnittstelle implementieren. Da hast du keine künstlerische Freiheit. Ein Implementierungsverbot aus Copyrightgründen bedeutet: Es wird keine Programme für diese grafische Benutzeroberfläche geben.

    Und APIs sind sehr wohl dazu gedacht, von Dritten implementiert zu werden. Nehmen wir die Java Persistence API. Die ist völlig unabhängig von einer Implementierung spezifiziert. Du als Entwickler kannst dich aber nun entscheiden, ob du EclipseLink, TopLink oder Hibernate benutzt, weil du weißt, dass alle dieselbe API implementieren. Wenn deine erste Wahl sich als Mist herausstellt kannst du ohne größere Probleme auf eine andere Implementierung wechseln. Das ist der Sinn von APIs. Dürfte diese API aus Copyrightgründen nicht implementiert werden, wäre sie völlig wertlos.

    Nehmen wir die Preferences API aus Oracles eigenem Fundus. Da gibt es zwar eine Defaultimplementierung von Oracle, allerdings war denen bei der Entwicklung sehr wohl klar, dass die für viele Anwendungsfälle nicht ausreichen wird. Darum dreht sich ein großer Teil der Dokumentation darum, was Drittanbieter beachten müssen, wenn sie diese API selbst implementieren. Wirklich vertane Müh, wenn eine solche Implementierung aus Copyrightgründen gar nicht zulässig wäre.

    Bei anderen Teilen seiner API ist Oracle aber plötzlich der Meinung, hier sei eine eigene Implementierung nicht erlaubt. Da frage ich mich als Entwickler, wo ist denn da die Grenze? In der API-Dokumentation jedenfalls steht nirgendwo, dass Oracle eine eigene Implementierung untersagt, genausowenig wie irgendwo steht, dass Oracle hier eine eigene Implementierung gestattet.

  16. Re: Das ist nicht so schwer.

    Autor: bstea 01.03.13 - 20:45

    Um's kurz zu machen: Es geht um die API, nicht um die Implementierung der Schnittstellen. Im Artikel steht eigentlich klar und deutlich, dass das Design der Klassenhierachie durch Copyright geschützt sein sollte.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  17. Re: Das ist nicht so schwer.

    Autor: mag 01.03.13 - 21:03

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Um's kurz zu machen: Es geht um die API, nicht um die Implementierung der
    > Schnittstellen.

    Genau, dass eine Implementierung geschützt ist und auch sein sollte, das ficht ja niemand an. Aber APIs davor zu schützen, implementiert zu werden, widerspricht ihrem Zweck.

    > Im Artikel steht eigentlich klar und deutlich, dass das
    > Design der Klassenhierachie durch Copyright geschützt sein sollte.

    Die ist in diesem Fall aber Teil der API. Konsumenten der API verlassen sich darauf, Klasse X als Erbe von Klasse Y in Paket Z zu finden. Will ich als Implementierer, dass ein Entwickler seinen Code, der diese API verwendet, weiter nutzen kann, muss ich die API genau so implementieren.

Neues Thema Ansicht wechseln


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

Anzeige
Stellenmarkt
  1. über Robert Half Technology, Berlin
  2. PTA GmbH, München
  3. Executives Online Deutschland GmbH, München
  4. T-Systems International GmbH, Bonn, Leinfelden-Echterdingen, Frankfurt am Main, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. (u. a. Die Bestimmung, Life of Pi, House of Wax, Predator, Der Polarexpress, X-Men)
  2. (u. a. House of Wax, Der Polarexpress, Gravity, Mad Max)
  3. (u. a. Der Schuh des Manitu, Agenten sterben einsam, Space Jam, Dark City)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Canon vs. Nikon: Superzoomer für unter 250 Euro
Canon vs. Nikon
Superzoomer für unter 250 Euro
  1. Snap Spectacles Snapchat stellt Sonnenbrille mit Kamera vor
  2. MacOS 10.12 Fujitsu warnt vor der Nutzung von Scansnap unter Sierra
  3. Bildbearbeitungs-App Prisma offiziell für Android erhältlich

DDoS: Das Internet of Things gefährdet das freie Netz
DDoS
Das Internet of Things gefährdet das freie Netz
  1. Hilfe von Google Brian Krebs' Blog ist nach DDoS-Angriff wieder erreichbar
  2. Picobrew Pico angesehen Ein Bierchen in Ehren ...
  3. Peak Smarte Lampe soll Nutzer zum Erfolg quatschen

MacOS 10.12 im Test: Sierra - Schreck mit System
MacOS 10.12 im Test
Sierra - Schreck mit System
  1. MacOS 10.12 Sierra fungiert als alleiniges Sicherheitsupdate für OS X
  2. MacOS Sierra und iOS 10 Apple schmeißt unsichere Krypto raus
  3. Kaspersky Neue Malware installiert Hintertüren auf Macs

  1. NBase-T alias IEEE 802.3bz: Schnelle und doch sparsame Kabelverbindungen
    NBase-T alias IEEE 802.3bz
    Schnelle und doch sparsame Kabelverbindungen

    Das ging schnell. Während sich im WLAN-Bereich die Wigig-Generation nicht so recht verbreiten will, geht es mit einem überfälligen Zwischenschritt für das LAN mit NBase-T alias 802.3bz schon los. Der Early Adopter muss aber viel zahlen.

  2. Autonomes Fahren: Komatsu baut Schwerlaster ohne Führerstand
    Autonomes Fahren
    Komatsu baut Schwerlaster ohne Führerstand

    Nie wieder wenden: Der neue Schwerlastkipper von Komatsu fährt vorwärts und rückwärts gleichermaßen gut. Grund ist, dass er keinen Fahrer hat. Der Laster fährt sich selbst.

  3. 500-Millionen-Hack: Yahoo sparte an der Sicherheit
    500-Millionen-Hack
    Yahoo sparte an der Sicherheit

    Marissa Mayer verteilte bei Yahoo kostenfreie iPhones und teures Catering - an der Sicherheit wurde aber offenbar gespart. Außerdem bezweifelt eine Sicherheitsfirma, dass Yahoo wirklich von einem staatlichen Akteur gehackt wurde.


  1. 11:59

  2. 11:35

  3. 11:20

  4. 11:03

  5. 10:46

  6. 09:17

  7. 07:45

  8. 07:26