Mal ganz abgesehen von den GPL-Verletzungen ist das, was Google und Apple derzeit abziehen einfach nur ein Debakel für die Softwarelandschaft.
Bis vor kurzem gab es mit JavaME einen weithin akzeptierten Quasi-Standard, der auf jedem ernst zu nehmendem Handy vorhanden war, und mit dessen Hilfe sich mit überschaubarem Aufwand für alle Geräte Applikationen entwickeln ließen.
Dann kommt Apple bit seinem iGlump daher und führt - oh Überraschung! - was komplett neues und komplett Java-freies ein. Wer seine Software hier sehen will, darf sie also komplett neu schreiben.
Dann kommt Google mit seiner Android-Plattform daher, die als Basis eigentlich Java verwendet - nur dummerweise ein komplett anderes, es existieren keinerlei Runtime-Bibliotheken, die mit Java ME oder SE irgend wie kompatible wären. Also auch hier: komplett neu schreiben.
Und natürlich existiert kein plattformübergreifendes Framework, das dieses Problem umgehen könnte, wxWidgets kann zwar mit Mac und iOS, aber eben nicht auf der Java-basierten Android-Plattform. Und Qt kann - AFAIK - noch nicht mal iOS.
Insgesamt ist das für Softwareproduzenten ein einziger Sumpf, ich kann nur hoffen, das über kurz oder lang wenigstens eins der beiden Systeme verschwindet.
Die Seuche JavaME als Alternative zu bezeichnen zeugt schon von gewisser Ignoranz. Und natürlich fangen jetzt alle an Google zu verklagen, nachdem Android erfolgreich geworden ist. Das wird das erste und einzige mal sein, dass Linux auf dem Desktop erfolgreich ist. Ich benutze übrigens einen Linux Desktop.
> Die Seuche JavaME als Alternative zu bezeichnen zeugt schon von gewisser Ignoranz.
Details zu deiner Behauptung?
Das einzige, was man Java ME vorwerfen kann, ist die Tatsache, dass es manchmal ein wenig gedauert hat, bis die herstellerspezifischen Klassen in Form eines JSR oder als offizieller RT-Bestandteil in der Release aufgetaucht sind.
Ansonsten war es bei vernünftiger Programmierung wirklich simpel auch für Mobilgeräte "write once run everywhere" Applikationen zu schreiben (eine offiziell zertifizierte KVM auf dem Zielgerät vorausgesetzt natürlich).
JavaME ist bis heute nicht bei den Smartphones angekommen sondern bewegt sich im Bereich der alten Feature-Phones. Wenn es so toll wäre, wären ihm nicht alle davon gelaufen *gg* Dass die Programmierung für ein I-Phone nicht grad besser geht ist schon klar, aber die Programmierung für Android ist ein Gedicht - so hätte ich mir das in Swing gewünscht (von der ollen lcdui will ich nicht anfangen).
Ich sehe es genauso wie ein Vorposter oben: DIES ist das erste (und letzte) mal, dass sich Linux auf dem Desktop durchsetzt! Und alle schreien o weh o weh ...
> JavaME ist bis heute nicht bei den Smartphones angekommen > sondern bewegt sich im Bereich der alten Feature-Phones.
Stimmt nicht. Es war längst auf Smartphones etabliert (Symbian und Windows Mobile) und ist nur in der neusten Inkarnation (iPhone, Android) nicht mehr vorhanden.
Und die unterschiedlichen Profile, die noch längst nicht auf jedem Mobiltelefon gleich vorhanden sind. Und die fehlende Distributionsmöglichkeiten. Und die schlechte Integration in bestehende Entwicklungsumgebungen (es gibt sie, aber mit iOS und Android gehts einfach komfortabler und schneller)...
Ich würde JavaME nicht direkt als Seuche bezeichnen, eher als einen guten Ansatz. Google, Apple und Palm werden aber schon wissen, warum sie da was neues gestrickt haben und wieso sie kein JavaME unterstützen wollen (abseits von den bereits erwähnten Lizenzkosten).
> Und Qt kann - AFAIK - noch nicht mal iOS. Deshalb hatte ich auch so auf einen Erfolg von Maemo/MeeGo gehofft. Auf meinem N900 läuft unsere Qt Applikation nämlich hervorragend. Bei Anroid bin ich erst noch mit dem inoffiziellen Qt Port (Lighthouse) am forschen.
Das Problem: - Qt gehört Nokia - Qt gibt es für Linux/Unix/OS-X/Windows/Maemo/MeeGO - Qt gibt es inoffiziell von der Community mit Android Lighthouse - Qt für iOS gibt es meines Wissens nach nicht. Welches Interesse sollte Nokia da auch haben ? Anders würde es aussehen, wenn Qt noch Trolltech gehören würde.
PS: Android ist mir unsympathisch, weil die GUI nur Java erlaubt. Wenn da Qt drauf laufen soll hat man einen Java Wrapper der Deine Qt App als Bibliothek ladt und dieser Bibliothek die Tastatur/Touchscreen/Mouse-Events schickt. Nicht besonders toll nach meinem Geschmack.
Die meisten dürfte das gleiche gestört haben, was mich auch stört: Java war oft mies bis gar nicht wirklich ins System integriert. Zudem gab es niemanden der Standards durchgesetzt hätte, die über die Programmierung hinausgehen.
Wenn ich auf meinem "normalen" Handy eine Java App starte, dann sehe ich erstmal eine lange Zeit (ein paar Sekunden) einen Wartescreen mit Java-Icon. Danach startet eine eher träge Anwendung die zudem mit nichts im System Ähnlichkeit hat, zudem von diesem auch nichts weiß.
So sieht JavaME für viele User auf alten Handys aus. Dazu im Vergleich eine iPhone App: Sie startet fast sofort, sieht aus wie jede Anwendung im iPhone und ist auch entsprechend gut zu bedienen, zusätzlich sind sie sehr schnell. Sie nutzen meist auch gut die Möglichkeiten des Geräts.
Was ist also wohl für den normalen User die Idealsituation? Ich denke anhand der Verkaufszahlen kannst du es dir denken.
Für alte iPhones/iPod Touch sieht es so aus: Man wählt das App aus wartet erst mal ein Paar Sekunden.Nur der Langweilige wartebildschirm kommt...Wenn man Glück hat geht es träge weiter, wenn nicht stürzt es ab, und jedes Jahr ein neues iPhone? Da kann ich nur den Kopf schütteln!
Von Warum kein BSD Kernel? am Fr, 18. März 2011 um 10:13 #
Wieso verwenden die keinen BSD-Kernel? Hab noch nie verstanden warum google den Linux Kernel wollte. Warscheinlich haben sie da schon mehr know how? Das sidekick hatte z.b. auch einen BSD Kernel
Ich wird's begrüßen, dann könnten endlich einige Baustellen mal in Angriff genommen werden. Aber vermutlich ist der Aufwand zu groß, die benötigten Treiber fehlen und ein kompletter Fork wäre vonnöten. Rein technisch würde sich NetBSD anbieten vielleicht sogar Darwin, da muss nicht so viel entrümpelt werden.
Es gab hier auf Prolinux vor einiger Zeit eine Nachricht zu GPL-Verletzungen. Dort wurde auch von Kommentatoren darauf hingewiesen, dass im Grunde genommen ein (schwerer) Lizenzfehler ausreicht, um die GPL flächendeckend in Android durchsetzen zu können. Ein solcher Fehler gerade mit der glibc wäre hierbei sehr, sehr hilfreich. Das setzt natürlich voraus, dass der zitierte Software-Experte bei seiner Analyse keinen Fehler gemacht hat. In der Nachricht selbst kommt mir jedenfalls noch zu oft das Wort "glauben" vor. IMHO ist es ein anscheinend leider legales Unding, das es möglich ist, um den freien Linuxkernel herum ein durch und durch unfreies Userland bzw. unfreies Betriebssystem wie Android herumzubauen.
Im Originaltext liest sich das so: "And now there is grave concern over the legality of a central element of its architecture: the library that connects Android and its applications with the underlying Linux kernel. (...) If Google is proven wrong, pretty much that entire software stack -- and also many popular third-party closed-source components such as the Angry Birds game and the Adobe Flash Player -- would actually have to be published under the GPL. (...)" http://fosspatents.blogspot.com/2011/03/googles-android-faces-serious-linux.html Im Text legt Müller dar, wie er sich die mögliche "Verseuchung" Androids durch den GPL-Linux-Kernel vorstellt. Im übrigen sprach ich oben von einem "legalen Unding". Wenn aus diesem androidschen GPL-, Apache/BSD/MIT- und Closed Source-Lizenzenmix ein illegales Unding werden würde, dann wäre das schon ein Riesenproblem, zumal die meisten Android-Dienstleister ausgeprägte GPL-"Hasser" zu sein scheinen. :-)
Nach meinem Wissen gibt es einen Konsens unter Juristen welcher auch schon vor Gericht bestätigt wurde das Header Dateien im allgemeinen nicht unter das Urheberrecht fallen. Header Dateien, wenn sie nicht jede Menge Inline-Code enthalten kann am als eine Schnittstellenspezifikation betrachten. Könnte man Grundsätzlich verbieten diese zu verwenden, dann wäre Interoperabilität so gut wie überhaupt nicht mehr möglich.
Header gehören ebenso unter das Urheberrecht wie Kommentare, Makros, Inline, überhaupt jeder Art von Code. Man war sich nicht einig wie das mit der "Originalität" aussieht(Deklaration), derzeit siehts aber mehr danach aus, dass Google richtig Mist gebaut hat. Das verbessert nicht gerade Googles Position beim Prozess gegen Oracle.
Wie gesagt, Anwälte sehen das anders, siehe z.B. hier: http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html
" However, I've talked with our lawyer about one specific issue that you raised: that of using simple material from header files. Someone recently made the claim that including a header file always makes a derivative work.
That's not the FSF's view. Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work. It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that. "
Nach meinem Wissen gibt es auch Rechtsurteile die in diese Richtung gehen. Ich konnte jetzt auf die schnelle nichts online finden, aber mit etwas intensiverem Googlen wirst du sicher fündig wenn es dich interessiert.
Hab hier gerade doch noch was gefunden: http://www.winehq.org/pipermail/wine-devel/2001-February/000204.html
"Copyright law does not protect idea, just the expression of them. Several court decisions have been rendered which suggest that the 'purely functional' elements of a computer program are not copyrightable. There are several cases that explicitly deal with the issue of copyright and header files. The most relevant one for Wine development is probably the 1992 decision in Sega v. Accolade, where Accolade reverse engineered the headers for Sega's ROM libraries in order to develop games compatible with Sega's hardware without paying Sega's royalties. http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html
The court in that case said:
Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles -- articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by external factors such as compatibility requirements and industry demands... In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for the purposes of copyright. When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement."
Das Header-Files nicht unter das Urheberrecht fallen war überigens auch einer der Hauptargumentatiosnlinien von IBM im Fall "IBM vs SCO". (http://www.groklaw.net/article.php?story=20070310204302343) Die Argumentation von IBM damals: Man kann einen bestimmten Error Code oder Funktion nur auf eine Art definieren, daran steckt keine schöpferische Höhe und damit nichts was unter das Urheberrecht fällt. Ein ganz einfaches Beispiel: Frage 100 Programmierer nach einem Header File für die Grundrechenarten (add, sub, mult, div) alle werden dir das liefern:
hier irgendwas unter das Urheberrecht zu stellen oder eine "schöpferische Höhe" finden zu wollen ist Absurd und wie breits gesagt und durch ein paar Links angedeutet wohl auch mehr oder weniger Konsens im juristischen Umfeld.
Gegen die pure Nutzung einfacher Header-files hätte wohl auch niemand etwas gehabt. Aber es sind eben _keine_ einfachen Header-files, wenn sich zu viel Programmlogik drinne versteckt. Dann muss eben zur nicht-lizenzgemäßen Nutzung erst die Funktionslogik bereinigt werden.
Und was ist eigentlich mit "purely functional" gemeint? Es ist ja sicher _nicht_ die Funktion gemeint. Ich kann ja eben nicht einfach irgendwelchen Quelltext nehmen und mir beliebige "Funktionen" da ausborgen. Es ist der Funktionsaufruf (bzw. dessen Definition) gemeint. Inline-Code geht aber eben darüber hinaus.
Von sülzsülzlabersülz am So, 20. März 2011 um 23:06 #
"Doch der von Google verwendete Code enthält laut Müller mehr als solche grundlegenden Dinge. Es sollen auch komplexere Definitionen und Inline-Funktionen enthalten sein"
Falls Du damit meinen solltest, irgendjemand könne sich von der GPL freikaufen, im Hinblick auf den Kernel geht das überhaupt nicht. :-) Falls das im Artikel Dargestellte tatsächlich stimmen sollte (hier sind allerdings noch dicke Fragezeichen angebracht, es würde mich überraschen, wenn Google so naiv gewesen wäre, dieses Szenario nicht zu berücksichtigen und im vorhinein durchzudenken), dann muss Google ohne Wenn und Aber die GPL erfüllen. Manche Anbieter anderer GPL-Software bieten allerdings eine Doppellizenzierung an, die man auch als "Freikaufen" verstehen könnte.
Mal ganz abgesehen von den GPL-Verletzungen ist das, was Google und Apple derzeit abziehen einfach nur ein Debakel für die Softwarelandschaft.
Bis vor kurzem gab es mit JavaME einen weithin akzeptierten Quasi-Standard, der auf jedem ernst zu nehmendem Handy vorhanden war, und mit dessen Hilfe sich mit überschaubarem Aufwand für alle Geräte Applikationen entwickeln ließen.
Dann kommt Apple bit seinem iGlump daher und führt - oh Überraschung! - was komplett neues und komplett Java-freies ein. Wer seine Software hier sehen will, darf sie also komplett neu schreiben.
Dann kommt Google mit seiner Android-Plattform daher, die als Basis eigentlich Java verwendet - nur dummerweise ein komplett anderes, es existieren keinerlei Runtime-Bibliotheken, die mit Java ME oder SE irgend wie kompatible wären. Also auch hier: komplett neu schreiben.
Und natürlich existiert kein plattformübergreifendes Framework, das dieses Problem umgehen könnte, wxWidgets kann zwar mit Mac und iOS, aber eben nicht auf der Java-basierten Android-Plattform. Und Qt kann - AFAIK - noch nicht mal iOS.
Insgesamt ist das für Softwareproduzenten ein einziger Sumpf, ich kann nur hoffen, das über kurz oder lang wenigstens eins der beiden Systeme verschwindet.
Die Seuche JavaME als Alternative zu bezeichnen zeugt schon von gewisser Ignoranz.
Und natürlich fangen jetzt alle an Google zu verklagen, nachdem Android erfolgreich geworden ist. Das wird das erste und einzige mal sein, dass Linux auf dem Desktop erfolgreich ist.
Ich benutze übrigens einen Linux Desktop.
> Die Seuche JavaME als Alternative zu bezeichnen zeugt schon von gewisser Ignoranz.
Details zu deiner Behauptung?
Das einzige, was man Java ME vorwerfen kann, ist die Tatsache, dass es manchmal ein wenig gedauert hat, bis die herstellerspezifischen Klassen in Form eines JSR oder als offizieller RT-Bestandteil in der Release aufgetaucht sind.
Ansonsten war es bei vernünftiger Programmierung wirklich simpel auch für Mobilgeräte "write once run everywhere" Applikationen zu schreiben (eine offiziell zertifizierte KVM auf dem Zielgerät vorausgesetzt natürlich).
Das was den Fundamentalisten hier stört ist die Tatsache, dass Lizenzgelder an Oracle("Jehova") gehen würden für jedes verkaufte Gerät.
JavaME ist bis heute nicht bei den Smartphones angekommen sondern bewegt sich im Bereich der alten Feature-Phones.
Wenn es so toll wäre, wären ihm nicht alle davon gelaufen *gg*
Dass die Programmierung für ein I-Phone nicht grad besser geht ist schon klar, aber die Programmierung für Android ist ein Gedicht - so hätte ich mir das in Swing gewünscht (von der ollen lcdui will ich nicht anfangen).
Ich sehe es genauso wie ein Vorposter oben:
DIES ist das erste (und letzte) mal, dass sich Linux auf dem Desktop durchsetzt!
Und alle schreien o weh o weh ...
> JavaME ist bis heute nicht bei den Smartphones angekommen
> sondern bewegt sich im Bereich der alten Feature-Phones.
Stimmt nicht. Es war längst auf Smartphones etabliert (Symbian und Windows Mobile) und ist nur in der neusten Inkarnation (iPhone, Android) nicht mehr vorhanden.
Und die unterschiedlichen Profile, die noch längst nicht auf jedem Mobiltelefon gleich vorhanden sind. Und die fehlende Distributionsmöglichkeiten. Und die schlechte Integration in bestehende Entwicklungsumgebungen (es gibt sie, aber mit iOS und Android gehts einfach komfortabler und schneller)...
Ich würde JavaME nicht direkt als Seuche bezeichnen, eher als einen guten Ansatz. Google, Apple und Palm werden aber schon wissen, warum sie da was neues gestrickt haben und wieso sie kein JavaME unterstützen wollen (abseits von den bereits erwähnten Lizenzkosten).
> Und Qt kann - AFAIK - noch nicht mal iOS.
Deshalb hatte ich auch so auf einen Erfolg von Maemo/MeeGo gehofft.
Auf meinem N900 läuft unsere Qt Applikation nämlich hervorragend.
Bei Anroid bin ich erst noch mit dem inoffiziellen Qt Port (Lighthouse) am forschen.
Das Problem:
- Qt gehört Nokia
- Qt gibt es für Linux/Unix/OS-X/Windows/Maemo/MeeGO
- Qt gibt es inoffiziell von der Community mit Android Lighthouse
- Qt für iOS gibt es meines Wissens nach nicht.
Welches Interesse sollte Nokia da auch haben ?
Anders würde es aussehen, wenn Qt noch Trolltech gehören würde.
PS: Android ist mir unsympathisch, weil die GUI nur Java erlaubt.
Wenn da Qt drauf laufen soll hat man einen Java Wrapper der Deine Qt App als Bibliothek ladt und dieser Bibliothek die Tastatur/Touchscreen/Mouse-Events schickt. Nicht besonders toll nach meinem Geschmack.
Das wichtigste Argument hast du vergessen, QT-Programme sehen/fühlen sich außerhalb Linux, KDE schrecklich an.
Die meisten dürfte das gleiche gestört haben, was mich auch stört:
Java war oft mies bis gar nicht wirklich ins System integriert. Zudem gab es niemanden der Standards durchgesetzt hätte, die über die Programmierung hinausgehen.
Wenn ich auf meinem "normalen" Handy eine Java App starte, dann sehe ich erstmal eine lange Zeit (ein paar Sekunden) einen Wartescreen mit Java-Icon. Danach startet eine eher träge Anwendung die zudem mit nichts im System Ähnlichkeit hat, zudem von diesem auch nichts weiß.
So sieht JavaME für viele User auf alten Handys aus. Dazu im Vergleich eine iPhone App:
Sie startet fast sofort, sieht aus wie jede Anwendung im iPhone und ist auch entsprechend gut zu bedienen, zusätzlich sind sie sehr schnell. Sie nutzen meist auch gut die Möglichkeiten des Geräts.
Was ist also wohl für den normalen User die Idealsituation? Ich denke anhand der Verkaufszahlen kannst du es dir denken.
Für alte iPhones/iPod Touch sieht es so aus:
Man wählt das App aus wartet erst mal ein Paar Sekunden.Nur der Langweilige wartebildschirm kommt...Wenn man Glück hat geht es träge weiter, wenn nicht stürzt es ab, und jedes Jahr ein neues iPhone?
Da kann ich nur den Kopf schütteln!
Dann hast du eine schlechte App erwischt oder trollst einfach nur...
Android = Guttenberg-OS?
Moomentmal, ja - das würde mathematisch gleichwertig bedeuten
Guttenberg = Androide.
Das erklärt wohl endlich seine Stahlgel-Frisur
.
Wieso verwenden die keinen BSD-Kernel?
Hab noch nie verstanden warum google den Linux Kernel wollte. Warscheinlich haben sie da schon mehr know how? Das sidekick hatte z.b. auch einen BSD Kernel
Ich wird's begrüßen, dann könnten endlich einige Baustellen mal in Angriff genommen werden. Aber vermutlich ist der Aufwand zu groß, die benötigten Treiber fehlen und ein kompletter Fork wäre vonnöten.
Rein technisch würde sich NetBSD anbieten vielleicht sogar Darwin, da muss nicht so viel entrümpelt werden.
Weils teuerer ist nen BSD-Kernel auf'nem Mobilgerät mit allem Foobar zum laufen zu kriegen, als dasselbe mit Linux zu machen.
Woran das liegt? Weil schon dutzende Firmen vorher Linux auf solchen und anderen Embedded-Geräten am Laufen hatten.
"Wieso verwenden die keinen BSD-Kernel? "
Wenn man BSD-Reste im System will, ist man dann nicht beim iPhone besser aufgehoben?
Es gab hier auf Prolinux vor einiger Zeit eine Nachricht zu GPL-Verletzungen.
Dort wurde auch von Kommentatoren darauf hingewiesen, dass im Grunde genommen ein (schwerer) Lizenzfehler ausreicht, um die GPL flächendeckend in Android durchsetzen zu können. Ein solcher Fehler gerade mit der glibc wäre hierbei sehr, sehr hilfreich.
Das setzt natürlich voraus, dass der zitierte Software-Experte bei seiner Analyse keinen Fehler gemacht hat. In der Nachricht selbst kommt mir jedenfalls noch zu oft das Wort "glauben" vor.
IMHO ist es ein anscheinend leider legales Unding, das es möglich ist, um den freien Linuxkernel herum ein durch und durch unfreies Userland bzw. unfreies Betriebssystem wie Android herumzubauen.
Userland kommuniziert über syscalls mit dem Kern. Was haben Schnittstellen mit der GPL zu tun?
Im Originaltext liest sich das so:
"And now there is grave concern over the legality of a central element of its architecture: the library that connects Android and its applications with the underlying Linux kernel. (...)
If Google is proven wrong, pretty much that entire software stack -- and also many popular third-party closed-source components such as the Angry Birds game and the Adobe Flash Player -- would actually have to be published under the GPL. (...)"
http://fosspatents.blogspot.com/2011/03/googles-android-faces-serious-linux.html
Im Text legt Müller dar, wie er sich die mögliche "Verseuchung" Androids durch den GPL-Linux-Kernel vorstellt.
Im übrigen sprach ich oben von einem "legalen Unding". Wenn aus diesem androidschen GPL-, Apache/BSD/MIT- und Closed Source-Lizenzenmix ein illegales Unding werden würde, dann wäre das schon ein Riesenproblem, zumal die meisten Android-Dienstleister ausgeprägte GPL-"Hasser" zu sein scheinen. :-)
Nach meinem Wissen gibt es einen Konsens unter Juristen welcher auch schon vor Gericht bestätigt wurde das Header Dateien im allgemeinen nicht unter das Urheberrecht fallen. Header Dateien, wenn sie nicht jede Menge Inline-Code enthalten kann am als eine Schnittstellenspezifikation betrachten. Könnte man Grundsätzlich verbieten diese zu verwenden, dann wäre Interoperabilität so gut wie überhaupt nicht mehr möglich.
Header gehören ebenso unter das Urheberrecht wie Kommentare, Makros, Inline, überhaupt jeder Art von Code. Man war sich nicht einig wie das mit der "Originalität" aussieht(Deklaration), derzeit siehts aber mehr danach aus, dass Google richtig Mist gebaut hat. Das verbessert nicht gerade Googles Position beim Prozess gegen Oracle.
Wie gesagt, Anwälte sehen das anders, siehe z.B. hier: http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html
" However, I've talked with our lawyer about one specific issue that you raised: that of using simple material from header files. Someone recently made the claim that including a header file always makes a derivative work.
That's not the FSF's view. Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work. It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that. "
Nach meinem Wissen gibt es auch Rechtsurteile die in diese Richtung gehen. Ich konnte jetzt auf die schnelle nichts online finden, aber mit etwas intensiverem Googlen wirst du sicher fündig wenn es dich interessiert.
Hab hier gerade doch noch was gefunden: http://www.winehq.org/pipermail/wine-devel/2001-February/000204.html
"Copyright law does not protect idea, just the expression of them. Several court
decisions have been rendered which suggest that the 'purely functional' elements
of a computer program are not copyrightable. There are several cases that
explicitly deal with the issue of copyright and header files. The most relevant
one for Wine development is probably the 1992 decision in Sega v. Accolade, where
Accolade reverse engineered the headers for Sega's ROM libraries in order to
develop games compatible with Sega's hardware without paying Sega's royalties.
http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html
The court in that case said:
Computer programs pose unique problems for the application of the
"idea/expression distinction" that determines the extent of copyright
protection. To the extent that there are many possible ways of
accomplishing a given task or fulfilling a particular market demand,
the programmer's choice of program structure and design may be highly
creative and idiosyncratic. However, computer programs are, in essence,
utilitarian articles -- articles that accomplish tasks. As such, they
contain many logical, structural, and visual display elements that are
dictated by external factors such as compatibility requirements
and industry demands... In some circumstances, even the exact set of
commands used by the programmer is deemed functional rather than
creative for the purposes of copyright. When specific instructions,
even though previously copyrighted, are the only and essential means
of accomplishing a given task, their later use by another will not
amount to infringement."
Das Header-Files nicht unter das Urheberrecht fallen war überigens auch einer der Hauptargumentatiosnlinien von IBM im Fall "IBM vs SCO". (http://www.groklaw.net/article.php?story=20070310204302343) Die Argumentation von IBM damals: Man kann einen bestimmten Error Code oder Funktion nur auf eine Art definieren, daran steckt keine schöpferische Höhe und damit nichts was unter das Urheberrecht fällt. Ein ganz einfaches Beispiel: Frage 100 Programmierer nach einem Header File für die Grundrechenarten (add, sub, mult, div) alle werden dir das liefern:
float add(float, float);
float div(float, float);
float sub(float, float);
float mult(float, float);
hier irgendwas unter das Urheberrecht zu stellen oder eine "schöpferische Höhe" finden zu wollen ist Absurd und wie breits gesagt und durch ein paar Links angedeutet wohl auch mehr oder weniger Konsens im juristischen Umfeld.
Gegen die pure Nutzung einfacher Header-files hätte wohl auch niemand etwas gehabt.
Aber es sind eben _keine_ einfachen Header-files, wenn sich zu viel Programmlogik drinne versteckt. Dann muss eben zur nicht-lizenzgemäßen Nutzung erst die Funktionslogik bereinigt werden.
Und was ist eigentlich mit "purely functional" gemeint? Es ist ja sicher _nicht_ die Funktion gemeint. Ich kann ja eben nicht einfach irgendwelchen Quelltext nehmen und mir beliebige "Funktionen" da ausborgen. Es ist der Funktionsaufruf (bzw. dessen Definition) gemeint. Inline-Code geht aber eben darüber hinaus.
"Doch der von Google verwendete Code enthält laut Müller mehr als solche grundlegenden Dinge. Es sollen auch komplexere Definitionen und Inline-Funktionen enthalten sein"
Bevor Google das macht sollten die sich mit allen Leuten an den Tisch setzten und eine "Lizenz" kaufen bzw. eine Spende tätigen.
Falls Du damit meinen solltest, irgendjemand könne sich von der GPL freikaufen, im Hinblick auf den Kernel geht das überhaupt nicht. :-)
Falls das im Artikel Dargestellte tatsächlich stimmen sollte (hier sind allerdings noch dicke Fragezeichen angebracht, es würde mich überraschen, wenn Google so naiv gewesen wäre, dieses Szenario nicht zu berücksichtigen und im vorhinein durchzudenken), dann muss Google ohne Wenn und Aber die GPL erfüllen.
Manche Anbieter anderer GPL-Software bieten allerdings eine Doppellizenzierung an, die man auch als "Freikaufen" verstehen könnte.