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. Wilhelm Bahmüller Maschinenbau Präzisionswerkzeuge GmbH, Plüderhausen bei Schrondorf
  2. über Hays AG, Frankfurt
  3. T-Systems International GmbH, Leinfelden-Echterdingen
  4. T-Systems International GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (-58%) 24,99€
  2. (-26%) 12,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Sonos Playbase vs. Raumfeld Sounddeck: Wuchtiger Wumms im Wohnzimmer
Sonos Playbase vs. Raumfeld Sounddeck
Wuchtiger Wumms im Wohnzimmer
  1. Playbase im Hands on Sonos bringt kraftvolles Lautsprechersystem fürs Heimkino

Elektromobilität: Wie kommt der Strom in die Tiefgarage?
Elektromobilität
Wie kommt der Strom in die Tiefgarage?
  1. e.GO Life Elektroauto aus Deutschland für 15.900 Euro
  2. Elektroauto VW testet E-Trucks
  3. Elektroauto Opel Ampera-E kostet inklusive Prämie ab 34.950 Euro

In eigener Sache: Die Quanten kommen!
In eigener Sache
Die Quanten kommen!
  1. In eigener Sache Golem.de führt kostenpflichtige Links ein
  2. In eigener Sache Golem.de sucht Marketing Manager (w/m)
  3. In eigener Sache Golem.de geht auf Jobmessen

  1. Cobot: Der Roboter wird zum Kollegen
    Cobot
    Der Roboter wird zum Kollegen

    Hannover Messe 2017 Gemeinsam statt durch Zäune getrennt: Der Roboter der Zukunft arbeitet nicht mehr in abgetrennten Arealen, sondern mit dem Menschen zusammen. Oberstes Gebot dabei ist, dass diese Cobots den Menschen nicht verletzen.

  2. Mimimi: Entwicklerverband kritisiert Deutschen Computerspielpreis
    Mimimi
    Entwicklerverband kritisiert Deutschen Computerspielpreis

    Das Entwicklerstudio Mimimi Productions verweigert eine Preisannahme - und verzichtet damit auch auf 40.000 Euro. Nun wird klar, dass Ursache für den Eklat wohl Unstimmigkeiten bei der Wahl der Jury sind.

  3. Sprachassistent: Google stellt SDK für Assistant vor
    Sprachassistent
    Google stellt SDK für Assistant vor

    Entwickler können künftig eigene Geräte mit eingebautem Google-Assistant entwickeln: Google hat ein entsprechendes SDK vorgestellt. Damit kann nicht nur auf dessen Wissen zugegriffen werden, sondern auch auf Sprachantworten.


  1. 12:01

  2. 11:53

  3. 11:42

  4. 11:32

  5. 11:21

  6. 11:04

  7. 10:27

  8. 10:12