EuGH: Programmfunktionen unterliegen nicht dem Urheberrecht

SAS Institute hatte World Programming Ltd (WPL) verklagt, weil diese schon vor Jahren eine eigene Software auf den Markt gebracht hatten, die die Skriptsprache BASE SAS interpretierte und ausführte. SAS sah sein Urheberrecht verletzt und klagte. Der zuständige Generalanwalts Ives Bots plädiere wortreich zugunsten der Briten, weder die Programmiersprache, noch die Funktionen von Programmen seien durch Urheberrecht geschützt. Das Gericht (EuGH) folgte dem Urteil.

Im Kern bedeutet das, dass jedes Unternehmen Interpreter für bestehende Programmiersprachen erstellen kann. Diese Erkenntnis wirft gegebenenfalls weite Schatten, etwa in die USA, wo Google derzeit von Oracle vor den Richter gezerrt wird. Dabei geht es um die Dalvik VM von Android, die Java-Code interpretiert; Oracle ist durch den Kauf von Sun Microsystems mittlerweile Java-Eigner. Wie der amerikanische Richter im Falle Oracle/Google entscheidet, wird sich in den kommenden Wochen herausstellen. Gut möglich aber, dass Google sich schon einmal mit dem EuGH-Urteil auf den nächsten Prozesstag vorbereitet. Sicher ist, dass bei WPL heute gefeiert wird.

Kostenloses Nutzungskontingent für Amazon Web Services

Die Vielfalt der Amazon Web Services ist gelinde gesagt abschreckend, wenn man sich dem Thema Cloud Computing das erste Mal nähern will. Das liegt aber auch daran, dass die Nutzung sofort mit Kosten verbunden ist. Damit nicht allzu viele potentielle Kunden zu Konkurrenten mit kostenlosen Einstiegstarifen abwandern – beispielsweise phpfog.com -, bietet Amazon Neukunden ein Jahr lang einen Teil seiner Infrastruktur-Ressourcen kostenlos an.

Enthalten ist zuerst einmal eine Micro EC2 (Elastic Cloud) Instanz mit 750 Stunden Rechenkapazität. Wie bei Amazon üblich wird nur die Nutzung bezahlt, d.h. wenn der Server nichts zu tun hat bzw. die CPU nicht belastet wird, geht das nicht zu Lasten des Stundenkontingents. Passend dazu gibt es einen 750 Stunden Load Balancer, der sich natürlich nur lohnt, wenn man mehr als eine Instanz am Laufen hat.

Zur Speicherung von Daten und Ressourcen (Dateien) steht eine Vielzahl von Services bereit, u.a. Amazon Elastic Block Store (EBS), Amazon Simple Storage Service (S3) oder auch Amazon SimpleDB, das sich noch im Betastatus befindet. Eine Übersicht findet man auf AWS in der Rubrik EC2 – Preise:

Eine detailliertere Übersicht findet sich hier.

SPDY hält Einzug in den Firefox

SPDY ist schon seit längerem im Chrome im Einsatz – hält sich dort aber im Hintergrund. Der Browser schaltet automatisch von HTTP um, wenn Daten von einem Google Server abgerufen werden. Da SPDY wie HTTP auf TCP aufsetzt, bedarf es in der Infrastruktur keiner Anpassung, allerdings muss der Webserver das Anfrageprotokoll unterstützen. Bisher tun das die wenigsten Webserver. Aber das könnte sich bald ändern.

Wie bekannt gegeben wurde, wird SPDY in den Mozilla Sourcecode aufgenommen und soll ab Version 11 freigegeben werden – also im ersten Quartal 2012. Damit kommt der potentielle HTTP-Nachfolger weltweit schlagartig auf 50% Marktanteil. Das macht es für die Hersteller von Webservern attraktiv, sich mit dem neuen Protokoll zu beschäftigen. Google hat bereits vorgelegt und ein bislang wenig verbreitetes Modul für den Apache Webserver und auch für NodeJS veröffentlicht.

Im Wesentlichen ist SPDY dem Hypertext Transfer Protocol überlegen, weil es sich besser an den aktuellen Anforderungen orientiert. Durch die steigende Komplexität von Webseiten werden pro Seitenaufruf mehr unterschiedliche Ressourcen (Text, Grafiken, Styles, Skripte…) benötigt. SPDY kann pro Anfrage mehrere Ressourcen auf einmal anfragen, führt eine Priorisierung ein und sorgt durch Komprimierung für weniger Traffic bei gleichzeitig hoher Sicherheit (durch Verschlüsselung). Darüber hinaus kann der Webserver den Client kontaktieren, um Ressourcen nachzuliefern.

Für Neugierige: Wie Golem berichtet, lässt sich SPDY im Tree „mozilla-inbound“ bereits aktivieren. Über about:config reicht dazu ein Eintrag true bei network.http.spdy.enabled.

SAS: Streit um Programmiersprache

EU-Generalanwalt bedient sich einer Methapher, die auch schon bei der Klageschrift Pate gestanden hat: Computerprogramme sind nach EU-Recht wie Literatur anzusehen und fallen damit unter das Urheberrecht. Das Kopieren von Programmcode ist damit eine Straftat. Soweit ist das unbestritten, aber gilt das nach Ansicht von Bot nicht für die Sprache selbst: BASE SAS ist öffentlich zugänglich und vergleichbar mit der Sprache, in der ein Roman geschrieben ist – nicht mehr als ein Hilfsmittel.

Das bedeutet im Klartext: wer immer eine Software schreibt, die eine allgemein zugängliche Programmiersprache interpretiert bzw. kompiliert und darauf basierende Funktionalität ausführt, macht sich nicht strafbar. Das gilt auch dann, wenn die interpretierte Sprache bislang nur von der kommerziellen Software des Spracherfinders eingesetzt wird – solange das Programm selbst keinen Quellcode des kommerziellen Vorbild kopiert. SAP wäre demnach machtlos gegen einen ABAP-Interpreter, Oracle könnte sich erst einmal nicht gegen Java-Implementierungen wehren – die Patent-Debatte lassen wir mal aussen vor.

Dass das US-Unternehmen SAS Institute dagegen vor Gericht zieht, ist allerdings allzu verständlich: Die Exklusivität der hauseigenen Software in Bezug auf die verwendete Sprache ist ein gewichtiges Argument in der Preispolitik. Jeder Konkurrent, der BASE-PRogrammierer mit preisgünstiger Alternativ-Software versorgt, macht den lukrativen Markt der Unternehmenskunden kaputt. Allerdings gehen SAS nach dem Votum des Generalanwalts die juristischen Mittel aus. Was bleibt noch? Zum einen könnte man die Dokumentation von BASE SAS exklusiv für Kunden zugänglich machen. Damit macht man sich aber vielleicht den Markt kaputt, wo man doch traditionell auch mit Universitäten zusammenarbeitet und offenherzig Dokumente veröffentlicht. Zum anderen könnte man World Programming aufkaufen. Aber damit macht man sich erpressbar. Jedes beliebige Softwarehaus könnte auf die Idee kommen, BASE SAS zu interpretieren und auf ein Kaufangebot aus Cary zu warten. Wenn die ersten beiden Alternativen ausfallen, kann man noch mit der Patentklatsche kommen und den Konkurrenten zur Kasse bitten. Wie das geht, kann man sich von Larry Ellison von Oracle im Detail erklären lassen. Oder aber man ignoriert den britischen Konkurrenten…

Native Windows-Unterstützung für Node.js

Node 0.6 kommt für Windows mit einem MSI-Installer, der im wesentlichen nichts anderes tut, als die zentrale node.exe in den Standard-Programm Ordner zu kopieren und den Verzeichnispfad in die Umgebungsvariabel PATH einzutragen, damit der Server von jedem Pfad aufrufbar ist, ohne auf der Kommandozeile zum Standort zu wechseln. Vielleicht gerade weil die Installation so leicht ist, sieht der Wizard auch keine Notwendigkeit, dem Installateur eine Wahlmöglichkeit zu lassen, ob das PRogramm gegebenenfalls in ein anderes Verzeichnis installiert werden soll – aber wir wollen von der ersten Installerversion nicht zu viel erwarten. Nach der „Installation“ lässt sich der Server über die Kommandozeile starten.

Wer sich noch nicht mit serverseitigem JavaScript auskennt und noch eine Anleitung braucht, wie man erste Programme mit Node.js schreibt, ist bei dem Video-Tutorial von Christopher Roach bei Nettuts+ gut aufgehoben. Das Video bezieht sich bei der Installation der Software zwar zuerst auf die Unix; in Anbetracht der oben beschriebenen einfachen Installation kann man diesen Teil (die ersten 6:10 Minuten) aber getrost übrspringen. Danach implementiert Christopher in aller Kürze einen Webserver, der „Hello World“ ausgibt – ein Beispiel, das ursprünglich von der Node.js Webseite stammt – bevor er noch auf Umgebungsvariablen von Node.js eingeht. Sehenswert und eingänglich!

Fazit: Der Sprung von einem altbekannten LAMP Umfeld zu Node.js fällt erstaunlich leicht. Gerade weil JavaScript clientseitig allseits bekannt ist, ist die Einarbeitung extrem schnell. Wer jetzt Blut geleckt hat, findet weitere Video-Tutorials zum Thema bei nettuts@blip.tv.

Welche Browser besuchen meine Webseite?

Ein Blick in die Statistiken zeigt, dass Firefox in Bezug auf die Seitenzugriffe weiterhin dominiert. Für mich ein wenig überraschend finden sich die mobilen Browser auf dem zweiten Platz; hinter „Mobile Safari“ in der Statistik verbirgt sich Android, in allen Fällen die Version 2.3. Es folgen halbwegs aktuelle Versionen von Safari und Chrome und erst hinter der veralteten Firefox-Version 3.6 kommen die unterschiedlichen Ausführungen des Internet Explorers mit zusammengerechnet 14%. Abgeschlagen sind Opera, und der Firefox 5 bis 6.

Was kann man aus dem Ergebnis für Schlüsse ziehen?

Zum einen zeigen die Zahlen ein sehr europäisches Bild. Global ist die Verteilung erfahrungsgemäß eine andere, der Internet Explorer sitzt mit 40% zwar auf dem höchsten, aber einem absteigenden Ast. Darum wollen wir uns aber nicht scheren. Globale Statistiken kann man sich übrigens kostenlos bei Statcounter.com ansehen.

Viel interessanter ist, dass ich es vornehmlich mit aktuellen Browsern zu tun habe, die auch entsprechend neue Standards wie HTML5, CSS3, Websockets, Geolocation, Local Storage und derer mehr unterstützen. Rund 80% der Zugriffe zähle ich zu diesen Browsern, Grund genug, weiter konsequent auf neue Technik zu setzen und für alte Browserversionen keine Workarounds mehr zu bauen.

Auffällig ist weiterhin, dass der Firefox 3.6 noch relativ stark vertreten ist und seine Nachfolger 5 und 6 in den Schatten stellt. Ich erkläre mir das damit, dass diese mittlerweile doch recht alte Version in Unternehmen als Alternative zum Internet Explorer beliebt wurde und dort wohl immer noch im Einsatz ist. In die gleiche Kerbe schlägt meines Erachtens der IE7

Nicht vergessen: die Zahlen zum Text

Browser Anteil
Firefox 7.0 25%
Firefox 8.0 13%
Mobile Safari 4.0 13%
Safari 5.1 10%
Chrome 15.0 8%
Chrome 12.0 7%
Firefox 3.6 6%
Internet Explorer 7.0 6%
Internet Explorer 8.0 5%
Internet Explorer 9.0 3%
Chrome 17.0 2%
Opera 11.5 2%
Firefox 6.0 2%
Chrome 14.0 1%
Firefox 5.0 1%
Googlebot 2.1 1%

Release Candidate: PHP 5.4 in der Endkontrolle

Eigentlich ist es bemerkenswert: bisher war PHP für seine langen Releasezyklen bekannt. Mit der avisierten Version 6.0 hat man solange gehadert, dass letztlich nur ein Minor Release draus wird. Dass es aber kommt, ist auch dem neuen Releasemodell zu verdanken, dass die Entwicklung planbarer macht. Auf den Wikiseiten kann man nachverfolgen, wie die Planung der kommenden Wochen aussieht: Es wird demnach solange Release Candidates geben, bis der Drops gelutscht ist. Fachmännischer ausgedrückt: bis die Version stabil ist.

Was die Features von PHP 5.4 betrifft, so haben wir auf phpundmysql.de schon vorab einen Test gemacht. Zur damaligen Alpha-Zeit blieb noch viel offen, was sich mit dem RC jetzt nachtesten lässt. Fest steht: ein Mega-Feature bringt der Neuling nicht mit. Das bedeutet im Hinblick auf die ursprünglichen Pläne, es gibt z.B. keine durchgängige Unicode-Unterstützung. Dafür kommt viele überschaubare Nettigkeiten hinzu, die dem Programmierer das Arbeiten erleichtern. Da sind z.B. Traits für wiederverwendbare Methoden in unterschiedlichen Klassen, die direkte Traversierung von MySQLi Resultsets oder das Array Dereferencing. Außerdem wird noch aufgeräumt und sozusagen im Regal der PHP-Features entrümpelt.

Wer helfen möchte, die kommenden Versionen zu testen, ist herzlich eingeladen. Gefundene Fehler können im Bugtracker eingegeben und deren Behebung nachverfolgt werden.

WordPress Statistiken Marke Eigenbau

Das Plugin ist mal wieder aus der Lust heraus geboren, neue Webfundstücke auszuprobieren. Diesmal sind das ETags zur Identifizierung eindeutiger Besucher und Bluff, eine JavaScript Charting Engine von James Coglan.

Nach der Installation erscheint auf dem Dashboard im Adminbereich ein neues Widget, auf dem die Anzahl Besucher pro Tag, die Besuche pro Stunde, und jeweils eine Verteilung der verwendeten Browser und der Herkunftsländer in Line-, Bar- und Pie-Charts anzeigt. Um die Anzeige kompakt zu halten, sind die Grafiken in einem Accordion zusammengefasst. Das Herkunftsland wird auf Basis der IP ermittelt, wobei die letzten Stellen der IP aus Gründen der Anonymität mit 0 ersetzt werden.

Besucher werden über ihren Cache-Inhalt identifiziert. Dabei wird eine Datei im Cache des Browsers abgelegt und per ETag mit einer eindeutigen ID versehen. Beim nächsten Aufruf der Seite wird der Cache geprüft und die ETag-Session fortgeschrieben. Das Logging funktioniert natürlich ab dem ersten Seitenaufruf.

Installation:

  1. Die Dateien von „Apt Statistics“ in das WordPress Plugin Verzeichnis extrahieren
  2. Das Plugin über im Adminbereich aktivieren. Fertig!

Das Plugin erzeugt eine neue Tabelle in der WordPress Datenbank und sammelt darin kontinuierlich Daten. Wird das Plugin deaktiviert, wird auch die Tabelle gelöscht!! Bis dahin gesammelte Daten sind verloren.

OpenSocial mit Elgg

Die Dokumentation von Elgg – einer Open Source Social Networking Plattform – wirbt damit, über das Apache Shindig Plugin zum Container für OpenSocial Widgets zu werden. Es gibt bloß ein Problem: Im Auslieferungszustand funktioniert das Plugin nicht. Schlimmer noch, bei der Installation sind schnell alle Tipps der README verbraucht und man steht mit den auftretenden Problemen allein da. In Konsequenz scheint sich das Plugin seit 2008 nicht weiterentwickelt zu haben – im Gegensatz zu Elgg und Apache Shindig selbst. Während Shindig mittlerweile bei OpenSocial 0.9 angekommen ist (in Version 1.1), unterstützt das Plugin OpenSocial 0.7.

So recht kann man den Elgg Entwicklern keinen Strick daraus drehen. Apache Shindig erweist sich selbst nicht als simples Tool, das Einrichten geht fernab der präferierten Installation auf einem eigenen (virtuellen) Host nicht leicht von der Hand, zumal hier unterschiedliche Konfigurationsdateien anzupassen sind. Ferner bestehen Unterschiede zwischen den Versionen: nachdem ich Shindig 1.0 (OpenSocial 0.8.1) einmal als Elgg Plugin zum Laufen hatte, bin ich mit meiner selbst geschriebenen Installationsanleitung für Shindig 1.1b5 kläglich gescheitert. Im Gegenteil, dass sie bei allen Spielereien und Versuchen mit den Konfigurationen irgendwann funktionierte, war eher unerwartet. Herausgekommen ist eine Version, die keine guten Werte in den Compliance Tests erreicht (68 Tests bestanden, 40 nicht bestanden), schlecht dokumentiert ist bzw. keine ausführliche Installationsanleitung mitbringt, und in denen noch hart verdrahtete Pfadangaben existieren.

Nichtsdestotrotz kann diese Version hier heruntergeladen werden. Ich hoffe damit auf ein Publikum aus Entwicklern zu stoßen, die das Plugin mit eigenen Ideen stabilisieren und verbessern. Anstehende Aufgaben sind zum aktuellen Zeitpunkt:

  • Entfernen der hart verdrahteten Pfade (.htaccess, PHP Konfig: local.php, JavaScript Konfig: container.js).
  • Umstellen der Shindig Interfaces auf MySQL statt JSON (möglicherweise mit Partuza Code), um es mit der Elgg Datenbank zu nutzen.
  • Reload des Widgets nach Verschieben im Dashboard

CodeIgniter installieren und einrichten

Auf der Suche nach dem richtigen Framework habe ich schon die ein oder andere Alternative ausprobiert und bislang alle wieder verworfen. Einige bekannte Vertreter waren dabei, z.B. CakePHP, und viele unbekannte, denen ich eine Chance geben wollte. Mein derzeitiger Liebling ist CodeIgniter, weil sich damit bei extrem flacher Lernkurve schnell Anwendungen erstellen lassen. CodeIgniter punktet mit großem und leicht handhabbarem Funktionsumfang und komfortabler Erweiterbarkeit durch eigene Libraries (oder die Anpassung bestehender Libraries).
Den Ausschlag CodeIgniter einzusetzen hat letztlich eine Serie von Videotutorials auf Nettuts namens „CodeIgniter From Scratch“ gegeben. Die Tutorials betrachten jeweils unterschiedliche Aspekte des Frameworks, angefangen von MVC über Datenbankzugriffe bis hin zu den eingebauten Kalender- und Shop-Libraries. Jedes Tutorial beginnt mit einer frischen Installation und mit der Zeit bekommt man eine ganze Reihe von Tipps und Tricks, die man bei der Konfiguration beachten sollte.

Der Einfachheit halber hier eine Checkliste aller notwendigen oder hilfreichen Einstellungen.

Installation

  • Download des Packages und Entpacken in ein Ordner unter htdocs (in diesem Beispiel ci).
  • Verschieben des Ordners ci/system/application nach ci/application
    Dieser Schritt ist nicht notwendig, sorgt aber für eine sichtbare Trennung des Basissystems und den anwendungsspezifischen Skripten
  • Löschen des Ordners ci/user_guide, sofern er nicht noch zum Nachschlagen während des Programmierens gebraucht wird.
    Ohne die Dokumentation entpuppt sich CodeIgniter als Leichtgewicht mit knapp einem Megabyte Platzbedarf.


Konfiguration

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /ci/index.php?/$1 [L]
</IfModule>

  • Einstellungen an der Datei ci/application/config/config.php

$config['base_url']    = "http://host/ci/"; //Standardpfad für den Zugriff per Browser
$config['index_page'] = ""; //nur dann das voreingestellte index.php entfernen, wenn die .htaccess verwendet wird
$config['encryption_key'] = "fzDfe64dsL§dsiitDvFoFD%3DrekDw1!"; //zufälliger Schlüssel für encode/decode Funktionen und die Sessionverschlüsselung
$config['sess_cookie_name']        = 'ci'; //Name passend zur Webseite
$config['global_xss_filtering'] = TRUE; //Automatische sicherheitsbedingte Eingabeprüfung

  • Festlegen der vorab geladenen Libraries, Helper, Models, etc. in der Datei ci/application/config/autoload.php
    Normalerweise werden benötigte Features in den Methoden der Controller per $this->load geladen. Anstatt eine häufig benutzte Library aber in jedem Controller einzeln einzubinden, z.B. die Datenbankanbindung, kann man diese zentral laden lassen.
  • Pflege der Zugangsdaten bei Verwendung einer (relationalen) Datenbank wie MySQL in der Datei ci/application/config/database.php

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "";
$db['default']['password'] = "";
$db['default']['database'] = "";

  • Definition des Controllers, der standardmäßig, also bei Aufruf von http://host/ci angezeigt wird (Einstellung in ci/application/config/routes.php)
    Im Auslieferungszustand enthält CodeIgniter einen beispielhaften Controller namens Welcome, der lediglich eine Nachricht im Browser ausgibt. Diesen kann man getrost löschen, muss dann aber in der routes.php Datei eine Alternative angeben.

$route['default_controller'] = "controllername"; //Standard ist welcome