Java SE unter der GPL?



  • Es ist nicht offiziell, sondern es hat jemand angeblich etwas erfahren:
    http://www.golem.de/0611/48819.html

    Nun, da ich tagtäglich kommerzielle Inhouse-Software in Java entwickle, würde mich diese Vermutung und ihre Folgen schon interessieren.

    Sagen wir mal, SUN stellt Java SE tatsächlich unter die GPL. Das würde nicht nur die JVM oder Javac.exe betreffen, sondern sicherlich auch die Runtime-Libs (java.utils., javax. usw.). Wie ist das jetzt mit der GPL? Ist dann automatisch die Software unseres Kunden auch unter GPL, sobald ich die GPL-Variante von Java SE nutze?

    Mir geht es jetzt nur um die rechtlichen Folgen. Ob GPL gut oder schlecht ist, kann man sich streiten.



  • Hm, wenn es solche Probleme gäbe, hätten ganz viele Projekte und Firmen Probleme... Sun würde damit Java ganz schön unpopulär machen und sich damit selbst schaden ➡ ich halte nicht viel von dieser Meldung.



  • Wie gesagt, eine Meinung zur GPL wollte ich nicht haben. Aber aus deiner Meinung schliesse ich indirekt, das meine Vermutung richtig ist.



  • Java ist zuallererst mal eine Sprache. Was eventuell unter GPL veroeffentlich wird (was ich nicht glaube, Sun hat doch extra 'ne eigene OS-Lizenz geschaffen), waere die Sun-Implementierung von Java. Aber da Dein Programm ja genausogut unter den Java-Implementierungen von IBM oder Blackdown laufen koennte, ist Dein Programm ziemlich sicher kein "derived work" von Sun-Java. Und das ist es, worauf es ankommt.

    Ausserdem: Wenn Java unter GPL veroeffentlicht wird, dann ziemlich sicher _zusaetzlich_ zur alten Lizenz, nicht stattdessen. Von daher gibts eh kein Problem.



  • Moin

    Ich versteh irgendwie nicht wiso das ein problem werden sollte, wenn java unter der GPL stehen sollte. Ich verwende zwar pakete die ggf unter GPL stehen können, müssen aber nicht, da sie das momentan ja auch nicht tun. (*.jar fils) Und da diese erst zur laufzeit "verlinkt" werden (wenn man bei java überhaupt von verlinkung sprechen kann) hab ich zwar eine bindung aber keine direkte. Ich leite mein werk somit nicht direckt davon ab.

    Das gleiche ist für mich bei c/c++. wenn ich eine GPL lib direckt in meinem projekt einkompilire muss mein projekt auch wieder unter die GPL. Wenn ich jetzt aber die GPL Lib in eine DLL verpacke und in einem sepearaten übersetzungsprojekt erstelle, und diese Dynamisch zur laufzeit in einem anderen projekt einbinde, muss dieses Projekt dann auch unter die GPL? Ich könnte auch eine DLL schaffen die das ganze ohne GPL beschränkung erledigen könnte. Oder darf ich das nicht mehr, da die DLL ein quasi interface implementieren würde das aufgrund der ersten GPL - DLL unter die GPL fallen würde?

    Sollte mich mal ein bischen mehr mit dem thema auseinandersetzen. Da kommen mir gerade ganz interesante fragestellungen.

    Auserdem hab ich gedacht, das sun nur die spezifikation unter die GPL stellen will.

    gruss



  • Eine DLL ist eine Linkung zur Laufzeit! Im DLL steckt das Wort "Link" drin, aber es passiert halt dynamisch (zur Laufzeit) - einfach nur zu einem späteren Zeitpunkt. So, wenn in der GPL steht, das nur zur Compile-Zeit die GPL gültig ist, ist man ja aus dem Schneider. Aber wenn es generell um Linken geht?

    Weiterhin hast du zu jeder C++ DLL auch eine Header, und die steht meistens dann auch unter GPL, oder? Und die Header bekommt der Compiler auf jeden Fall mit. Oh oh! Deshalb benutzt ja sogut wie niemand unter Windows die Qt-GPL, auch wenn Qt mehrere DLLs hat. Theoretisch könnte man jede GPL-Bedingung umgehen, in dem man eine GPL-Lib in eine DLL oder unter Linux eine .so steckt. Dann würde jedes Closedsource-Projekt mit Leichtigkeit GPL-Libs benutzen können. Ist aber nicht der Fall.

    So, was passiert mit den JARs? Werden die auch zur Laufzeit gelinkt? Oder was passiert technisch im Hintergrund?



  • Termite schrieb:

    Das gleiche ist für mich bei c/c++. wenn ich eine GPL lib direckt in meinem projekt einkompilire muss mein projekt auch wieder unter die GPL. Wenn ich jetzt aber die GPL Lib in eine DLL verpacke und in einem sepearaten übersetzungsprojekt erstelle, und diese Dynamisch zur laufzeit in einem anderen projekt einbinde, muss dieses Projekt dann auch unter die GPL?

    Ich glaube ja, denn so habe ich GPL verstanden. Es gibt ja auch die LGPL, die ja für den Fall gedacht ist, dass Programme, welche LGPL-Libs verlinken, nicht diese Lizenz erhalten sondern untern ihrer eigenen verbreitet werden können.

    Sollten die Java-Libs unter GPL gestellt werden, wäre das für viele Unternehmen nicht zu tolerieren, von daher glaube ich der Meldung nicht so ganz.



  • Artchi schrieb:

    Eine DLL ist eine Linkung zur Laufzeit! Im DLL steckt das Wort "Link" drin, aber es passiert halt dynamisch (zur Laufzeit) - einfach nur zu einem späteren Zeitpunkt. So, wenn in der GPL steht, das nur zur Compile-Zeit die GPL gültig ist, ist man ja aus dem Schneider. Aber wenn es generell um Linken geht?

    fuer sowas gibts die LGPL, libs wo der src unter gpl steht, aber dynamische linken ist problemlos fuer nicht gpl apps, bsp is zb sdl

    ansonst, linzenzen gibt es viele, ich denke man kann sich drauf verlassen das sun daran denkt das es problemlos weiter moeglich sein wird sachen mit java zu schreiben die nicht unter die GPL fallen, selbstmord werden sie ja nicht begehen wollen.
    event etwas verdienen, dann ware eine dual lizenz ala trolltech moeglich, aber wir werden sehn was passiert

    ps, das es wenig qt anwendugen gibt die die gpl version verwenden liegt vielleicht uU auch daran das des fuer die gesammte versoin 3 keine windows gpl version gab.



  • @artchi:

    von linken steht in der gpl meines wissens nichts drin nur von "abgeleitet". Heißt das du den scource direckt in deinem programm mit verwendest oder erweiterst bzw. veränderst, bzw integraler bestandteil deiner anwendung ist. Da java ja so schöne jar dateien hat, kommt man meist ohne die scourcen der lib's aus die man verwendet.

    Auserdem wer sagt mir das ich die Header datei die unter der GPL steht für die DLL verwenden muss? ich kann auch DLL dynamisch laden und mittels win api mir die funktionen rausfischen, entsprechend casten und aufrufen, sicher etwas aufwendiger. Wenn ich die meist beiliegenden libs zur Dll verwende, hab ich das problem das diese auch unter der GPL liegen, und ich somit meinen code gegen die GPL-libs linke. Und wer sagt mir als Autor der DLL, das ich die Headerdatei zu meiner DLL auch unter GPL stellen muss? Wenn ich die nicht direckt zum linken der DLL benötige kann ich die sogar als closed scource behanden.

    Auserdem irgendwie haben die bei linux es ja auch hinbekommen, libs unter die LGPL zu stellen, obwohl sie mit dem kernel arbeiten, der bekantlicherweise unter der GPL steht. Sprich die LGPL libs müssen direckt oder indireckt GPL code verwenden oder aufrufen.

    gruss



  • Hallo,

    hier meine Meinung, wie das mit GPL und LGPL so ist. Als Beispiel nehme ich den Linuxkernel.

    Der steht komplett unter der GPL. Somit ist es verboten, Quellcode(teile) des Programmes in nicht-GPL Anwendungen zu verwenden. Das Verwenden von Kernelfunktionen über "binäre Schnittstellen" (also per SO/DLL/Reflection) von nicht-GPL Anwendungen aus ist verboten.

    Es gibt also keine legale Möglichkeit Kernel- oder Kernelspacefunktionen in nicht-GPL Anwendungen zu benutzen.
    Beispiel: Siehe der Stress um binäre Grafikkartentreiber im Kernel.
    Der NVidia/ATI Treiber (also das Kernelmodul) ist propietär, benutzt aber lustig GPL lizensierte Funktionen. Streng genommen ist das verboten. Praktisch zwingt dich NVidia dazu, das Kernelmodul selbst zu compilieren - den Lizenzbruch begeht also der User, nicht die Firma NVidia/ATI.
    Aus selbigem Grund gibt es closed source Treiber auch nicht standardmäßig in GPL Distributionen.

    Eine Ausnahme GPL & den Rest der Welt zu mischen gibt es jedoch:
    Wenn die GPL Funktionen beispielsweise per Socket verfügbar gemacht werden, dürfen auch nicht GPL Programme darauf zugreifen. So wäre ein Programm, welches seine Funktionen per SOAP-Protokoll verfügbar macht, (fast)universell verwendbar. Es gab da mal eine Opensource Schachengine, über die wurde dreisterweise ein simpler Socket-RPC-Server gelegt und das wurde dann leicht verändert für Geld (und ohne Quellcode) veröffentlicht. Dreist, aber theoretisch legal.

    Wie sieht das mit der Mischung eines GPL-Kernels uns eines beliebig lizensierten Userspaces aus? Gute Frage, k.a. Wie kommunizieren die Lowlevel Userspacesachen mit dem Kernel? Wenn das nur über Devices oder Pipes läuft, dürften die gleichen Regeln wie bei Sockets gelten.

    </subjektive Meinung zu Rechtsthemen>


  • Mod

    Artchi schrieb:

    Es ist nicht offiziell, sondern es hat jemand angeblich etwas erfahren:
    http://www.golem.de/0611/48819.html

    Nun, da ich tagtäglich kommerzielle Inhouse-Software in Java entwickle, würde mich diese Vermutung und ihre Folgen schon interessieren.

    Sagen wir mal, SUN stellt Java SE tatsächlich unter die GPL. Das würde nicht nur die JVM oder Javac.exe betreffen, sondern sicherlich auch die Runtime-Libs (java.utils., javax. usw.). Wie ist das jetzt mit der GPL? Ist dann automatisch die Software unseres Kunden auch unter GPL, sobald ich die GPL-Variante von Java SE nutze?

    Mir geht es jetzt nur um die rechtlichen Folgen. Ob GPL gut oder schlecht ist, kann man sich streiten.

    Falls es tatsächlich die GPL wird, bin ich mir sicher, dass Java auch weiterhin zusätzlich unter der jetzigen Lizenz oder einer ähnlichen Lizenz erhältlich bleiben wird. Der Originalartikel (diese ganzen Meldungen darüber sind ja das Resultat eines einzelnen unbestätigten Artikels, der auf irgendwelchen inoffiziellen Informationen basiert) sagt dazu auch:

    http://www.crn.com/sections/breakingnews/breakingnews.jhtml;?articleId=193600331

    A more likely scenario is that Sun would offer dual licensing for Java, a commercial/community hybrid approach used by vendors such as MySQL and Sleepycat Software (now part of Oracle).


  • Mod

    Anscheinend ist es heute soweit. Der erste Teil von Java kommt unter die GPLv2. Die Lizenz wird aber wohl eine explizite Ausnahme enthalten, die es Closed-Source-Projekten erlaubt, die Standardbibliothek zu verlinken und davon abzuleiten. Weiterhin wird es eine zweite kommerzielle Lizenz geben. ...sagt zumindest:

    http://www.javalobby.org/java/forums/t84244.html

    Java SE scheint aber erst mit der zweiten Stufe der Öffnung von Java Anfang 2007 zu folgen. ...zumindest sehe ich in dem Beitrag auf javalobby.org keinen Hinweis darauf, dass Java SE jetzt schon dabei ist.


Anmelden zum Antworten