1. Foren
  2. Kommentare
  3. Politik/Recht
  4. Alle Kommentare zum Artikel
  5. › Oracle gegen Google: Java…
  6. Th…

Lizenzrechte auf eine API?

Für Konsolen-Talk gibt es natürlich auch einen Raum ohne nerviges Gedöns oder Flamewar im Freiraum!
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Lizenzrechte auf eine API?

    Autor: mnementh 29.03.18 - 11:03

    gadthrawn schrieb:
    --------------------------------------------------------------------------------
    > 1. google mal nach dem Code, du wirst einige Projekte aus dem JAvaumfeld
    > finden, wo der so drin ist. Beispiel? github.com
    >
    Die Klammerung stimmt nicht in Deinem Beispiel, wie man leicht sieht. Der Code ist daher syntaktisch inkorrekt und also nirgends enthalten.

    > 2. Wieviel triviales muss drin sein, damit es nicht trivial ist?
    >
    Es muss etwas mit Schöpfungshöhe enthalten sein, statt viel Triviales.

    > 3. Ach und immer mit genau denselben Bezeichnern? Sehr unglaubwürdig.
    Alle Bezeichner in dem Beispiel sind durch die API vorgegeben, die man erfüllen muss um kompatibel zu sein.

  2. Re: Lizenzrechte auf eine API?

    Autor: mnementh 29.03.18 - 11:16

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Beazy schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Habe ich das richtig verstanden? Kann eine Firma jetzt verhindern, dass
    > > jemand ihr Produkt API-kompatibel nachprogrammiert?
    >
    > Wieso "jetzt"? Konnte das eine Firma nicht schon immer verhindern?
    >
    > > Heißt das, Projekte wie Mono oder Wine können in Zukunft im Keim
    > erstickt
    > > werden?
    >
    > Nicht in den USA. Der große Unterschied zwischen Mono/Wine und Android ist:
    > Die Macher von Mono und Wine verdienen mit diesen Projekten keinen Cent.
    > Kommerzieller Nutzwert ist gleich Null. Das war ja einer der
    > Hauptkritikpunkte in diesem Verfahren. Laut Gericht kann das was Google
    > macht gar kein Fair Use sein, denn da wo Gewinnabsicht das Spielfeld
    > betritt, da darf Fair Use nur noch von der Seitenlinie zuschauen. Und
    > Google verdient Geld mit Android, auch wenn sie Android direkt nicht
    > verkaufen.
    >
    Aber Fair USe erlaubt keine Open Source Software. Denn diese erlaubt kommerzielle Nutzung. Mono steht unter MIT-Lizenz. Microsoft könnte also diese Lizenz untersagen oder Firmen verklagen die Mono lizenzkonform benutzen. Das wird in diesem Fall nicht passieren, da MS Mono unterstützt, aber nach der Auslegung dass APIs schützenswert sind, sind kompatible Open Source Implementierungen verboten.

    > Das wirft aber durchaus die Frage auf, ob Microsoft nicht gegen Codeweavers
    > vorgehen kann, weil deren CrossOver Produkt basiert ja auf Wine und das
    > verfolgt aber ohne Zweifel kommerzielle Absichten:
    >
    > www.codeweavers.com
    >
    > Aber vielleicht hat MS da auch kein Interesse dran, denn zum einen ist die
    > Anzahl der CrossOver Nutzer verhältnismäßig klein (fraglich ob sich der
    > Aufwand überhaupt lohnen würde) und zum anderen ist der Haupteinsatzzweck
    > dieses Produktes lange Zeit die Möglichkeit gewesen, MS Office unter Linux
    > nutzen zu können, das MS selbes ja nicht für diese Plattform anbietet. Und
    > wenn ich sage "nutzen", dann meine ich legal nutzen, sprich, die Nutzer
    > haben bei Microsoft ein Office Lizenz ganz legal erworben um dieses Produkt
    > ganz legal auf ihrer Linuxkiste nutzen zu können. Microsoft hat also auch
    > noch Geld verdient an der ganzen Geschichte und wahrscheinlich wesentlich
    > mehr als ihnen die Lizenzkosten eingebracht hätten.
    Genau so. Oracle ist halt frecher in der Beziehung. Microsoft selbst ist vermutlich überrascht von der Auslegung, dass APIs schützenswert sind. Das könnte fies ausgelegt auch MS in die Zwickmühle bringen, denn Windows hat durchaus kompatible APIs zu Unix oder in der Unix-Welt verbreiteten Sachen. Mein Gott, könnte Sir Tim Berners-Lee mit der Auslegung Leute wegen der Implementierung des HTTP-Protokolls auf Schadensersatz verklagen? Das ganze Internet wäre kaputt. Die Möglichkeiten sind grenzenlos. Oracle hat hier wirklich eine Dose voller Würmer geöffnet.

  3. Re: Lizenzrechte auf eine API?

    Autor: Tuxgamer12 29.03.18 - 11:21

    Kurz doch noch der Link, weil ich ihn gerade habe; aber dass Sun eigentlich der Meinung war "ist okay" tut wie bereits gesagt nicht so viel zur Sache.
    https://www.cnet.com/news/former-sun-ceo-says-googles-android-didnt-need-license-for-java-apis/

    Aber ja: Ein gewisses Maß an Core-Bibliotheken zählt man zu einer Sprache hinzu. Versuche mal ohne den hier relevanten APIs was sinnvolles in Java zu programmieren. Und ja: Die meisten App-Entwickler schreinen wohl nicht danach, sich in eine zweite, inkompabible Klassenbibliothek einarbeiten zu müssen.

    Um die Sache noch einmal auf den Punkt zu bringen: Grundsätzlich geht es mir einzig und alleine um die Möglichkeit, freie Alternativen zu propritärer Software zu re-implementieren.

    Da das Urteil aber sowieso nicht mehr so ausfällt, wie es kurzzeitig auch mal war:
    https://www.theverge.com/2012/5/31/3055620/oracle-java-api-not-covered-copyright-law/in/2731667
    muss ich mich wohl mit FairUse begnügen.

    Bei Google ist das natürlich aus dem von dir auch genannten Punkten recht lustig; ich gehe jedoch davon aus, dass bei definitiv nicht-komerzieller Nutzung und freier Software die Frage Fair Use eindeutig anders ausfällt. Genau dieser komerzielle Charakter von
    Android ist genau die Sache, die ich akzeptiere. Grundsätzlich Re-implementierung propritärer Software verbieten eher nicht.

    Ich denke, wir haben gestern doch sehr auseinander geredet, deshalb spare ich mir das Zitieren jedes einzelnen Satzes.



    1 mal bearbeitet, zuletzt am 29.03.18 11:24 durch Tuxgamer12.

  4. Re: Lizenzrechte auf eine API?

    Autor: rldml 29.03.18 - 11:23

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > gadthrawn schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > 2. Wieviel triviales muss drin sein, damit es nicht trivial ist?
    > >
    > Es muss etwas mit Schöpfungshöhe enthalten sein, statt viel Triviales.

    Mit der Argumentation kannst du nahezu allem eine Schöpfungshöhe absprechen: Da du heutzutage alles als digitale Abfolge von Nullen und Einsen darstellen kannst, und nix trivialer ist als 0 und 1, erreicht somit nichts mehr irgendeine definierte Schöpfungshöhe.

    Mit trivial ist im Programmierumfeld eher die Umsetzung von Sprachmerkmalen gemeint: Wenn ich in einem Array aus Objekten eine Eigenschaft der Objekte ausgeben will, dann macht man immer mit Hilfe einer Schleife - dann hätte diese für sich alleine noch keine Schöpfungshöhe, weil jeder in irgendeiner Weise eine Schleife in seinem Quellcode einbauen würde um diese Aufgabe zu erfüllen.

    > > 3. Ach und immer mit genau denselben Bezeichnern? Sehr unglaubwürdig.
    > Alle Bezeichner in dem Beispiel sind durch die API vorgegeben, die man
    > erfüllen muss um kompatibel zu sein.

    Wie du deine Variablen INNERHALB einer Funktion benennst, ist für jede Art von Quellcode AUßERHALB der Funktion völlig egal. Wenn die Variablen innerhalb einer Funktion völlig identisch sind, ist das ein klarer Hinweis auf Copy+Paste.

    Gruß Ronny

  5. Re: Lizenzrechte auf eine API?

    Autor: mnementh 29.03.18 - 12:49

    Tuxgamer12 schrieb:
    --------------------------------------------------------------------------------
    > Bei Google ist das natürlich aus dem von dir auch genannten Punkten recht
    > lustig; ich gehe jedoch davon aus, dass bei definitiv nicht-komerzieller
    > Nutzung und freier Software die Frage Fair Use eindeutig anders ausfällt.
    > Genau dieser komerzielle Charakter von
    > Android ist genau die Sache, die ich akzeptiere. Grundsätzlich
    > Re-implementierung propritärer Software verbieten eher nicht.
    >
    Freie software erlaubt per Definition kommerzielle Nutzung. Insofern macht Urheberrecht auf API auch kompatible Reimplementationen als freie Software unmöglich.

  6. Re: Lizenzrechte auf eine API?

    Autor: Trockenobst 29.03.18 - 12:49

    Tuxgamer12 schrieb:
    --------------------------------------------------------------------------------
    > Und gerade als Softwareentwickler solltest du dich fragen, ob du - sobald
    > du eine API einer nicht-OpenSource Software nutzt - der jeweiligen Firma
    > komplett ausgeliefert sein willst. Und bedenke immer: Firmenpolicies können
    > sich problemlos innerhalb kürzester Zeit um 180 Grad drehen - wie z.B. als

    Das Problem mit Sun damals war nicht, das Google nicht bereit gewesen wäre die Lizenzen zu zahlen. Das Problem war, dass Sun das Mobile Thema sehr wichtig gewesen ist, und sie nicht mit einer schnöden Lizenz für Java zufrieden waren.

    Wikipedia zum Thema:
    Sun offered a licensing deal of between US$30 and 50 million, a figure that Schmidt said Google would have paid, but also requested some shared control of Android which troubled the company

    Sie wollten ein Joint Venture mit Google erzwingen, und die hatten darauf keine Lust.
    Was auch korrekt ist.

    > Das einzige, was ich interessant finde, ist was die jeweiligen Ausgänge dieses
    > Rechtsstreites für Konsquenzen haben könnten.

    In der Rechtscommunity dort ist man immer davon ausgegangen, dass die Konservative Sicht im Urheberrecht sich durchsetzen wird. Die vorherigen Urteile waren grundsätzlich eher als "unerwartet" betrachtet worden.

    Klar hätte heute Oracle 10% Kontrolle an Android und würde das natürlich mit entsprechenden Datenbankprodukten etc. bespielen und wahrscheinlich auch hart weitere Lizenzen von den Implementatoren von Android erzwingen.

    Ob Android diesen Siegeszug gehabt hätte, müsste man verneinen. Oracle ist keine Enduser Company, die lassen sich mit allem ewig Zeit und wenn was kein Geld mehr macht, verramschen sie es an Apache, Eclipse oder wem auch immer.

    Google wird zahlen, aber im Kontext der vorhandenen Marktmacht und zukünftigen Kontrolle ist Geld Pur vielleicht schmerzhaft, aber nicht schmerzhafter als das bei jeder neuen Androidversion Oracle anruft und sagt "Wartet mal sechs Monate, wir haben da ein paar tolle Lizenzideen für die vielen Android Umsetzer".

  7. Re: Lizenzrechte auf eine API?

    Autor: Trockenobst 29.03.18 - 12:51

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Freie software erlaubt per Definition kommerzielle Nutzung. Insofern macht
    > Urheberrecht auf API auch kompatible Reimplementationen als freie Software
    > unmöglich.

    Deswegen gibt es eben auch GPL Projekte, die sagen "API is LGPL und Implementation is GPL". Weil dort politisch wollen, dass etwa andere Sprachen diese API nutzen.

  8. Re: Lizenzrechte auf eine API?

    Autor: mnementh 29.03.18 - 12:56

    rldml schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > gadthrawn schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > 2. Wieviel triviales muss drin sein, damit es nicht trivial ist?
    > > >
    > > Es muss etwas mit Schöpfungshöhe enthalten sein, statt viel Triviales.
    >
    > Mit der Argumentation kannst du nahezu allem eine Schöpfungshöhe
    > absprechen: Da du heutzutage alles als digitale Abfolge von Nullen und
    > Einsen darstellen kannst, und nix trivialer ist als 0 und 1, erreicht somit
    > nichts mehr irgendeine definierte Schöpfungshöhe.
    >
    > Mit trivial ist im Programmierumfeld eher die Umsetzung von Sprachmerkmalen
    > gemeint: Wenn ich in einem Array aus Objekten eine Eigenschaft der Objekte
    > ausgeben will, dann macht man immer mit Hilfe einer Schleife - dann hätte
    > diese für sich alleine noch keine Schöpfungshöhe, weil jeder in irgendeiner
    > Weise eine Schleife in seinem Quellcode einbauen würde um diese Aufgabe zu
    > erfüllen.
    >
    Eine Aneinanderreihung von Trivialitäten macht noch nichts mit Schöpfungshöhe. Etwas mit Schöpfungshöhe kann triviale Bestandteile enthalten. Das ist ein Unterschied.

    > > > 3. Ach und immer mit genau denselben Bezeichnern? Sehr unglaubwürdig.
    > > Alle Bezeichner in dem Beispiel sind durch die API vorgegeben, die man
    > > erfüllen muss um kompatibel zu sein.
    >
    > Wie du deine Variablen INNERHALB einer Funktion benennst, ist für jede Art
    > von Quellcode AUßERHALB der Funktion völlig egal. Wenn die Variablen
    > innerhalb einer Funktion völlig identisch sind, ist das ein klarer Hinweis
    > auf Copy+Paste.
    >
    Nein. In der Spezifikation sind die Namen der Parameter definiert. Es wurden in dem Beispiel keine Bezeichner innerhalb der Funktion definiert, schon weil die Funktion trivial ist.

    Aber abgesehen davon bezweifle ich auch, dass die gleiche Wahl von Parameternamen auf Kopie schließen lässt. Es gibt bei Namen gewissen Konventionen. Hier geht es um arrayLen, fromIndex and toIndex. Nichts außergewöhnliches. Natürlich gibt es andere Varianten, aber sinnvoll kann man angesichts der Semantik nur zwei oder drei Namen wählen. Und man benennt oft nach System, also alle im gleichen Schema.

    Hätte der Code von Oracle sehr ungewöhnlich und nicht Namenskonventionen entsprechende Namen enthalten (beispielsweise rldml, gadthrawn und mnementh) und Google hätte die gleichen verwendet, dann würde ich zustimmen es wäre kopiert.

  9. Re: Lizenzrechte auf eine API?

    Autor: mnementh 29.03.18 - 12:57

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Freie software erlaubt per Definition kommerzielle Nutzung. Insofern
    > macht
    > > Urheberrecht auf API auch kompatible Reimplementationen als freie
    > Software
    > > unmöglich.
    >
    > Deswegen gibt es eben auch GPL Projekte, die sagen "API is LGPL und
    > Implementation is GPL". Weil dort politisch wollen, dass etwa andere
    > Sprachen diese API nutzen.
    Sowohl GPL als auch LGPL sind freie Lizenzen und erlauben kommerzielle Nutzung, sind also nicht durch Fair Use gedeckt. Man dürfte eine durch Urheberrecht geschützte API also weder in GPL noch in LGPL reimplementieren.

  10. Re: Lizenzrechte auf eine API?

    Autor: Trockenobst 29.03.18 - 13:08

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Sowohl GPL als auch LGPL sind freie Lizenzen und erlauben kommerzielle
    > Nutzung, sind also nicht durch Fair Use gedeckt. Man dürfte eine durch
    > Urheberrecht geschützte API also weder in GPL noch in LGPL
    > reimplementieren.

    Solange man sich an die GPL und LGPL hält, gibt es keine Möglichkeit eine Anklage zu beginnen. Als Java damals noch bei Sun war, war java rein unter einer proprietären Lizenz und Google hat 1:1 die API kopiert.

    Deswegen wird ja momentan wegen weitläufigen GPL Verletzungen so ein Wind gemacht. Die meisten bauen auch keine API nach, sondern halten sich einfach nicht an die Lizenz, eg. ihren Sourcecode offen legen. LGPL gegen eine API sagt, dass Du die API in deinen Modulen nachbilden darfst. Dein Code kann dann unter einer beliebigen Lizenz sein.

    Der einzige Fall der hier passend wäre, ist der Mono Nachbau von .net. Aber der ist ja mit Wohlwollen von Microsoft passiert.

    Es gibt massig OpenSource GPLd Projekte wie Blogs oder Shops. Und da existieren inzwischen 1:1 nachbauten. Die beteiligten Firmen schießen sich zu 99% auf verwendete Trademarks ein. Solange man die GPL einhält, war da auch gerichtlich nichts zu holen. Jedenfalls kenne ich keinen Fall.

  11. Re: Lizenzrechte auf eine API?

    Autor: Trockenobst 29.03.18 - 13:17

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Die Möglichkeiten sind grenzenlos. Oracle hat hier
    > wirklich eine Dose voller Würmer geöffnet.

    Wie du auf diese Sichtweise kommst ist absolut unklar.

    Von der Wikipedia Seite:
    The 37 API calls arose through through the implementation of a portion of Apache Harmony, an open-source cleanroom Java implementation developed by the Apache Software Foundation (ASF). The ASF had tried to obtain necessary licenses from Sun to support the Apache Harmony project, but could not in part due to incompatible licensing with Java's GNU General Public License and ASF's Apache License, nor could gain access to the Java Technology Compatibility Kit to validate the Harmony project against Sun's implementation.[11][12]

    Praktisch ist Dalvik eine indirekte GPL Verletzung. Apache Harmony war eine ASF Version der Basislibrary, die aber nie eine Lizenz von Sun/Oracle bekam. Eine GPLd API mit beliebiger Größe war schon immer grenzwertig im Copyright. Das Oracle dies nun mit Nachdruck klargestellt hat ist vollkommen in Ordnung.

    In der Zukunft wird man eben bei größeren APIs darauf pochen, dass derjenige der sie veröffentlicht die APIs selbst auch unter eine entsprechende Lizenz legt. Für ein paar Jahren wird es etwas Unsicherheit geben und ein paar gewiefte werden irgendwo ein paar Cents abgreifen. Wie viele andere Fälle kann es da geben?

    90% der Java Welt stehen komplett unter Apache Lizenz. Das gilt auch für die API. im C++ Bereich ist fast alles unter Derivaten von BSD oder MIT. Es gibt keinen Grund die große Glocke zu läuten.

  12. Re: Lizenzrechte auf eine API?

    Autor: mnementh 29.03.18 - 13:39

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Sowohl GPL als auch LGPL sind freie Lizenzen und erlauben kommerzielle
    > > Nutzung, sind also nicht durch Fair Use gedeckt. Man dürfte eine durch
    > > Urheberrecht geschützte API also weder in GPL noch in LGPL
    > > reimplementieren.
    >
    > Solange man sich an die GPL und LGPL hält, gibt es keine Möglichkeit eine
    > Anklage zu beginnen. Als Java damals noch bei Sun war, war java rein unter
    > einer proprietären Lizenz und Google hat 1:1 die API kopiert.
    >
    Du verstehst meine Argumentation nicht. Wenn APIs unter das Urheberrecht fallen, sind kompatible Open-Source-Implementierungen proprietärer APIs ohne Einwilligung des Urhebers vom Tisch. Wenn der Urheber seine Einwilligung gibt (und Open-Source-Lizenzen sind so etwas), dann ist das etwas anderes. Spielt hier aber keine Rolle. Als die Android-Entwicklung begann gab es noch kein OpenJDK und Oracle verklagt nicht auf Verletzung der GPL (da hätten sie kaum Anspruch auf Schadensersatz), sondern auf Verletzung der kommerziellen Java-Lizenz.

    > Deswegen wird ja momentan wegen weitläufigen GPL Verletzungen so ein Wind
    > gemacht. Die meisten bauen auch keine API nach, sondern halten sich einfach
    > nicht an die Lizenz, eg. ihren Sourcecode offen legen. LGPL gegen eine API
    > sagt, dass Du die API in deinen Modulen nachbilden darfst. Dein Code kann
    > dann unter einer beliebigen Lizenz sein.
    >
    Darum geht es aber nicht. Open-Source-Projekte haben ja schon nichts dagegen, dass Du ihren Code nimmst, erst recht nicht gegen Reimplementierungen.

    > Der einzige Fall der hier passend wäre, ist der Mono Nachbau von .net. Aber
    > der ist ja mit Wohlwollen von Microsoft passiert.
    >
    Nö, wie gesagt geht es bei Android um das kommerzielle Java. Aber es gäbe da auch noch Wine, Dosbox, MAME, ... Viele Projekte wären von dieser Auslegung betroffen.

    > Es gibt massig OpenSource GPLd Projekte wie Blogs oder Shops. Und da
    > existieren inzwischen 1:1 nachbauten. Die beteiligten Firmen schießen sich
    > zu 99% auf verwendete Trademarks ein. Solange man die GPL einhält, war da
    > auch gerichtlich nichts zu holen. Jedenfalls kenne ich keinen Fall.
    Wie gesagt, es geht nicht um API-Nachbauten wo das Original OSS ist. Sondern darum dass diese Auslegung eine OSS-Implementierung einer API verhindert.

  13. Re: Lizenzrechte auf eine API?

    Autor: mnementh 29.03.18 - 13:48

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Die Möglichkeiten sind grenzenlos. Oracle hat hier
    > > wirklich eine Dose voller Würmer geöffnet.
    >
    > Wie du auf diese Sichtweise kommst ist absolut unklar.
    >
    > Von der Wikipedia Seite:
    > The 37 API calls arose through through the implementation of a portion of
    > Apache Harmony, an open-source cleanroom Java implementation developed by
    > the Apache Software Foundation (ASF). The ASF had tried to obtain necessary
    > licenses from Sun to support the Apache Harmony project, but could not in
    > part due to incompatible licensing with Java's GNU General Public License
    > and ASF's Apache License, nor could gain access to the Java Technology
    > Compatibility Kit to validate the Harmony project against Sun's
    > implementation.[11][12]
    >
    > Praktisch ist Dalvik eine indirekte GPL Verletzung. Apache Harmony war eine
    > ASF Version der Basislibrary, die aber nie eine Lizenz von Sun/Oracle
    > bekam. Eine GPLd API mit beliebiger Größe war schon immer grenzwertig im
    > Copyright. Das Oracle dies nun mit Nachdruck klargestellt hat ist
    > vollkommen in Ordnung.
    >
    Nope. Harmony wurde entwickelt als es keine GPL-Version von Java gab. Und Oracle verklagt nicht auf GPL-Verletzung, sondern auf das kommerzielle Java. Das OpenJDK spielt bei der Betrachtung schlicht keine Rolle, es hat keine Funktion in dem Streit, schon allein deshalb weil der Beginn der Android-Entwicklung vor OpenJDK liegt.

    > In der Zukunft wird man eben bei größeren APIs darauf pochen, dass
    > derjenige der sie veröffentlicht die APIs selbst auch unter eine
    > entsprechende Lizenz legt. Für ein paar Jahren wird es etwas Unsicherheit
    > geben und ein paar gewiefte werden irgendwo ein paar Cents abgreifen. Wie
    > viele andere Fälle kann es da geben?
    >
    Wine, Dosbox, MAME, R (Nachbau von S), alle Unixe (AT&T Unix), Windows (nutzt Unix-APIs) ... - unsere gesamte moderne Softwarewelt beruht darauf, dass APIs nicht copyrightgeschützt sind.

    > 90% der Java Welt stehen komplett unter Apache Lizenz. Das gilt auch für
    > die API. im C++ Bereich ist fast alles unter Derivaten von BSD oder MIT. Es
    > gibt keinen Grund die große Glocke zu läuten.
    Wenn andere Idioten auf die Idee kommen Oracle nachzuahmen...

  14. Re: Lizenzrechte auf eine API?

    Autor: Trockenobst 29.03.18 - 14:07

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Wine, Dosbox, MAME, R (Nachbau von S), alle Unixe (AT&T Unix), Windows
    > (nutzt Unix-APIs) ... - unsere gesamte moderne Softwarewelt beruht darauf,
    > dass APIs nicht copyrightgeschützt sind.

    Im Wikipedia Artikel steht drin, das der POSIX-Standard seit um 2000 von mehren Gruppen gleichzeitig mitentwickelt und verabschiedet worden ist. Das einer behaupten könnt er hätte das alleinige Copyright auf die APIs ist eher unwahrscheinlich. Die Can-of-Worms hat schon SCO damals aufgemacht und hat nur immens viel Geld verbrannt.

    Windows würde ich deswegen herausnehmen, weil Microsoft ein Defakto-Monopolist ist und sich mit harter Hand hier nur selbst in die Nesseln setzen würde. Dann bekäme er vielleicht Links Recht gesprochen und Rechts müssten sie es wieder abgeben. Außerdem passt es nicht in die neue Mentalität, sich mit allen zu verstehen.

    MAME war schon immer ein schwieriges Thema, nicht erst seit gestern.
    http://mamedev.org/legal.html

    Da MAME kein Geld bringt, wäre das nur Geldverbrennung und Gesicht in den Shitstorm halten. Außerdem gibt es in dem Bereich gegensätzliche Gerichturteile, gerade bei der Konservierung von alten Medien, auch gegensätzliche Gesetze. Ein schwieriges Thema bei Medien (aktuell mit dem Bluray 'Kopierschutz')

    > Wenn andere Idioten auf die Idee kommen Oracle nachzuahmen...

    Nintendo versuchte immer wieder Emulatoren zu verhindern. Im US Recht hat es noch nie das Recht auf Emulation gegeben. Die Gesetze sind aus dem 2000er Zeitraum, da hat man viel in die Copyright-Gesetze geschrieben die noch heute Gültigkeit haben.
    Es gibt, wie gesagt, andere Gesetze, die bestimmte Dinge erlauben.

    Weil das so ein schwieriges Hot Topic ist, schießen Nintendo und Co gegen die ROMs.
    Sie haben natürlich die Angst, dass irgendein positiver Gesetzgeber sieht dass das Copyright Recht ein Update braucht und Emulation legalisiert wird.

    Fair Use war in den USA im Kontext von Software schon immer sehr tricky.
    https://en.wikipedia.org/wiki/Fair_use#U.S._fair_use_procedure_and_practice
    Genau deswegen hat gerade Java mit Apache Lizensiertem Code so einen Hype erlebt.
    Diese Freiheit war der massive Vorsprung zu häufig zugenagelten, schwierigen Lizenzen von Kommerztools UND Apis.

    Natürlich gibt es massig APIs. Aber es war schon immer eine schwierige Gradwanderung welche zu nutzen die eigentlich nicht öffentlich sind. Wir haben vor 10 Jahren eine Fax APi eines Systems nachgebaut (war eine dll) und haben diese dann auch erfolgreich drei Jahre lang verwendet. Der Unterschied zwischen Desktop Version und Server Version war 200¤ vs. 20000¤ (Und der Kunde hatte VIELE Server).

    Die Firma hat das irgendwann spitzgekriegt und die API der Kundenversion künstlich beschnitten. Gerade dann kamen VMs auf und wir haben einfach ein Windows 7 in der VM mit der 200¤ bespielt. ;)

  15. Re: Lizenzrechte auf eine API?

    Autor: Trockenobst 29.03.18 - 14:17

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > fallen, sind kompatible Open-Source-Implementierungen proprietärer APIs
    > ohne Einwilligung des Urhebers vom Tisch.

    Es gibt in den USA einen ganzen rechtlichen Baum von gegenläufigen Gesetzestexten und Case Law, die man sich in jedem Falle erst einmal genau ansehen müsste.

    Außerdem geht es hier um das Geld verdienen. Was ein wichtiger Punkt in der Diskussion ist. Viele der Beispiele sind OpenSource und verdienen nichts.

    Ich bin im anderen Posting unten schon auf Mame, Unix, Windows eingegangen. Neben Java (Mono) sehe ich momentan kaum andere große Produkte die in diesem Rahmen fallen.

    Kannst du aus dem Kopf zwei Produkte nennen, die in die Kategorie "Ich nehme eine OpenSource Lib/DLL" und ersetze damit das Kommerzprodukt? Auch auf anderen Diskussionsplattformen scheinen die dortigen Diskutanten das Problem zu erkennen, aber nicht wirklich **spontan** auf ein Produkt/Projekt applizieren zu können.

    Außer die, die sowieso schon immer grenzwertig waren, wie etwa Emulatoren. Es gibt z.B. schon Bios Cracks, damit man - vom Hersteller nicht gewollte - upgrades in niedrigwertigere Hardware möglich macht. Dies wird u.A. auch dadurch getan, dass man nicht vorhandene Bauteile durch Code simuliert und dadurch das Bios glaubt es wäre auf der passenden Hardware.

    Der Hersteller verliert Geld damit, aber Geld verdient mit den Cracks in 99% der Fälle niemand.

  16. Re: Lizenzrechte auf eine API?

    Autor: rldml 29.03.18 - 15:14

    Du willst mir hier doch nicht wirklich erzählen, dass du zwei Programmierer unabhängig voneinander eine (meinetwegen triviale) Aufgabe gibst und am Ende kommen zwei bis aufs letzte Zeichen identische Dateien dabei heraus.

    Es gibt immer Unterschiede, jeder der sich öfter mal durch fremden Code wühlt, weiß das.

  17. Re: Lizenzrechte auf eine API?

    Autor: Trockenobst 29.03.18 - 17:40

    rldml schrieb:
    --------------------------------------------------------------------------------
    > Es gibt immer Unterschiede, jeder der sich öfter mal durch fremden Code
    > wühlt, weiß das.

    Es geht ja auch "Mode" in der Entwicklung. Vor zehn Jahren hat man etwa Objektorientiertung auch wegen der Datenbankabhängigkeit meist bis zum Exzess betrieben. Der Lieferwagen war dann vom Auto abgeleitet und das ging dann runter bis zur var schraubenZähler = 4000;

    Diese Monster kann heute niemand mehr warten und die Datenbankperformance ist auch mies, weil solche n:m Verbindungen unwartbar sind.

    Heute gibt es ganz andere Programmiersprachen und Ansätze. Rust etwa. Darauf basierend würde man bestimmte Usecases so nicht mehr schreiben. Man muss sich nur ansehen, wie häufig Microsoft im C# konkurrente Threads abgebildet hat. Die haben das Subsystem bis zur aktuellen Version von .net drei, vier Mal komplett neu geschrieben.

    Der Fall hier von Java/Oracle ist hochspezifisch und kaum auf typische Anwendungsfälle applizierbar. Trotzdem schreibe auch ich heute ganz anders, schon alleine wegen der geforderten Skalierbarkeit trenne ich Datenschicht und Funktionalität.

    In unserer aktuellen Applikation mit ca. 50 Usecases sind die Lesefunktionen über DB Views abgebildet, weil die DB intern Joins bis zu Faktor 4 schneller machen kann als der Entwickler über höchst optimierte SQLs.

    Dagegen ist das schreiben irrelevant und wird über den Rest von C(R)UD abgewickelt.
    Das machen die Hivis. Kein Mensch hätte APIs vor 10 Jahren so geschrieben.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Berliner Stadtreinigungsbetriebe (BSR), Berlin
  2. dmTECH GmbH, Weilerswist
  3. über vietenplus, Großraum Osnabrück
  4. persona service AG & Co. KG, Unna

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme