Leitung Detlef Borchers
 
 
 

Patrick Hausen: Ja, mir fiel gerade an dem letzten Bild auf: Die Vererbungscharakteristik von Lizenzmodellen. Die trifft meines Erachtens in der Form gerade auf kommerzielle Lizenzen nicht zu, in dem Sinne, daß kommerzielle Lizenzen sich nicht auf das Gesamtprodukt ausdehnen. Das sieht, denke ich, folgendermaßen aus: Wenn ich eine frei verfügbare Software schreibe, irgendein Progrämmchen, das unter X läuft, nehmen wir den frühen GIMP, und dieser GIMP verwendet die Motif-Library -- Motif ist ein kommerzielles Produkt; das gibt es nur in binary Form, gegen Geld -- dann ist es eben nicht so, daß die Lizenz dieses Motif-Toolkits sich auf den gesamten GIMP überträgt. Ich kann weiterhin meine Quellen für den GIMP als Open Source ins Netz stellen, und jeder kann sich die runterladen und kann mit seiner selbst gekauften Lizenz von Motif diesen GIMP linken. Überhaupt kein Problem, ganz im Gegenteil. Dagegen hat die GPL, die GNU General Public License, den Anspruch, sich auf das gesamte Produkt zu übertragen. Das ist ein bißchen Interpretationssache, aber Richard Stallman, den wir ja morgen noch hören werden zu dem Thema, hat eben immer wieder ganz klar gesagt, daß das so beabsichtigt und intendiert ist. Das heißt, wenn ich eine GPL-Library, wie beispielsweise Readline in mein Produkt hineinlinke, dann bin ich gezwungen, den gesamten Rest ebenfalls unter GPL zu stellen. Das heißt, ich kann kein Produkt bauen, was z.B. Motif und Readline miteinander kombiniert, weil ich nicht in der Lage bin, Motif unter GPL zu stellen. Also ich glaube, hier wurden die infektiösen Charakteristiken der verschiedenen Lizenzen ein bißchen vertauscht. 

Publikum: [unverständlich] 

Patrick Hausen: Das Argument war, daß man mit der Readline-Library ja auch dynamisch linken kann, weil wir jetzt moderne Betriebssysteme haben, die in der Lage sind, sich das, was unter Windows eine DLL [Dynamic Link Library] ist, eben auch im Unix-Bereich als dynamisch gelinkte Libary zur Laufzeit zu laden, kann eben der Benutzer sich die Readline-Library selbst installieren und ich kann meine gesamte Open Source-Software oder auch meine kommerzielle Software ohne die Readline-Library vertreiben und damit dem GNU-Copyleft Genüge tun. Das Problem ist meines Erachtens nur, daß erstens von Seiten der FSF und Richard Stallman eine Bewegung weg von dieser Library General Public License geht, hin zur GNU General Public License, daß er also Entwickler ausdrücklich auffordert, für Librarys, für kleine Toolkits, die man eigentlich in einer Applikation nur hinzulinkt, wo die Kernarbeit in der Applikation liegt, daß man dafür die GPL verwenden soll. Und er hat nochmal klargestellt, daß auch dynamisches Linken im Sinne der GPL aus dem gesamten Softwareprodukt ein derivative Work macht. Dieses derivative Work -- das ist praktisch der Schlüsselsatz der GNU General Public License, der sagt: Wenn Sie ein Stück Software, das unter der GPL ist, in ihre eigene Software einbauen, dann wird die gesamte Arbeit, die Sie gemacht haben, automatisch eine aus der GPL-Software abgeleitete Arbeit, und damit gilt die GPL für alles, was Sie getan haben. So interpretiere ich das im Moment. Und so ist es eben schwierig, GPL-te Open Source-Software in kommerziellen Produkten mit anderen Teilen, sei es mit Treibern, die unter Non-disclosure-Agreement sind, sei es mit Librarys, mit einer Oracel-Datenbank-Library oder mit Motif oder was immer zu kombinieren, um ein Gesamtes zu entwickeln. Mir bleibt letzten Endes nichts anderes übrig, als den GPL-ten Teil komplett neu zu schreiben. 

Publikum -- Florian Cramer: Zwei Fragen. Die erste geht vor allem an die kommerziellen Linux-Distributoren: Wie sichern die sich juristisch ab? Um noch einmal dieses leidige KDE-Qt-Beispiel zu zitieren: Es ist ja unter der modifizierten Qt Public License, QPL, die mit KDE und Qt 2.0 in Kraft tritt, nach wie vor noch so, daß in dem Moment, wo ich kommerzielle Software basierend auf dieser Library entwickle, ich auch eine kommerzielle Lizenz zahlen muß. Jemand, der sich z.B. eine SuSE-Distribution oder eine RedHat kauft, sieht das nicht. Die Library ist in der Distribution drin. Man könnte erst einmal davon ausgehen, daß man mit diesem System auch entwickeln kann. Es können also versteckte Folgekosten in dieser Distribution schlummern, die weit über diese hundert Mark für die CD hinausgehen. Das war die erste Frage: Wie gehen die Distributoren damit um? Gibt es da auch juristische Überlegungen bezüglich der Kompatibilität der verschiedenen Lizenzmodelle, die so in einer normalen Linux-CD schlummern? 

Punkt zwei: Wie verträgt sich diese Vorstellung vom Linken von Code und Kombinieren von verschiedenen Lizenzen eigentlich noch mit verteilten Objektmodellen? Wenn wir z.B. CORBA-Objekte haben, meinetwegen ein CORBA-Objekt aus GNOME, einer GPL-Anwendung, das z.B. über ein anderes Objekt eine Oracle-Datenbank abfragt -- funktioniert das überhaupt noch? Sind diese Vorstellungen des Code-Links nicht eigentlich veraltet und für moderne Programmansätze nicht mehr zu gebrauchen? 

Dirk Hohndel: Also, aus Sicht eines Linux-Distributors: aus der Frage, welche Auswirkungen die Lizenzen der auf unseren Distribution vorhandenen Libraries und Toolkits auf die Arbeit des Endbenutzers haben, können wir uns natürlich nur herausziehen. Bei einem Hundert-Marks-Produkt können Sie nicht erwarten, daß jedes einzelne Paket -- und das sind ja weit über Tausend -- von uns mit einer Lizenz versehenen wird, oder daß wir die Hersteller dieser Pakete zwingen könnten, es mit einer Lizenz zu versehen, die Sie als Käufer von jeglichen Verpflichtungen freistellt. 

Kalle Dalheimer: Vielleicht speziell noch zu dem Thema: Gerade SuSE hat ohnehin Qt aufgeteilt in die Bibliothek selbst und in die Header-Dateien. Und wenn Sie während der Installation eines SuSE-Systems nur die Bibliothek installieren, passiert nichts weiter, und Sie können dann ja auch nicht aufs Glatteis kommen. In dem Moment, wo Sie das Paket mit den Header-Dateien ausfrieren, poppt so eine kleine Box hoch, wo drin steht: 'Beachten Sie bitte die Lizenzbedingung'. Sich die durchzulesen, ist dann in Ihrer Verantwortung. 

Publikum: Ich möchte gerne fragen, wann diese ganzen Lizenzen dann eigentlich zum Problem werden. Wenn ich das richtig verstehe, sind sie ja eigentlich mal dafür gemacht worden, daß man als Privatmensch nicht-kommerziell die Software einfach benutzen kann und es verhindert wird, daß irgendein böser Geschäftemacher sich das Werk von anderen zu Nutze macht. Nun ist aber die Frage -- mittlerweile gibt es ja wirklich so ein babylonisches Lizenzgewirr --: wann wird es denn eigentlich zum Problem? Wenn ich Privatmann bin und nur ein bißchen Linux benutze? Wenn ich rumsurfe oder wenn ich z.B. weitergehe, ich mach einen kleinen Internetserver mit nur privaten Homepages oder dann doch kommerziell? Keiner weiß ja nun wirklich genau, wann welche Lizenz zutrifft. Keiner hat auch die Zeit und die Möglichkeit, die sich alle durchzulesen und auszuwerten. Dafür könnte man wahrscheinlich ein ganzes Heer von Juristen festanstellen. Oder ist es überhaupt ratsam zu sagen: 'Ist mir eigentlich egal. Wenn jemand Software frei zugänglich macht auf FTP-Servern, muß er eben damit rechnen, daß irgendwelche Leute sie vielleicht benutzten, auch wenn er da eine schöne Lizenz schreibt.' Oder sollte man sehr darauf achten? Gibt es Leute, die hinterherrennen und da eine Kontrolle durchführen? 

Marc Lehmann: Zu den Lizenzen wollte ich mal ganz allgemein sagen: Sie sind sehr unterschiedlich. Die GPL verfolgt ja völlig andere Ziele, als die BSD-Lizenz. Und das Problem, welche Lizenz ich für meine Programme benutze, und welche Programme ich als Entwickler vielleicht benutze und mir damit eine Lizenz importiere, ist eine sehr wichtige Frage. Heutzutage denken die meisten Leute: 'Ja, das ist Open Source.' Und die denken dann: 'Wenn ich meinen Quellcode mit verkaufe, ist das dann auch richtig im Sinne von Open Source und im Sinne der GPL.' Aber man muß sich speziell bei der GPL vergegenwärtigen, daß sie ja ein ganz spezifisches Ziel verfolgt. Die GPL wurde meines Erachtens nicht dafür geschaffen, den Autor irgendwie zu schützen oder die Software zu verbreiten, sondern sie wurde speziell zu dem Ziel geschaffen, daß die Software frei bleibt, frei verfügbar für jedermann. Und daher kommt ja auch dieser Anspruch: 'Wenn ich die GPL benutze, dehnt sie sich auf das gesamte Produkt aus.' Und das ist das, was viele Leute auch mißverstehen an der GPL. Die denken: 'Super, ich mach ein GPL-Produkt und dann bin ich sicher.' Aber das stimmt nicht. Das einzige, was sicher ist, ist die Software. Und das einzige, was daran sicher ist, ist daß kein Mensch sie wegschließen darf. Mehr macht sie eigentlich nicht. 

Sebastian Hetze: In der Frage nach irgendeinem Punkt, wo Lizenzen Probleme aufrufen, ist ein bißchen der Eindruck entstanden, als könnte in der Anwendung von freier Software ein Problem liegen. Das ist ziemlich sicher nicht der Fall. Für die Anwender erlaubt freie Software die Anwendung in allen Bereichen, wo eben so eine Software einsetzbar ist. Es wird niemals ein Problem geben, den Apache-Webserver für kommerzielle Zwecke oder auch die Qt, das KDE, im Office-Bereich einzusetzen. Die Fragestellung mit den Lizenzen taucht erst in dem Moment auf, wenn Sie selber entwickeln, wenn Sie freie Software als Grundlage für eigene Entwicklungen nehmen. Der heikle Punkt, der ja gerade schon angedeutet wurde, tut sich nur an der Stelle auf, wo ich Bibliotheken, also Funktionssammlungen sozusagen, die GPL-Code enthalten, in eigenen Projekten einsetze und dann das größere Ganze als abgeleitetes Werk diese GPL-Codes verstanden werden kann. Und da sagt die GPL ganz klar: 'Dann ist dieses abgeleitete Werk auch unter die GPL zu stellen. Dann müssen auch die Sourcen veröffentlicht werden usw. ' Es gibt -- ganz wichtig und klar und auch zu diesem Zweck wirklich deutlich formuliert -- die Library-GPL, die eben sagt: 'Die Bibliotheken -- mal abgesehen von der Readline, die da eine Ausnahme darstellt, aber der Großteil der Bibliotheken, die bei einem Linux-System eingesetzt werden, sind ja eben unter der Library-GPL -- darf ich ohne weiteres auch in eigenen Entwicklungen, auch proprietären Entwicklungen, verwenden. Die exakte Formulierung für die Bedingung ist, daß ich dem Anwender ermöglichen muß, das Binary gegen neue Versionen der neuen Library zu linken. D.h. nach den eigentlichen Forderungen ist es so, daß ich ein prä-gelinktes Objekt-File, ein Archiv sozusagen, mit den proprietären Programmodulen ausliefern muß, und dann dieses Objekt-File praktisch gegen jede neue Version der unter der Library-GPL stehenden Library gelinkt werden darf. Da kann man sicherlich drüber streiten, ob das dynamische Linken das erfüllt oder nicht. So wie ich das sehe, ist es schon die Intention der Mehrzahl der Entwickler, die GPL-Software machen, daß natürlich das dynamische Linken genau diesen Tatbestand der Ersetzbarkeit der Bibliothek erfüllt. 

Patrick Hausen: Ich habe ganz kurz noch mal eine Klarstellung zum Thema Library-GPL und GPL. Es ist nicht davon abhängig, ob es sich bei dem per Copyright oder GPL geschützten Werk um eine Library handelt oder nicht. Es handelt sich hier um zwei verschiedene Lizenzen, und ich kann eine Library als Autor sowohl unter die GPL, als auch unter die Library-GPL stellen. Entsprechend unterschiedlich sind die Auswirkungen, die das Ganze letztendlich bei einem anderen Entwickler hat. 

Dann wollte ich noch auf die Frage aus dem Publikum eingehen: Wann kann das zum Problem werden? Es kann immer dann zum Problem werden, wenn irgendjemand klagt. Auch die Frage: Wie ist das mit CORBA-Modellen? Wir wissen es schlicht und ergreifend nicht, weil es noch nicht in der Praxis erprobt wurde. Das ganze Copyright ist eigentlich auf Software nicht wirklich applizierbar, weil es immer nur den Ausdruck, und nicht die Ideen schützt. Aber es ist das einzige Werkzeug, das wir im Moment für Software haben, weil es keine Software-Patente oder ähnliche Regelungen gibt. Nun hat die GPL ja ganz starke Ziele, nämlich eben die Aufhebung des Copyrights für den gesamten Software-Bereich. Das ist das politische Ziel, das hinter der GPL steckt. Es ist ja auch in Ordnung, wenn man sich das setzt. Man muß sich nur überlegen, ob man dahintersteht oder nicht. Wir werden, aber nur in einem praktischen Prozeß, irgendwann herausfinden, wo was ist und wo nicht. Ein Problem ist z.B. schon mal aufgetreten: Die Firma NeXT ist da reingetappt, salopp gesagt. Die haben für den GCC-Compiler Objective C-Erweiterungen geschrieben und gedacht, sie können das eben in ein separates Modul abspalten und diese Objective C-Erweiterungen für sich behalten, bzw. nur das Modul ausliefern, nicht den Source Code. Und das ist eben nach der GPL, weil die Anwälte von NeXT die nicht genau genug gelesen haben, nicht möglich und da wurde geklagt. Und seitdem freuen wir uns über die schönen Objective C-Erweiterungen in GCC, die NeXT uns gesponsert hat. 

Sebastian Hetze: Eine Korrektur: Es ist nicht so, daß die FSF oder irgendjemand mit der GPL beabsichtigt, die Copyright-Gesetze auszuhebeln. Der Punkt, wo sich die FSF und sehr viele Leute in der gesamten Free Software Community engagieren, ist das Patentrecht. Da ist es so, daß gerade in Europa zur Zeit Bestrebungen im Gange sind, unter anderen auf Druck der US-Konzerne, Software-Patente zuzulassen. Und genau das gilt es zu verhindern. Es gibt in den USA und weltweit eine Initiative, um auch in den USA Software-Patente wieder abzuschaffen. Das Copyright ist auf jeden Fall nichts, was von der FSF oder von sonst irgendjemandem angegriffen wird, sondern ganz das Gegenteil ist der Fall: Die FSF bietet sich an, das Copyright für freie Software zu übernehmen, um genau dieses Copyright, also das Urheberrecht der Autoren an ihren Werken besser schützen zu können. Das ist durchaus im Sinne der freien Software. Also, da muß man ganz klar zwischen Urheberrecht, Lizenzrecht und Patenten trennen. Das sind unterschiedliche Dinge. 

Publikum: Ich habe noch eine Frage zum Bereich kommerzieller Software, weil wir hier gerade jemanden von der Firma Intershop haben. Wie sieht denn das eigentlich aus, wenn z.B. ein Entwickler der Firma Intershop ganz unwissentlich einen GPL-Teil zu dem Binary hinzulinkt? Was kann dann z.B. die Firma Intershop machen, und wäre es nicht auch sinnvoll, durch eine unabhängige Institution z.B. alle kommerziellen Produkte zu auditen oder zu überprüfen, ob da überhaupt Copyright-protected Source oder GPL-Source verwendet wurde, um a) den Hersteller in Sicherheit zu wiegen und b) auch zu verhindern, daß hier Arbeit von anderen Leuten für kommerzielle Zwecke ausgenutzt wird? 

Marc Lehmann: Intershop darf das natürlich so lange machen, und es passiert auch überhaupt nichts, solange sie das Produkt nicht rausgeben. Sowie sie das Produkt dann herausgeben, ist klar, muß man das auch erst einmal herausfinden. Das ist ja schon mal so ein bißchen bei Be passiert. Die haben ja da GPL-Quellen eingebaut, und das wurde dann auch recht schnell herausgefunden. Dann bleibt natürlich nur, wenn man das herausfindet, der Weg der Klage gegen Intershop. Und das kann grundsätzlich nur der Autor tun oder derjenige, der das Recht an der Software hat. Das kann also nicht die FSF für einen machen. Das geht bei FSF-Programmen wie GCC, aber wenn ich irgendeine Bibliothek schreibe oder irgendwas und sie verwenden das, dann müßte ich persönlich gegen sie klagen. Das kommt recht selten vor, und dann ist immer die Frage der Beweislage. 

Und das mit dem Monitoring: Gute Frage. Also, eine Firma, die das macht, muß sich immer überlegen, daß die Software dann geliefert ist. Sie müssen den Quellcode herausgeben, d.h. die Gefahr ist sehr, sehr groß. Und wenn sie das dann trotzdem machen, sind sie selber schuld. Aber es ist eine sehr, sehr große Gefahr für die Firma. 

Publikum: Ich sehe gerade ein bißchen die Gefahr, daß wir uns in die Winkel des Lizenzrechts verzweigen. Diese zwei Stunden waren eigentlich vorgesehen für eine etwas generellere Diskussion. Die Frage des billigen Outsourcings ist ja eigentlich eine gesellschaftspolitische Frage. Und ich würde einen kühnen Versuch machen, ein bißchen zurückzulenken, weg vom Lizenzrecht, das Sie uns als Ebene vorgegeben hatten und hin auf diese etwas allgemeineren Fragen. Mich hat sehr gewundert, daß auch die Vertreter der kooperativen Projekte sich eigentlich hier dargestellt haben wie Firmenvertreter. Zwar natürlich nicht mit einem kommerziellen Hintergrund, aber mit einer Rhetorik, die doch sehr eine Marketing-Rhetorik war: 'Bei uns läuft alles prima. Wir müssen nur noch größer werden. Es herrscht eine große Einigkeit. Und wir achten auf Qualität.' Das war so die Selbstdarstellung. Was mich viel mehr interessiert hätte, klang nur in dem einen Vortrag etwas an: Das sind nämlich innere Konflikte innerhalb dieser kooperativen Projekte, weil mir die sehr viel plastischer machen, was eigentlich kooperative Projekte sind und wie da die Friktionen und auch die Entscheidungsprozeße laufen. Allein die Versicherung: 'Bei uns gibt es keine Gurus', weiß ich aus meiner Erfahrung kooperativer Projekte schlicht zu dementieren. Das gibt es nicht, sondern selbstverständlich gibt es irgendwelche Prozesse, wie sich Hierarchien und auch Entscheidungshierachien herausbilden. Mich würde also von den Vertretern der freien Projekte interessieren: Wie entscheiden Sie Konflikte? Wenn also zwei Entwicklungsstäbe sozusagen an einem Problem sitzen, werden die beiden Produkte ja entweder nebeneinander in das Endprodukt gestellt oder es wird irgendwie entschieden. Da würde mich interessieren, wie es entschieden wird. 

Und das Zweite, ist auch eine Frage an die freien Projekte. Daß die Kommerziellen sich von den Freien nicht eingeschränkt sehen, haben wir gehört. Wie ist es umgekehrt? Sehen die Freien sich nicht mißbraucht von den Kommerziellen, weil die Kommerziellen ja ganz prächtig damit verdienen, daß es die Freien gibt? Die können die Sahnehäubchen aus der freien Szene abschöpfen und sie in klingende Münze umsetzen. Da sehe ich ein ganz erhebliches Konfliktpotential, natürlich an den unterschiedlichen Konfliktlinien der einzelnen Firmen verschieden. Intershop selber hat ein klares Profil. Da wird sich keiner wundern. Aber bei den anderen ist das Verhältnis zur freien Szene sicher problematischer. Die beiden Fragen gehen also an die kooperativen Projekte. 

Dirk Hohndel: Also, ich kann gerne zu beiden Fragen ein bißchen was sagen. Zum Thema XFree86: Wir haben ein Core-Team. Das ist ein Konzept, das es in sehr vielen freien Projekten gibt. D.h., es ist ein Team, das theoretisch die Entwicklung leitet. So ein Team rekrutiert sich meistens aus den Leuten, die entweder schon am längsten daran arbeiten oder sehr viel daran gearbeitet haben oder heute am aktivsten sind. Innerhalb dieses Core-Teams werden Entscheidungen gefällt über die Entwicklungen: Welche Richtung will man gehen? Welche Lösungen will man wählen? Wie will man das Design steuern? Selbstverständlich gibt es auch innerhalb eines Core-Teams mal Meinungsverschiedenheiten, aber das wird eigentlich sehr einfach demokratisch geregelt. Es ist eigentlich auch sehr selten so, daß in diesen Projekten wirklich Zerreißproben entstehen, daß einer sagt: 'Ich will A', und der andere sagt: 'Und ich will nicht-A', und keiner kann irgendwie die Punkte des anderen sehen. Zumindest hab ich das in den Projekten, in denen ich in den letzten acht Jahren beschäftigt war, noch nicht erlebt. 

Zur Frage des billigen Outsourcing, und ob sich die Freien da nicht ausgenutzt fühlen: Ich habe damit jetzt schon ein kleines Problem, weil ich natürlich beide Hüte trage. Denn ich bin auf der einen Seite Core-Team-Member von XFree86, auf der anderen Seite Vorstand der SuSE Rhein-Main AG. Es war eine sehr interessante Situation auf der Linux-EXPO in Durham im letzten Jahr, als genau diese Frage aufgeworfen wurde und man versucht hat, unter den Entwicklern diesen Aufruhr zu erzeugen. Und die einzigen, die sich wirklich aufgeregt haben, waren Reporter, die meinten, da muß doch ein Konflikt sein. Interessanterweise ist es so, daß die meisten Entwickler sagen: 'Oh Klasse, jemand verkauft meine Software. Das ist doch toll.' Ich freue mich wahnsinnig über jeden, der XFree86 einsetzt. Und als NCR vor vielen Jahren als erste Firma gesagt hat: 'Wir benutzen euren Server in unseren kommerziellen Unix-System. Habt ihr damit ein Problem?' Da war unsere Antwort: 'Oh, super, klasse! Dürfen wir das anderen erzählen?' D.h., wenn ich diese Auffassung hätte, daß ich mich ausgenutzt fühle, dann würde ich das nicht machen. Ich meine, wenn ich das Bedürfnis habe, daß ich für jede Zeile Code, die ich schreibe, Geld sehen will, dann würde ich wahrscheinlich nicht anfangen, freie Software zu entwickeln. Und da ich freie Software entwickle, heißt das wohl, daß mein Ziel es nicht ist, diese Software in ihrer Benutzung einzuschränken. Dementsprechend habe ich überhaupt kein Problem, wenn meine eigene Firma oder eine andere Firma meine Software benutzt, ganz im Gegenteil. Ich werde versuchen, das zu unterstützen. Ich werde diesen Leuten Support geben, soweit ich das in meiner Zeit kann. 

Kalle Dalheimer: Wir sind heilfroh, daß es Linux-Distributoren gibt, die mit -- in unserem Fall -- KDE Geld verdienen. Glauben Sie wirklich, ich hätte Lust, Pappkartons produzieren zu lassen, CDs pressen zu lassen und Telefon-Support zu machen? Also, ganz ehrlich gesagt, nicht. Da bin ich heilfroh, daß es Firmen gibt, die so etwas machen, so daß wir uns im Wesentlichen auf die Entwicklung konzentrieren. Und seit sämtliche wichtigen Linux-Distributionen KDE in ihren Distributionen aufgenommen haben und auch für ihre Kunden Support anbieten, hat sich die Support-Last bei uns trotz ständig steigender Anwenderzahlen deutlich verringert. Also da können wir nur heilfroh darüber sein, daß es so ist. 

Lars Eilebrecht: Ich kann dem im Prinzip auch nur beipflichten. Beim Apache-Webserver ist es ja auch so: Wir haben ein Core-Team, und es gibt gelegentlich schon mal Reibereien oder Meinungsverschiedenheiten. Dabei ist es aber vom Prinzip her uninteressant, ob die Person, die damit irgendein Problem hat, von einer Firma ist oder ob sie privat bei der Apache-Group dabei ist. Wir haben zwar vom Prinzip her, ich will nicht sagen Kooperationen, aber Firmen mit in der Apache-Group dabei, aber in Form eines Vertreters dieser Firma. Das heißt z.B., IBM ist mit dabei, Siemens und Apple demnächst. Aber sie haben im Prinzip bei Abstimmungen, oder wenn irgendetwas entschieden werden soll, jeweils nur eine Stimme. Im Fall von IBM sind es mittlerweile zwei, aber das ist ein anderes Thema. Aber, wenn die meisten anderen Mitglieder etwas dagegen haben, daß bestimmte Änderungen gemacht werden oder bestimmte Entscheidungen nicht gewollt sind, dann haben die keine Chance, das irgendwie durchzusetzen. Dann müssen sie entweder aussteigen oder akzeptieren, daß es nicht gemacht wird. Bisher bin ich eher positiv eingestellt gegenüber solchen Kooperationen. Gerade bei IBM ist das Engagement sehr groß. Sie haben selber ein mehrköpfiges Development-Team, und sie entwickeln nicht nur Teile, die für sie, für ihre Produkte interessant sind, sondern es kommen auch Änderungen von IBM, die generell andere Sachen vom Apache betreffen. Gut, sie benutzen den Apache an sich als Basis für ihr Produkt, insofern sind natürlich generell die Sachen interessant. Aber was auch der Fall ist, nehmen wir eine Bug-Report-Datenbank: Da herrscht auch oftmals ein Mangel an Leuten, die sich um diese Bug-Reports kümmern, weil es sehr, sehr viel geworden ist in den letzten Monaten, in den letzten Jahren. Und IBM ist auch da mit mehreren Leuten vertreten, die sich darum kümmern, Bug-Reports zu bearbeiten. Das sind dann in vielen Fällen Sachen, die IBM-Rechner betreffen, aber gerade dafür sind sie ja die Spezialisten. 

Publikum: Ich hätte noch einmal eine Frage bezüglich der Konfliktbereinigung innerhalb solcher Teams. Es wurde während der Vorträge doch immer betont, daß der Split eines Entwicklerteams das Schlimmste ist, was einem Open Software-Projekt passieren kann. Ich bin der Meinung, daß, ganz im Gegenteil, die Möglichkeit, sich jederzeit abzusetzen und den eigenen Krempel zu machen, diese gesamte Open Software-Szene doch überhaupt antreibt und verhindert, daß unwartbare Mammutprogramme entstehen und Personen, die Verantwortung für Programme tragen, sich nicht mehr darum kümmern. Bestes Beispiel ist dieser GCC gewesen, der nach einem Split zum EGCS wurde und jetzt offiziell wieder von EGCS zu GCC umgetauft wird. Das Beispiel Emacs ist auch zu nennen. Und es gibt genügend andere Beispiele, wo gerade so ein Split von Entwicklerteams doch sehr heilende Wirkung auf die gesamte Entwicklung von Open Source hatte. Wie steht man hier generell gegenüber solchen Splits? 

Patrick Hausen: Ja, meine Meinung zu dem Thema ist, daß das auch sehr stark davon abhängt, wie es dem Projekt dann in diesem gespaltenen Zustand geht. Das kann zum Tod eines Projektes führen. Das kann aber auch sehr fruchtbar sein. EGCS ist ein gutes Beispiel. Und wir leben ja jetzt im BSD-Bereich seit ein paar Jahren mit drei verschiedenen Gruppen, die hier die Entwicklung voran treiben und das auch sehr, sehr gut. Die haben unterschiedliche Schwerpunkte. Die Entwickler reden alle miteinander, und Austausch von Code zwischen den verschiedenen BSD-Systemen findet auch mehr oder weniger frei statt. Man guckt sich also an, ob bei der anderen Gruppe was entwickelt wird, was einem gut in den Kram paßt und integriert das, eventuell nach Rücksprache oder macht Vorschläge. Das kann durchaus zur gegenseitigen Befruchtung führen, wie auch das Verhältnis von Linux und BSD, wo durchaus auch Ideen, wenn auch nicht Code, aus Copyright-Gründen, aber doch auch Ideen und technische Informationen übernommen werden. Das ist überhaupt kein Thema. 

Ich wollte noch ganz kurz zu der Frage von vorhin sagen: Abgesehen von dem berühmten Aufsatz von Eric Raymond mit der Kathedrale und dem Basar, hab ich im vergangenen Jahr einen gelesen, dessen Autor mir leider entfallen ist. Man möge mir das verzeihen. Das Thema ist ein bißchen utopisch: 'Das Ende der Geldökonomie und der Beginn der Aufmerksamkeitsökonomie'. Wenn wir die Frage: 'Warum sind wir hier oder warum lassen sich freie Software-Entwickler "ausnutzen"?', beantworten möchten: Es ist eben ein sehr gutes Gefühl oder es ist ein Wert, den man bekommt, wenn man positives Feedback erhält, wenn man gesagt bekommt: 'Hey, das ist toll, was du an diesem Projekt machst. Das ist Wahnsinns-Software. Du bist ein super Programmierer.' Dann ist das schon mal sehr, sehr gut für das Ego. Und Leute, die gut sind im Software-Entwickeln, brauchen sich über die grundlegenden wirtschaftlichen Bedürfnisse meistens ohnehin keine Sorgen machen. Das heißt: Die haben alle Jobs oder spätestens, wenn sie ein solches freies Software-Projekt erfolgreich gemanagt haben. Das heißt, statt Geld-Feedback gibt es hier Image und Ruhm als Feedback, mehr oder weniger. Das erklärt auch, warum man in den Präsentationen, so ein bißchen business-like auftritt. Es geht um mind share, um Anteil daran, daß man Aufmerksamkeit bekommt. Und das bedeutet natürlich, daß man auch ein bißchen Marketing machen muß, d.h. wenn man für BSD an Promotion überhaupt nichts tut, während Linux die ganze Presse bekommt, dann verschwindet BSD irgendwann, weil man ja auch keine weiteren Software-Entwickler und Helfer bekommt. Umgekehrt muß das Linux-Thema gepuscht werden. Wenn es nicht so gepuscht worden wäre in den letzten Jahren, dann säßen wir jetzt nicht hier auf dieser Konferenz. Und das erklärt auch diese durchaus professionell gestalteten Auftritte. 

Publikum: Das ist sehr angenehm zu hören, daß sowohl von Entwicklern als auch von Firmen das Verhältnis als gut angeschaut wird betreffs Weiterverwendung von freier Software für kommerzielle Produkte. Im Gegenzug halte ich es für sehr wichtig, daß Firmen, die viel freie Software benutzen, sich dafür verdient machen, dieses sehr freie Klima, was wir in Europa haben, auch beizubehalten. Konkret meine ich damit, daß wir, was ja auch schon eben angesprochen wurde, in diesem und im nächsten Jahr Entscheidungen zu erwarten haben bezüglich Patente auf Software in Europa. Im Moment gibt es da noch nichts. In der Münchener Konvention sind Software-Programme von Patenten ausgenommen, in den USA und Japan ist es anders. Im Zuge der in anderen Aspekten sehr, sehr wünschenswerten Bereinigung des Patentwesens in Europa, wird eben auch von der europäischen Kommission darauf hingetrieben, in diesem Jahr eine Gruppe zu bilden, die einen Vorschlag bis zum ersten Januar 2001 für ein europäisches Patentrecht auf Software erarbeitet. Und es gibt dagegen auch Kampagnen, die sehr stark von Individuen und Programmierern unterstützt werden, also z.B. Freepatents.org, da ist die französische AFUL sehr aktiv. Dann gibt es auch die Gruppe FFII in München. Relativ wenig Input ist von Firmenseite gekommen. Und wenn ich jetzt hier eine ganze Latte von Firmenvertretern sehe, würde ich ganz gerne wissen, was Firmen, die viel freie Software verwenden, zu den eventuell kommenden Software-Patenten denken? 

Publikum: Das klingt alles ein bißchen merkwürdig mit diesem Ruhm und Ehre. Sie sagten: 'Die kriegen doch alle nachher einen guten Job. Sie empfehlen sich sozusagen durch ihre Open Source-Arbeit.' Das setzt aber voraus, daß es diese ganze alte Software-Industrie noch gibt. Was ist jetzt, wenn Open Source als Modell immer mächtiger wird? Wer bezahlt das? Wo kommt das Geld für diese Entwicklung her? 

Sebastian Hetze: Es gibt das GNU-Manifest, in dem das ideologische, idealtypische Modell, mit dem freie Software entwickelt wird, einigermaßen genau beschrieben ist. Da geht es letztenendes genau um den Aspekt, daß mit der freien Software gleichzeitig auch eine Dienstleistung und ein Service angeboten werden kann. Und d.h., daß beispielsweise eine Firma, die freie Software einsetzt, z.B. für die Gewährleistung, daß die Software eine bestimmte Operationalität hat, oder für die Installation oder für eine Beratung Geld zahlt. Es geht letztenendes um eine Orientierung weg davon, daß die Software als Produkt verkauft wird, hin zur Service- und Dienstleistungsorientierung, daß diejenigen, die an dieser Software arbeiten, für genau diese Arbeit bezahlt werden. Das ist eine Sache, die in einem großen Umfang noch keine Geschichte hat, weil ja genau dafür sich der Markt erst entwickelt. Das ist genau die Situation, die ich vorhin beschrieben habe. Wir haben einfach jetzt erst die Situation, daß das Management der Unternehmen freie Software überhaupt als brauchbare Alternative im produktiven Einsatz anerkennt. Das ist eine Bewegung, die von den Technikern, von unten sozusagen nach oben gekommen ist. Und an dieser Stelle ist es dann tatsächlich eine Möglichkeit. 

An dieser Motivationssache muß man auch noch auf jeden Fall ganz deutlich sehen: wenn wir uns Wissenschaft angucken, dann ist der Austausch zwischen denjenigen, die Wissen schaffen und denjenigen, die als neue Generationen von Wissenschaftlern nachfolgen wollen, ein ganz entscheidender und offener Prozeß. Und genau darum geht es bei freier Software auch. Ich verteile mit den Quelltexten ja nicht nur ein funktionierendes Programm, sondern ich verteile eben auch ganz entscheidend das Wissen über die Algorithmen. Ich verteile die Erfahrung, die Generationen von Programmierern vor mir reingesteckt haben. Und auch eine ganz, ganz entscheidende Sache: wenn ich was dazu tue, dann veröffentliche ich nicht nur für mein Ego, sondern ich setze mich auch der Kritik aus. Und da ist es ganz klar so, daß in der Welt der freien Software ein sehr positives, ein konstruktives Kritikklima herrscht, d.h., ich werde ja für einen Fehler -- Software hat Bugs --, den ich in einem Programm gemacht habe, nicht runtergemacht. Es sind ganz viele Leute da, die versuchen, Fehler mit mir gemeinsam zu beheben, d.h., ich lerne. Und das ist eine ganz wichtige Motivation für sehr viele Menschen, die sich einfach auch daran entwickeln wollen. An dieser Stelle sind die Motivationen ganz offenbar so stark, daß sie über das reine, einfache Monetäre hinausgehen. Ich muß vielleicht sogar an dieser Stelle diese Ego-Präsentation ein bißchen zurücknehmen. Es ist bei den großen Software-Projekten so, daß natürlich oben immer welche im Rampenlicht stehen, aber die vielen hundert Leuten, die nichts weiter machen, als mal einen Bugfix oder eine gute Idee reinzugeben, kriegen niemals diese Aufmerksamkeit. Also, ich habe selber viel Source Code gelesen -- mußte ich, um das Linux-Handbuch zu schreiben -- und enorm viel gelernt, und ich bin dafür enorm dankbar. Ich lese es einfach nur, um es zu lernen, weil es mich bereichert. 

Publikum: Was für Leute sind das eigentlich, die entwickeln? Jetzt haben wir hier ja die Köpfe von verschiedenen Organisationen. Was für Leute sind das? Was für Interessen vertreten die? Und wie finanzieren die sich? Davon ist schon ein bißchen angeklungen, aber es würde mich doch mal im einzelnen interessieren. 

Dirk Hohndel: Also, wir haben etwa sechshundert Entwickler, ein bißchen mehr. Und ich behaupte nicht von mir, daß ich weiß, was die alle beruflich machen. Was ich weiß, weil zufällig kürzlich erst so eine Frage durch die Listen ging, ist das wir leider Gottes im Augenblick keinen einzigen haben, der arbeitslos ist, denn den hätte ich furchtbar gerne angestellt. Und ich weiß außerdem, daß die Gruppe der Studenten verblüffend klein ist. Wir haben etwa nur ein Drittel Studenten. Ich weiß außerdem aus einer Frage, die wir kürzlich mal gestellt haben, daß etwa zehn Prozent von unseren Listen, also nicht nur die besten Fünf, sondern in unserem Fall 65 ihr Geld damit verdienen, daß sie irgendwo im Bereich Open Software angestellt sind. D.h., daß sie, so wie ich, bei einem Distributor arbeiten oder daß sie als Freelancer tätig sind oder in einem ähnlichen Bereich mit freier Software auch Geld verdienen. Ich glaube, daß die Vorstellung, daß es da eine homogene Struktur gibt, völlig falsch ist. Wir haben Entwickler von allen Kontinenten der Welt, Altersklasse 12 bis Ende 50. Das sind zumindest die Daten, die ich kenne. Da zu sagen: 'Oh, die sind alle genauso und alle gleich', das wird nicht funktionieren. 

Marc Lehmann: Das ist auch von Projekt zu Projekt äußerst unterschiedlich. Bei GCC beispielsweise ist es so, daß sehr viele, natürlich die großen, wichtigen Leute bei Cygnus und anderen Firmen angestellt sind und teilweise sogar dafür bezahlt werden, daß sie daran arbeiten. Und die kleineren Entwickler sind sehr oft Studenten und werden teilweise auch von anderen Firmen bezahlt, so von SCO: 'Ja, wir möchten auch, daß der Compiler funktioniert.' Und bei GIMP ist es z.B. so, daß wir sehr viele Studenten haben. Ich hab ja gesagt, als die beiden Originalentwickler ihren Abschluß hatten, war erstmal Stille. Der Trend geht aber dazu, daß Leute, also auch 'weniger wichtige' Leute, dann einfach als Dank von irgendwelchen Linux-Firmen eingestellt werden. Natürlich, sie wissen ja, die können programmieren, die können gute Sachen machen. Und die können dann, nicht immer, aber einen Großteil ihrer Zeit, weiter an diesen freien Projekten arbeiten. 

Publikum: Genau dazu habe ich die Frage: Wer macht denn die Hauptarbeit? Also, wenn ich höre, es gibt hundert Programmierer und die kommen von überall, Schüler, Studenten, Berufstätige, Hausmänner und -frauen, dann ist immer noch die Frage: Gut, es gibt zehn Kernentwickler, was sind das für Menschen? Gut, jeder weiß, als man zur Schule ging, da hatte man fast nur Freizeit. Wenn man dann z.B. studiert, wird es schon weniger, und wenn man arbeitet, dann beschränkt sich das nur noch auf ganz wenig Zeit, vielleicht auf's Wochenende, wo man dann wirklich Zeit hat. Wenn man programmiert, kann man das nicht täglich nur eine halbe Stunde machen, da schafft man nichts. Man braucht ja schon ein paar Stunden hintereinander, um sich reinzuarbeiten, ein Problem zu lösen. Wenn man sagt: 'Gut, die meisten haben vielleicht einen tollen Job,' schaffen die dann auch wirklich was weg in einem Jahr? Oder schaffen sie nur ein paar Bugfixes? Ich will nicht sagen, daß die unwichtig sind, aber die Frage ist doch: Wer macht die großen Features, die das Projekt wirklich weiterbringen? Und ich glaube, das sind dann doch oftmals Studenten oder vielleicht ganz speziell Angestellte von Firmen wie SuSE oder Cygnus. Aber von irgendwelchen anderen Leuten, die andere Jobs haben, ist immer die Frage, wie man sich da noch zeitlich engagieren kann? 

Publikum: Inwieweit ist die Gesellschaft davor geschützt, wieder in die Situation zu verfallen, wie bei Digital, als das noch wahnsinnig teuer war und sich eigentlich keiner so eine Maschine leisten konnte? Die Open Source ist ja nun das letzte Mittel gewissermaßen, bevor sich irgendwelche Großunternehmen bestimmte Teile in der Software, irgendwelche Zugänge, lizenzieren lassen und damit den Zugang zur Computernutzung für weite Teile der Bevölkerung vermeiden. Sind da wirklich alle Schutzmöglichkeiten ausgeschöpft oder kann die Open Source das gut abdecken? 

Patrick Hausen: Antworten möchte ich zunächst auf die Frage davor, wenigstens für das FreeBSD-Projekt. Ich muß dazu sagen, ich bin selber kein Core-Team Member, sondern gehöre zu dem Heer der kleinen Bug-Fixer und Feedback-Lieferer. Aber interessanterweise funktioniert das bei dem FreeBSD-Team ganz ähnlich wie bei mir. Ich bin hauptsächlich technisch verantwortlich für den Betrieb bei einem Internet-Service-Provider. Und wir fahren den gesamten Betrieb, abgesehen von ein paar älteren Solaris-Maschinen, inzwischen auf FreeBSD. Wenn ich da in ein Problem reinrenne, bin ich, da ich ganz gut C spreche und mittlerweile das Teil ganz gut kenne, oft alleine oder mit Feedback in der Lage, das zu lösen. Und selbstverständlich gebe ich die Lösung zurück an die FreeBSD-Gruppe. Wer macht nun die Hauptarbeit? Das sind natürlich nur Kleinigkeiten. FreeBSD kann sich den Luxus leisten, daß viele der Hauptentwickler festangestellt sind von größeren Firmen, z.B. von Walnut Creek CDROM, die ja ihren FTP-Server-Betrieb auf FreeBSD fahren, wo FreeBSD das bestgehende CD-ROM-Produkt ist. Die haben zwei Leute angestellt, die nur FreeBSD entwickeln, d.h., die Firma sponsert praktisch die Open Source-Entwicklung. Matt Dillon, mittlerweile einer Chef-Kernel-Entwickler, ist auch Technical Director bei einem der größten ISPs in Kalifornien, bei Best Internet. Und auch die erlauben ihm, damit er den Server-Betrieb am Laufen hält und es auch weiter skaliert, eben mitzuschreiben an den entsprechenden Kernel-Funktionen für virtual Memory, für SMP, für all das, was man braucht. Ein anderer sitzt bei der NASA und baut für die gerade einen Parallelrechner auf FreeBSD-Basis auf, und auch das geht alles als Feedback in das Projekt zurück. Soweit mal zum Kernel, wo wir den größten Teil an zentral anfallender Hauptarbeit haben. Bei den Utilities außenrum ist es wirklich ein Heer von Leuten, die Kleinigkeiten machen, so wie ich das hin und wieder auch tue. 

Kalle Dalheimer: Tatsächlich ist es so, daß eine ganze Reihe von Entwicklern entweder Studenten sind oder im Rahmen ihrer Anstellung das eine oder andere an KDE schreiben können. Aber wenn ich mir so angucke, wer bei uns die produktivsten Entwickler sind, dann haben viele davon einen ganz normalen Tagesjob, oft auch als Programmierer in anderen oder vielleicht auch in verwandten Dingen. Und da ist dann die Frage, wie man seine Prioritäten setzt. Ich persönlich habe die Prioritäten für mich unter anderem so gesetzt, daß ich keinen Fernseher besitze, und damit habe ich gegenüber dem statistischen Bundesbürger 28 Wochenstunden gespart. In 28 Wochenstunden kann man verdammt viel guten Code schreiben. Noch eine andere Sache ist: wenn man seinen ganz normalen Broterwerb in einer Software-Firma hat, da vielleicht eine 40 Stunden-Woche hat -- es ist ja nicht in jeder Firma so, daß es man in so irrsinnig viele Überstunden gepresst wird --, dann ist auch die Frage: Mach ich freiwillig Überstunden, um noch mehr Geld ranschaffen zu können für den zweiten, dritten, vierten Wagen oder den Wintergarten oder was auch immer, oder gehe ich lieber um 17 Uhr nach Hause und setze mich dann an ein freies Projekt? Ich habe dann immer noch ein gutes Auskommen und kann dafür noch in freier Software arbeiten. Das ist eine Frage der persönlichen Prioritäten. 

Lars Eilebrecht: Ich denke, man kann nicht sagen, daß Studenten mehr Zeit haben, als Leute, die einen festen Job haben. Es kommt auch sicherlich zum Großteil darauf an, wie die Fähigkeiten der einzelnen Personen aussehen. Wenn ich einen hervorragenden Entwickler habe, der einen Full-time Job hat und vielleicht nur wenig Zeit, kann er aber, sage ich mal, in zehn Stunden die Woche deutlich mehr leisten, als ein Student, der gerade erst angefangen hat, Software zu entwickeln, und da gelegentlich etwas macht und damit natürlich auch etwas lernt. Es ist so. Ich habe es auch erst gemerkt. Ich habe bis letztes Jahr im Oktober noch studiert. Ich hatte damals mehr Zeit, etwas für den Apache zu machen, ganz klar. Jetzt habe ich einen Full-time Job. Ich arbeite bei einem Service-Provider, aber ich weiß nicht, vielleicht bin ich ein kleines bißchen verrückt bezüglich Apache, daß ich dann doch immer noch in der Woche Zeit finde, etwas für den Apache zu machen. Ich denke, daß ist bei vielen anderen Leuten genauso. 

Dirk Hohndel: Bei uns ist es so, daß im Core-Team im Moment ein einziger Student ist. Das ist ein lieber Freund, der jetzt meines Wissens im 26. Semester Physik studiert. Alle anderen im Core-Team haben Real-Life Jobs: der typische Systemadministrator, Vorstand in einer kleinen Firma, Vorstand einer großen Firma, Vorstand von zwei kleinen Firmen, ein Arzt, ein leitender Entwickler, ein Systemarchitekt -- also ganz normale Berufe, so wie jeder andere auch. Das sind ganz normale Leute, die nach ihrem ganz normalen 60 Stunden-Wöchelchen gerne auch noch mal 20, 30 Stunden etwas machen, was Spaß macht. Ich glaube, das entscheidende Kriterium für Leute, die sehr produktiv sind und viel in solchen Projekten arbeiten, ist einfach die Faszination am Projekt. Und diese Faszination bedeutet auch sehr oft, daß man sich abends um sieben hinsetzt und noch schnell ein kleines Problem löst und auf die Uhr schaut, wenn es vier Uhr früh ist. Passiert halt. 

Publikum: Durch die Referenten und auch durch die Diskussion hat sich herausgestellt, daß im Grunde genommen freie Software etwas für Leute ist, die Langeweile haben und nebenbei ein bißchen was machen wollen, und obendrein noch für Leute, die ziemliche Koryphäen sind, die das mit der linken Hand nebenbei machen. Aber die eigentliche Frage, dachte ich, dieses Kongresses ist ja, wie die Ideen, die hinter freier Software stecken, eventuell relevant sein könnten für die Gesellschaft. Und die Gesellschaft besteht ja nicht aus Leuten, die nur Freizeit haben. Deswegen ist ja im Grunde genommen die Hauptfrage -- das ist ja vorhin versucht worden zu erklären --, wie man mit freier Software Geld verdienen kann. Wir leben nun einmal hier in einem kapitalistischen System und deswegen müssen wir zusehen, daß wir jeden Morgen unsere Brötchen auf den Tisch kriegen. Und mit Ehre kriegt man da nichts zwischen die Zähne. Wenn man sich ansieht, daß man beispielsweise mit Support Geld machen kann, dann bedeutet das aber auch, daß man neben diesem Support auch noch Zeit finden muß für die Entwicklung. Firmen, die einfach hingehen und sagen: 'Okay, ich mache jetzt nur noch Support', fahren natürlich dann auf so einer Schiene prinzipiell besser. D.h., im Grunde genommen lohnt sich doch die Software-Entwicklung für freie Software nie richtig, weil sie immer hinterherhinkt hinter anderen kommerziellen Varianten. 

Detlef Borchers: Die Frage ist: Sind Firmen, die nur Support für Linux bieten, Schmarotzer? 

Sebastian Hetze: Erstmal muß man sagen, mit Support kann man leider kein Geld verdienen. Support für Linux ist zwar etwas, das medial ganz massiv angefragt wird, was aber in der Realität bedauerlicherweise kein wirkliches Gechäft ist, weil im Internet der Support kostenlos und sehr gut und sehr schnell zu haben ist. Vor diesem Hintergrund ist das Volumen des gesamten Support-Geschäfts -- also jetzt nur Anfragen von Kunden, die Probleme gelöst haben wollen -- bedauerlicherweise sehr klein. Ich möchte jetzt allen abraten, da großartig Hoffnungen reinzusetzen. 

Frank Gessner: Ich versuche mal, so ein bißchen der Böse zu sein. Also, Geld verdienen ist nicht böse. Das muß sein. Wenn man sich mal überlegt, bei den ganzen Technologien, bei den ganzen Sachen, die sich mittlerweile herausgebildet haben, auch gerade in der Open Source-Szene und im Internet, auch bei den steigenden Geschwindigkeiten von Technologien, die jetzt immer mehr kommen, und die Power, die man braucht, um dort überhaupt noch mitzuhalten und den Anwendern Lösungen anzubieten, die die wirklich haben wollen: Was ist denn das, was erfolgreich macht, und das, was nicht erfolgreich macht? Ist es, die bessere Software-Lösung zu haben, den saubersten Code, möglichst Bug-frei zu sein, möglichst Free Software zu haben als Investment-Schutz und die ganzen anderen Attribute? Ich meine, wir haben schon viel kommen und gehen sehen. Ich komme aus einer NeXTstep-Vergangenheit heraus. Es gibt viele andere Systeme, die uns schon gezeigt haben, daß die Technologie nicht das ist, was etwas erfolgreich macht -- vielleicht etwas, das etwas anschieben kann, aber nicht das, was es erfolgreich macht. Wenn Sie heute mitnehmen: Es ist nur der Commerce, der etwas erfolgreich macht und etwas nicht -- wenn Ihre gesamten Überlegungen über Legalisierung, Lizenzmodelle, Urheberrecht, wie man überhaupt Software-Systeme im Internet organisieren muß, nicht davon getrieben werden, was im Endeffekt der kommerzielle Nutzen für die jeweiligen Actors darin ist, wird das sehr wahrscheinlich nicht langfristig sein. 

Sebastian Hetze: Kommerzieller Nutzen bei freier Software liegt natürlich in erster Linie bei den Anwendern. Die haben den Gebrauchswert, und das ist tatsächlich im professionellen Bereich ein enormer wirtschaftlicher Faktor. Und da kommt natürlich der Erfolg der freien Software her. 

Patrick Hausen: In die Richtung wollte ich gerade auch nochmal gehen. Auf die Frage von vorhin: Natürlich ist Open Source zu entwickeln letztendlich etwas, was man für Gotteslohn oder den Ruhm und die Ehre oder für Spaß am Projekt oder so etwas tut. Und es wird ja nicht proklamiert, daß die gesamte Gesellschaft anfangen soll, Open Source zu schreiben. Die meisten Leute benutzen Software. Da muß man sich mal die Zahlen angucken: Ein Produkt wie Apache, jedes Software-Produkt, sowohl die von Microsoft, als die Open Source-Produkte, sind in der Anwendung komplex, so komplex, daß die durchschnittlichen Endanwender, 'Endkunden' -- wenn wir sie auch bei freier Software mal so nennen wollen -- mit dem Einsatz letztendlich schon überfordert sind, z.B. einen Webserver erfolgreich aufzusetzen und zu betreiben. D.h., ich habe vielleicht zehn Entwickler, die diese Apache-Software für Gotteslohn schreiben. Ich habe hunderttausend Anwender. Dann brauche ich für diese hunderttausend Anwender tausend Consultants, von denen jeder hundert Anwender betreuen kann. D.h., ich habe tausend Consultants, die davon leben können, und ich habe hunderttausend Anwender, die durch den Einsatz dieses kostenlosen Webservers mehr Geld für vernünftiges Consulting ausgeben können und letztendlich ja auch wieder etwas tun mit dieser Software, was hoffentlich in der einen oder anderen Form Umsatz generiert. 

Publikum: Ich würde gerne noch einmal eine Meinung hören zu Software-Patenten. Ich weiß nicht, ob das jedem bewußt ist: Wenn sich da nichts tut, kann es sein, daß in einem Jahr eine Situation hier in Europa herrscht wie in Amerika. Man schreibt ein Stück Software, veröffentlicht das unter der GPL, es verstößt gegen ein Patent, und man wird verklagt oder abgemahnt. Ich denke schon, daß das einige Auswirkungen auf Open Source haben kann. Es würde mich auch die Meinung der Distributoren, also von SuSE und Debian, interessieren, die ja nun wirklich mit vier CDs voll Software, einige Software-Patente verletzen werden. 

Dirk Hohndel: Wir verkaufen ja unsere Software schon längst in den USA. Wir sind in den Jahren, genauso wenig wie RedHat, jemals verklagt worden. Das ist sicherlich eine theoretische Gefahr, und ich bin selbstverständlich strikt gegen Software-Patente. Nichtdestotrotz, diesen Horrorszenarien, die da gemalt werden, kann ich mich nicht so ganz verschreiben, weil in den Ländern, in denen es sie heute schon gibt, hat sich bisher noch niemand gefunden, der wirklich versucht hat, diese Patente auch durchzusetzen. Nichtdestotrotz sollte man auch unsinnige Gesetze, die keiner durchsetzt, gar nicht erst schaffen. Denn der Versuch, Software zu patentieren, ist meines Erachtens einfach falsch. Und daß wir selbstverständlich versuchen, den winzigen Einfluß, den wir haben, da auch einzusetzen, das ist ja klar. Nur muß man sich überlegen, daß eine SuSE oder eine RedHat oder wie sie auch alle heißen, im Vergeich zu einer Microsoft oder einer IBM, es relativ schwer hat, wirklich effizentes Lobbying zu betreiben. 

Publikum: Ich möchte noch einmal auf die vorherige Diskussion zurückkommen. Ich kann nicht programmieren, ich bin Chemiker. Und wenn ich einfach mal durch meine SuSE-CD scrolle, was so geboten wird, dann gibt es sehr viele ausgereifte Entwicklungen auf dem Sektor, wo sich Leute finden, die Spaß dran haben und einen Sinn darin sehen -- also vor allem Software-Entwicklung, zu der Informatiker und vielleicht auch Physiker noch einen Zugang haben. Das merke ich auch beim LaTeX, für wen schon gute Sachen gemacht sind und für wen nicht. Und da ist die Frage einfach: Wie kann dieses ganze Projekt Open Source gesamtgesellschaftlich erfolgreich werden, wenn Leute, die sich dafür finden zu programmieren, eigentlich immer nur aus ihrem eigenen Kontext heraus programmieren oder Lust haben zu programmieren? Ganz pragmatisch fehlt mir z.B. nur ein Formelzeichenprogramm. Da finde ich nirgendwo etwas, womit ich ordentlich umgehen kann, weil sich wahrscheinlich noch niemand dafür gefunden hat, das zu programmieren. Und ich selber habe nicht die Fähigkeit, das zu machen. Es gibt also Leute, die brauchen so eine Software, aber es findet sich keiner, der jetzt Lust hat, das zu programmieren. Wie kann man aus dieser Lücke rauskommen und trotzdem bei Open Source bleiben? 

Kalle Dalheimer: Da gibt es zwei oder drei Möglichkeiten: Zum einen, das wird Ihnen vielleicht ein bißchen wagemutig vorkommen, aber da kann ich nur sagen: Lernen Sie programmieren! Wenn Sie in der Lage sind, Chemie zu verstehen, dann können Sie Programmieren allemal lernen. Zum anderen ist es durchaus nicht so, daß es nur Programme aus dem naturwissenschaftlich-technischen Bereich gibt, auch wenn die sicherlich in der Überzahl sind. Wir, mit unserem KDE-Desktop, sind das beste Gegenbeispiel. Es gibt noch weitere ähnliche Oberflächen. Es gibt Open Source-Textverarbeitung, nicht nur vom Schlage LaTeX, die möglicherweise auch wieder nur von technisch orientierten Menschen vernünftig bedienbar sind. Und wenn es an einzelnen Stellen mal fehlt, dann fehlt es wahrscheinlich an jemandem, der Interesse gehabt hat, es zu entwickeln. Dann sind da tatsächlich auch Firmen gefragt, so eine Entwicklung in Auftrag zu geben. Wir haben auch im KDE einzelne Lücken, die keiner Lust gehabt zu füllen, weil alle fanden, daß es langweilig ist zu programmieren. Es ist schon in einzelnen Fällen vorgekommen, daß sich eine Firma bereitgefunden und gesagt hat: 'Es ist uns wichtig, daß diese Lücke gefüllt wird. Wir heuern mal jemanden für einen Monat an. Du kriegst dafür den Monat bezahlt, und du füllst dann diese Lücke.' Wir haben andere Lücken, die sind leider noch nicht so gefüllt worden, da hoffen wir auch noch drauf. 

Publikum: Ich wollte noch einmal auf das Problem eingehen, das der Herr von der Firma Intershop angesprochen hat, speziell das Geld-Verdienen mit Software: Ich möchte niemanden abstreiten, daß er auch mit seiner kommerziellen Software Geld verdienen kann. Nur, im Endeffekt kommt es darauf an, was für den Anwender das Bestmögliche ist. Geld kann man ja sowohl mit freier Software, als mit Copyright-protecteter Software verdienen, wie wir heute mitbekommen haben. Und was speziell viele Firmen ansprechen ist, daß sie proprietäre Lösungen benutzen, die von Features strotzen, wo aber keiner mehr bereit ist, ein Bugfix zu schicken, wenn man einen Fehler gefunden hat. Oder wenn man irgendwo im Walde steht und nicht mehr weiterkommt, kann man nicht solche mächtigen Tools benutzen, ob das nun *Estres oder ein Library-Debugger ist. Man steht im Regen, man kann nicht weiterkommen. Und viele große Firmen, die kommerzielle Software anbieten, haben auch überhaupt kein Interesse, ihre Fehler zu fixen, weil sie ja Fehler-Fixes nicht verkaufen können. Keiner würde ein neues Betriebssystem aus Redmond kaufen, weil: 'wir haben hundert Fehler beseitigt'. Nein, da müssen hunderttausend neue Features kommen, die kein Mensch braucht, die kein Mensch verstehen kann, und dann wird die große Marketing-Maschine angeschmissen, die alles als Superlösung verkauft. Das ist im Endeffekt nicht das, was für den Anwender und auch nicht für kleine Firmen gut ist, denn die stehen dann im Regen und wissen gar nicht mehr, was sie machen sollen. Und die Großen teilen den Markt unter sich auf, nach dem Motto: 'Wir wollen Weltführer mit E-Commerce-Service werden' oder 'wir sind das marktführende Betriebssystem'. Das ist ja eine Monopolisierung, die auch gar nicht Sinn und Zweck ist. Wenn man sich z.B. die Wissenschaft rückblickend betrachtet: wo wären wir denn heute, wenn jeder Wissenschaftler oder jeder Mathematiker, der eine Formel entdeckt, die durch ein Patent schützt, wegschließt, und der Nächste darf wieder bei Null anfangen? Und wenn irgendjemand auf dieselbe Formel kommt, heißt es: 'darauf haben wir unser closed oder hidden Patent. Nein, die dürfen Sie nicht benutzen.' Also, das ist ja keine Zukunft, auch nicht für die Weiterentwicklung im wissenschaftlichen Bereich. 

Publikum: Ich will mich in diesem Zusammenhang direkt an meinen Vorredner anschließen und die große Frage nach dem Kapitalismus stellen. Ich will hier nicht als der große Revoluzzer auftreten, aber es wurde vorhin von der Ökonomie der Anerkennung gesprochen, die es in der Wissenschaft schon seit langer, langer Zeit gibt. Die Professoren in Deutschland sind alle Beamte, und trotzdem machen sie noch Wissenschaft. Ist es nicht so, daß wir möglicherweise mit der Software-Entwicklung plötzlich eine ganz neue Tür aufgestoßen haben, wie Menschen miteinander umgehen, wie Menschen sich gegenseitig ihr Handwerk vermitteln, sich gegenseitig dienen? Der Kapitalismus ist ja auch nur eine Form zu organisieren, daß Menschen einander dienen und jeder das möglichst Produktivste aus seiner Arbeit herausholt. Und ist nicht die Form, wie wir sie jetzt hier in der Software-Entwicklung haben, eine ganz neue Art, wie Leute miteinander umgehen, und jeder das tut, was er am besten kann, jeder sich an den Fehlern aufhält, die ihn am meisten stören, und somit die Gesamtheit der Software verbessert wird? 

Frank Gessner: Ich möchte mich jetzt hier nicht hinsetzen und sagen: 'Ich bin der Vertreter der Bösen, die ihre Software nicht im Source Code herausgeben.' Wir haben uns ziemlich lange darüber unterhalten, was denn wirklich der Benefit für den Kunden ist. Und wenn der Benefit für den Kunden ist, die Software im Source Code zu haben -- das hatte ich vorhin auch auf meinen Slides drauf --, dann würden wir ihm den sofort geben. Die Dynamik in den Technologien und in der Industrie, in der wir uns bewegen, die steigt immer an. Ich glaube, da wird mir niemand wiedersprechen. D.h., es ist eine ungeheure Power notwendig, um so ein Software-Projekt wie Apache heute überhaupt noch einmal zu beginnnen, also sich noch einmal irgendetwas zu nehmen, eine neue Technologie, sagen wir mal einen XLM-Server oder irgendwelche ganz tollen ldap oder *iop-Geschichten, und so etwas noch einmal zu beginnen, oder wirklich ein Produkt zu haben, das richtig gut ist und das die Leute mögen. Das ist nur mit einer sehr koordinierten Organisation möglich, die eine ungeheure Power hat. 

Das nächste, was ich sagen wollte, ist: Um wirklich eine Entwickler-Community und solche Projekte weltweit hochzuziehen... Ich bin in der DDR geboren, ich bin dort aufgewachsen. Das waren vielleicht vergleichbare Gedanken, die ich heute hier wieder gefunden habe. Im Endeffekt sind das wirklich kommerzielle Sachen. Es sind auch kommerzielle Sachen, an denen die DDR gescheitert ist. Das war nicht so, daß da irgendwelche schlimmen Tyrannen waren. Im Endeffekt ist das Wirtschaftssystem zusammengebrochen, weil der Kommerzgedanke gefehlt hat. Wir sind vielleicht in unserer Menschheitsentwicklung noch nicht weit genug, zu sagen, wir machen hier irgendetwas anderes. Und auch solche Lizenzkosten innerhalb von Software, das ist nicht das, was den Leuten weh tut. Wir kaufen sehr viel Lizenzen ein, wir verkaufen Lizenzen. Wenn ich an unsere CRM-Installation denke, also die Customer Relationship Management System-Installation, da waren die Lizenzkosten drei Prozent. SAP, da waren es zwei Prozent von dem, was wir ausgegeben haben. 

Publikum: Entschuldigung, daß ich nur wenig Deutsch spreche, deshalb werde ich auf Englisch sprechen. I have a question to you, Frank. It's a question of fact. You just mentioned that there are 200 engineers at Intershop. Do you happen to know of any of those 200 who have the same urge that Kalle from KDE has mentioned, the urge to go home at fivr and start working on their open source project? 

Frank Gessner: It's actually pretty funny. The guys working for me in Jena in R&D have stock options. They love what I have and they know how much this is worth. I mean, we have created 80 millionairs. They have a lot of fun, and they love their software and every press news they see on Intershop and the stock price. That's how it works. They work 12, 14, 16 hours a day, and that's for free. Nothing we pay them [extra]. 

Marc Lehmann: Was mir schon mehrmals aufgefallen ist, nicht nur bei Intershop, ist dieser Satz: 'Wenn es für unseren Kunden sinnvoll wäre, würden wir den Quellcode freigeben. Was für einen Sinn der hat, das kann ich einfach nicht nachvollziehen.' Das ist für mich vielleicht als Entschuldigung zu werten, aber meiner ganz persönlichen Erfahrungen nach funktioniert einhundert Prozent der Software, nicht der kommerziellen Software, sondern der Software, die ohne Quelltext kommt, nicht. Das kann ich nicht anders sagen. Und 'nicht funktionieren' bedeutet: Sie tut nicht das, was ich will, und sie tut nicht das, wofür ich bezahlt habe, und sie tut nicht das, wofür sie eigentlich geschrieben sein sollte. Bei freier Software ist es teilweise auch so. Es gibt gute und schlechte Programme. Aber ich hab den Quelltext. Und ich kann immer, selbst wenn ich nicht programmieren kann, wenn ich Geld habe, jemanden einstellen, der mir die Software so weit hinschreibt, wie ich das gerne habe. Und wenn ich selber programmieren kann, kann ich das sogar ohne Geldaufwand. Also dieses 'Wenn es für unseren Kunden sinnvoll wäre' -- Ich würde sagen, daß es grundsätzlich sinnvoll ist, den Quellcode mitzuliefern, denn der Kunde hat dadurch eine viel höhere Qualität. Und ich denke auch, daß die Qualität der existierenden Open Source- und GPL-Produkte für sich spricht. Die ist ja wesentlich größer, als alles, was man so an kommerzieller, nur binär verbreiteter Software bekommt. 

Frank Gessner: Also das erste: Wenn wir den Source Code mit-shippen, wird die Qualität der Software nicht besser. Das muß man trennen. Das zweite: Ich habe erklärt, daß wir einen zweistufigen Vertrieb haben. Das macht auch Sinn. D.h., unsere Kunden sind große Telcos und Enterprises. Die haben weder ein Interesse noch die Kompetenz noch die Möglichkeit dazu, in ein Software-System, wie in die Intershop-Software-Systeme, mit mehreren Millionen Lines of Code reinzukommen. Das macht in der Regel ein Systemintegrator oder ein Professional Service oder Design Agencies. Wenn die für bestimmte Bereiche Quellcode brauchen, weil sie sagen: 'Hier ist eine Funktionalität drin, die uns nicht gefällt, die wir gerne erweitern möchten', gibt es dazu die Möglichkeit. Wenn in dieser Software ein Fehler drin ist, dafür gibt es Warranty. Da werden wir zu Tode geklagt, wenn das Zeug nicht funktioniert. So etwas muß auch der Markt regeln. Und wenn der Kunde zum Schluß selbst die Software anfaßt und eine Zeile Code verändert, weiß er, was er damit macht: Er hat danach ein Custom-Built. Er hat dann damit wirklich ein großes Problem. Die bezahlen sehr viel Geld für diese Software, auch für Support und wissen, daß sobald sie dort irgendwelche Datenbank-Tabellen oder Objekte umstrukturieren, daß sie in ein anderes Support-Modell reinfallen. Das wollen die in der Regel nicht. Die wollen, daß das Problem gefixt wird, möglichst morgen früh. 

Publikum: Nach dieser Buzz-Word-Kaskade aus der großen Geschäftswelt möchte ich noch einmal darauf eingehen, wie man als Endnutzer an die Software kommt, die man haben will. Wir hatten gerade die Sache: 'Ich möchte als Chemiker ein Formelprogramm haben.' Chem-TeX ist meiner Meinung nach übrigens ganz exzellent. Aber jetzt war direkt der Schrei nach den großen Firmen, die vielleicht jemanden bezahlen, der das entwickelt. Und wir sind hier, um uns nicht über das letze Jahrhundert Gedanken zu machen, sondern über das nächste. Da muß man überlegen, ob man da nicht andere Geschäftsmodelle finden kann. Freie Software heißt nicht Software, die kostenfrei ist, sondern bezahlen ist ja OK. Und wenn man sich zu zehn oder hundert oder tausend Chemikern zusammenfindet, dann kann man auch ganz problemlos ein Team bezahlen, daß die Software schreibt. Was uns nur fehlt, sind Geschäftsmodelle, wie man sowas organisiert und finanziert, denn man möchte sein Geld nicht auf irgendein Konto überweisen und gucken, ob mal Software rauskommt. Aber gerade für so was werden gerade z.B. kryptographische Protokolle entwickelt. Bruce Schneier, der da ganz groß freie Gedanken in der Krypto-Ecke macht, also keine Software, sondern vor allem Algorithmen, der hat jetzt einen Algorithmus vorgestellt oder ein Protokoll, mit dem man sicherstellen kann, daß erst bei Produktablieferung bezahlt wird, daß viele Leute nicht spenden, sondern bezahlen, und sie bekommen dann ein freies Produkt, wenn genug Geld zusammengekommen ist. Ich denke, man muß über ganz andere Modelle nachdenken. Momentan haben wir in der freien Software-Szene ganz stark den Hang dazu, nach Firmen zu schreien, die uns entwickeln, was wir haben möchten. Das ist sicher nicht an allen Stellen so, aber es heißt doch immer wieder: 'Kann nicht RedHat mal fünf Entwickler darauf ansetzen?' Das ist immer noch die falsche Denke, wenn man so drangeht. 

Publikum: Ich würde gerne noch mal etwas dazu sagen, was bei dem Herrn von Intershop anklang: Daß man große Softwareprojekt nur mit sehr viel Geld managen kann und nur so auch neue innovative Verfahren entstehen können. Das kann auch sehr schnell nach hinten losgehen, wie man an Toshiba und Microsoft sieht. Microsoft implementiert ja gute Ideen mit sehr viel Geld, aber die Implementationen sind so auf den Markt abgestimmt, daß sie unvollständig sind, einfach qualititativ minderwertig. Und man kümmert sich nicht darum, daß das Produkt wirklich gut implementiert wird oder leistungsfähig ist, sondern nur darum, ob man etwas Neues verkaufen kann. Wenn die Entwicklung dahin geht, daß wirklich nur noch auf den Geldbeutel geachtet wird, dann wird die Qualität der Software permanent sinken. Und da hat der Anwender überhaupt nichts von. Ich denke mal, daß Open Source-Entwicklung natürlich auch ihre Probleme hat, z.B., daß viele Leute Zeit finden müssen, aber zumindest sind die Leute daran interessiert, daß sie Qualität produzieren, und gucken nie auf den Geldbeutel. Und ich denke, was dabei rauskommt, ist im Enddeffekt eine bessere Implementation, von der die Welt und die Gemeinschaft mehr hat, als von einer kommerziell motivierten, unvollständigen, fehlerhaften Implementation, die sehr leicht entstehen kann. 

Und zum zweiten Aspekt: Dieser Vergleich mit dem Kommunismus, der hier ein bißchen durchklang. Ich glaube, der Hauptunterschied zwischen Open Source und Kommunismus ist, daß man bei Open Source für Einzelleistung belohnt wird, was man im Kommunismus nicht wurde. Der Hauptunterschied ist die Motivation. Man bekommt Feedback. Die Motivation durch Lob, durch Ehre, ist, glaube ich, schon sehr stark. Meine persönliche, berufliche Erfahrung ist so, daß man mit Geld alleine Leute nicht kaufen kann. Geld ist natürlich wichtig, aber Leute, die nur für Geld arbeiten, leisten schlechtere Arbeit, als Leute, die motiviert sind. 

Publikum: Mein Name ist Edmund Humenberger. Ich bin mit Linux seit 1992 involviert und habe mich damals dazu entschlossen, mich damit zu beschäftigen, nicht weil Linux so super war oder technisch herausragend, sondern weil das Prinzip dahinter faszinierend ist: eben wie Open Source-Software entwickelt wird. Ich habe natürlich seit damals auch gesucht, wie man davon leben kann. Weil, von der Anerkennung kann ich nicht in den Aldi gehen und mir zwei Kilo Brot kaufen und meine Miete bezahlen. Es muß schon das Ziel sein, daß Programmierer, die qualifiziert sind, auch davon leben können. Es zeichnet sich jetzt ab, daß es gewisse Typen von Software gibt, mit denen man wirklich Geld verdienen kann. Das ist eine typische Situation: Ich habe ein Open Source-Projekt, das zu achtzig Prozent das tut, was ein Anwender will. Und er bezahlt mich noch für die zwanzig Prozent, daß es dann zu hundert Prozent das tut, was er will. Und das sind die Produkte wie Apache, wie Linux, die momentan bereits nutzbringend sind und die dann einfach weiterentwickelt werden im Interesse des Benutzers, der auch dafür bezahlt. Es gibt aber sehr wohl Klassen von Software, die momentan nicht als Open Source entwickelt werden. Darunter fällt zum Beispiel Spracherkennung, Text to Speach, OCR und all diese Klassen von Applikationen, die einen irrsinnigen Aufwand an Grundlagenforschung brauchen, um überhaupt einmal ein Produkt zu erreichen, das man halbwegs benutzen kann. Es finden sich momentan keine Leute, keine Teams von drei, vier, fünf Leuten, die über Jahre hinweg diese Forschung betreiben und dann das Produkt als Open Source releasen, weil einfach niemand die Investionen tätigen kann, weil er sie nicht mehr zurückbekommt. Meine Frage an das Panel ist, ob das Panel eine Vorstellung hat, wie wir zu dieser Klasse von Applikationen kommen, in Form von Open Source. Ich bin der Meinung, daß dieses Bounty-Prinzip: 'Legen wir doch alle mal zusammen und wenn es dann fertig ist, bezahlen wir das, was sie versprochen haben', nicht funktioniert. Weil die Qualität von Software, ob jetzt das ausgeschriebene Ziel erreicht wurde, einfach zu Streitereien führt, ob, wer, wie, wann, was beigetragen hat und wieviel er jetzt bekommt. 

Marc Lehmann: Es gibt Spracherkennungssysteme auch für Linux und die können sogar teilweise deutsch. Und es gibt auch Sprach-Synthesizer, sogar relativ viele. Das ist ein relativ erforschtes Gebiet, gerade bei diesen Anwendungssachen. Mit der Forschung ist es klar, die Universitätsprofessoren sagen: 'Wir müssen neuerdings auch Geld verdienen, d.h., wir machen mit der Wirtschaft ein Bündnis und entwickeln für eine Firma irgendwas. Das wird ja irgendwann einmal zugängliches Wissen sein.' Ein Kernpunkt dieser freien Software-Bewegung ist, daß das Wissen -- dazu gehört auch die Grundlagenforschung -- nicht weggeschlossen werden kann, sondern es ist frei. Dazu gehört dann auch, daß ich so ein Programm schreiben kann. Es ist jetzt die Frage: Wie sieht das in der Zukunft aus? Wer zahlt das dann in Zukunft? Ich denke, auch heute wird ein Großteil der Forschung ja nicht bezahlt von einer Firma, sondern beispielsweise vom Staat und vielleicht auch mal von einer Firma. Ich weiß nicht, ob sich das groß ändert. 

Sebastian Hetze: Ich habe den Eindruck, daß hier relativ häufig im Unterton ein bißchen drin steht: 'Es darf nur freie Software geben.' Und das finde ich, ist möglicherweise ein sehr hehres und sehr hohes idealistisches Ziel, aus rein abstrakten Gesichtspunkten. Zu fordern, daß Intershop als freie Software veröffentlicht wird, ist dann eher eine rhetorische Frage. Das ist einfach unrealistisch und nicht das, was letztenendes das Attraktive an freier Software ist. Ich will nicht alles in freier Software. Das wäre schön als reines, abstraktes Ziel, aber in der realen Welt ist es so, daß wir mit einem Kompromiß leben. 

Publikum -- Edmund Humenberger: Ich wollte nicht den Eindruck erwecken, daß ich, wie der Stallman, Open Source-Militant bin, sondern ich bin genauso der Meinung, daß kommerzielle Software in gewissen Anwendungsgebieten ihre Berechtigung hat. Ich möchte aber im Bereich Open Source natürlich auch die Vorteile nutzen von Fehlerfreiheit, von gemeinsamen Bugfixes, usw. und daher eben auch der Wunsch, gewisse Applikationen als Open Source zur Verfügung zu haben. Ich denke mir immer, wenn ich irgendwelche kommerziellen Macintosh-Applikationen im Graphikbereich sehe: 'Oh, das ist schön. Das ist ein html-Editor, der kann wirklich was.' In diesem Bereich ist als Open Source weit und breit nichts zu sehen, was leistungsmäßig an diese Produkte herankommt. Was die Forschung angeht: Forschung wird an den Universitäten betrieben, und das Ergebniss von Forschung sind meistens Paper, weil die Wissenschaftler Papers produzieren. Sie werden für die Papers belohnt. Und die Software, die dabei rauskommt, ist meistens nicht benutzbar. 

Kalle Dalheimer: Noch einmal zu der Frage: Wollen die Kunden von Intershop den Source Code oder nicht? Ich denke, auch dies ist eine Sache, die man den Markt entscheiden lassen kann. Wenn es einen Kunden gibt, dem es wichtig ist, daß er den Source Code bekommen kann, und die Firma Intershop oder wer auch immer sagt: 'Nein, den Source Code gibt es nicht', oder nur unter Bedingungen, die für den Kunden nicht akzeptabel sind, dann wird der Kunde sich woanders umgucken. Dann wird er sich möglicherweise Lösungen wie *Minivent angucken, wo er eventuell noch ein bißchen was dranstricken lassen muß, vielleicht reicht es aber schon für das, was er braucht. Und wenn er tatsächlich keine Lösung im Open Source Bereich findet, dann kann der Kunde sich immer noch überlegen: 'Beiße ich jetzt in den sauren Apfel und akzeptiere dann, nicht den Source Code zu bekommen.' Ich glaube zwar auch nicht, daß der Markt überall funktioniert, aber mit dem Bewußtsein, das die Leute inzwischen haben, und dem Wissen, das sich mehr und mehr durchsetzt, daß man mit Open Source Software einfach besser fährt, weil es die Risiken für den eigenen Betrieb minimiert, kann man da, glaube ich, in diesem Fall einfach den Markt spielen lassen. 

Sebastian Hetze: Ich möchte auch noch einmal einen Aspekt aufwerfen: Die Entwicklung von freier Software, das haben wir schon gehört, ist natürlich schon eine sehr alte. Sie datiert mit den Anfängen von Computern überhaupt, mindestens mit der Entwicklung von Unix. Es hat dann eine sehr reichhaltige Entwicklung in den vergangenen 30 Jahren gegeben. Jetzt haben wir einen Durchbruch. Es gibt eben das relativ komplette Desktop- und Server-System, alleine aus freier Software. Die Entwicklung ist aber, wenn man sich das einmal bezogen auf das technologische Zeitalter betrachtet, erst am Anfang. Der Durchbruch für freie Software ist gekommen mit dem Internet. Das ist ganz klar. Es ist das zentrale und wichtigste Medium, was überhaupt diese Art von Kommunikation und Kooperation, wie sie für freie Software notwendig ist, in dem Ausmaß, wie wir es jetzt sehen, überhaupt möglich macht. Und die produktiven Ressourcen der gesamten Welt sind zur Zeit nur zu einem geringen Bruchteil überhaupt mit elektronischen Medien derart vernetzt, daß die Leute daran teilnehmen können. Die Ressourcen, die also jetzt noch brachliegen, werden mit ziemlicher Sicherheit noch eine ganze Menge neuer freier Software hervorbringen. Ich würde an dieser Stelle sozusagen dem Toyotismus das Wort sprechen: Nichts ist unmöglich! Die Spracherkennung ist da meiner Ansicht nach eher eine kleinere Geschichte. Durch den Charakter des freien wissenschaftlichen Austausches des Wissens, nämlich des Inhalts dieser Software, kann da Innovation jetzt erst frei fließen. Sie ist natürlich immer schon geflossen, sonst wären wir mit der Computertechnologie gar nicht da, wo wir jetzt sind. Aber es wird natürlich in dem gleichen Maße weitergehen wie bis jetzt, beziehungsweise es wird sich in dem gleichen Maße steigern, wie das Internet wächst. Das ist allein eine Frage der Zeit, bis all diese Sachen da sind. 

Publikum: Ich möchte gerne ein wenig die Perspektive verändern. Freie Software bedeutet in weiten Teilen der Welt erst einmal gar nichts, weil es in Afrika keine Software gibt. Zweitens, etwas ganz anderes als hier in unserer Diskussion: In China gibt es freie Software. Sie wird von Microsoft produziert und von unzähligen kleinen Geschäften illegalerweise dupliziert. Dieses Beispiel zeigt, daß wir auf eine ganz interessante Weise dahin zurückkommen, wo wir angefangen haben, nämlich: 'Software ist ein geistiges Gut, das dem Menschen zur Verfügung zu stehen hat.' Ich glaube allerdings, daß die Behauptung, Open Software sei von höherer Qualität, in vielen Fällen tatsächlich stimmt. Das zeigt uns auch die Entwicklung der letzten Jahre. Deswegen möchte ich jetzt versuchen, von dieser elenden Computerei wegzukommen. Software ist ja schließlich ein Gedankengut. Es ist etwas, was erzeugt wird von Menschen, die sich Gedanken machen, und die das im Falle von freier Software auch ganz unentgeldlich tun. Und im jeden Fall, auch bei Leuten, die das nicht unentgeldlich tun, können sie das nur deswegen, weil die Gesellschaft ihnen Bildung ermöglicht hat, in die Schule zu gehen, sich einen Computer zu kaufen, zu studieren usw. Mich würde interessieren und ich hatte mir eigentlich erhofft von diesem Kongreß, einen gewissen Anstoß in diese Richtung zu bekommen: Es gibt andere Bereiche, in denen das ebenfalls zutrifft. Da gibt es die Genom-Analyse und die Patentierung von Leben -- eine Diskussion, die in Europa und den USA wie auch in Indien und dergleichen äußerst vehement geführt wird. Da gibt es die Frage von Copyright auf Musik, auf Literatur. Ich glaube, morgen ist jemand vom Gutenberg-Projekt hier. Ich freue mich schon sehr darauf. Und ich hoffe, daß diese Sachen zu einer ein wenig erweiterten Perspektive auf diese Frage der Open Source kommt, weil Open Source kann zumindest im Beispiel der Software ein erfolgreiches Modell sein. Wir sollten uns fragen: Kann das auch in den anderen Bereichen des täglichen Lebens funktionieren, auch kommerziell, vor allem auch sozial funktionieren? Kann es dazu führen, daß man innerhalb unseres Wirtschaftssystems, auch in anderen Bereichen als nur Software zu einer freieren Verbreitung von Wissen kommt? 

Sebastian Hetze: Die Antwort ist 42. <Gelächter> Mal ganz im Ernst, es ist so, daß freie Software sich von den meisten anderen Produkten, Gütern, Waren dieser Welt ganz entschieden dadurch unterscheidet, daß sie praktisch kostenlos, also ohne Aufwand, beliebig häufig zu reproduzieren ist. Es gibt keinen Mangel an Software. Auf diese Weise läßt sich natürlich diese Ökonomie, wie wir sie mit freier Software entwickeln, erproben, erleben, nicht auf die gesamte gesellschaftliche, volkswirtschaftliche Ökonomie übertragen. Da sind einfach die Grundlagen nicht gegeben. 

Detlef Borchers: Vielleicht können wir das ganze damit beenden. Die Fragen der Digitalisierung einer Gesellschaft bis hin zu den Genen, der Musik, den Medien, den Nachrichten, die alle in die Open Source-Geschichte hineinrutschen, ist Thema des morgigen Tages. Heute waren wir sehr eng an der Software.