ZUR DISKUSSION GESTELLT / OPEN SOURCE SOFTWARE }

Rechtsrisiko Open Source Software? Frank A. Koch

Die Nutzung von Open Source-Software ist nach wie vor mit teilweise recht engagierten Diskussionen verbunden. Nur ein Teil der aufgeworfenen Fragen ist in der Vertriebs- und Anwendungspraxis aber tatsächlich relevant. Diese Fragen und der aktuelle Stand der Diskussion hierzu werden nachfolgend zusammengestellt, wobei kritische Argumente der in der Praxis besonders intensiv diskutierten Studie [3] im Mittelpunkt stehen sollen. Während das Recht zumeist ausreichende Lösungsmöglichkeiten zur Verfügung hält, müssen Open Source-Lizenzen wie etwa die in den meisten Fällen verwendete GNU General Public License (GPL) der Free Software Foundation (Version 2 vom 02.06.1991) zumindest bezüglich des neu eingeführten Rechts der „öffentlichen Zugänglichmachung“ ergänzt werden. Die Darstellung kann im vorliegenden Rahmen nur in knapper Weise erfolgen; ausführlicher werden Open Source-bezogene Fragen in [1] behandelt. Vorab sei festgehalten, dass Open Source-Software wie jede andere Software urheberrechtlich geschützt sein kann, wenn sie (wie zumeist der Fall) individuelle Gestaltungsmerkmale aufweist. Die GPL „funktioniert“ sogar nur unter Urheberrecht.

Anwendungseignung im Einzelfall prüfen Der Einsatz von Open Source (OS)-Software wird bisher überwiegend im technischen und wirtschaftlichen Zusammenhang diskutiert. In technischer Hinsicht scheint die Auffassung gefestigt, dass OSSoftware wie etwa Linux für den Einsatz auf Serverrechnern sicher läuft und gut zu administrieren ist. Auf PC-Ebene sind ebenfalls Distributionen verfügbar (und mittlerweile wohl fast problemfrei instal-

lierbar), doch gibt es bisher wenige Anbieter, die ihre Systeme serienmäßig z.B. mit vorinstallierten Linux-Distributionen ausstatten. Auch muss der Anwender jeweils prüfen, ob die gesamte von ihm geplante Peripherie unterstützt wird, – ein Problem, das sich mit wachsender Marktpräsenz von OSSoftwareanbietern lösen dürfte. In wirtschaftlicher Hinsicht muss unterschieden werden: Beim Einsatz auf Serverrechnern und Endanwendersystemen wird meist ein deutlicher Kostenvorteil zum Tragen kommen, da Distributoren die OS-Teile ihrer Applikationen kostenfrei weitergeben müssen und nur das Zusammenstellen und eigene Zusatzprogramme vergütet verlangen dürfen. Bei größeren Anwendungen müssen freilich die unvermeidbaren Migrationskosten mit in Betracht gezogen werden. Sie ergeben sich etwa aus erforderlichen Umschulungen und Anpassungen bzw. dem Neuschreiben von verwendeten Formularen oder Makros. Zu vergleichen ist, welche Updating- bzw. Upgrading-Kosten in einem vorgegebenen Zeitraum (etwa von 5 Jahren) bei proprietärer Software auftreten werden und welche Anpassungsund Updating-Kosten bei OS-Software. Die Ergebnisse eines solchen Vergleiches können überraschend sein. So basierte die – in der Presse aufmerksam verfolgte – Entscheidung von München, für mehr als 14.000 Systeme Linux-basierte Applikationen einzusetzen, auf einer „Client Studie“ [2], die für einen Zeitraum von 5 Jahren DOI 10.1007/s00287-003-0365-6 dem Einsatz von proprietä- © Springer-Verlag 2004 Dr. F. A. Koch rer Software den Vorzug Rechtsanwalt in München, gab und erst für den ZeitMaximilianstr. 54, 80538 München raum von 10 Jahren die E-Mail: [email protected] Informatik_Spektrum_20_Februar_2004

55

} OPEN SOURCE SOFTWARE

Vorteile des Einsatzes von OS-Software überwiegen sah. Beim kürzeren Zeitraum fielen insbesondere die höheren Kosten für Schulung und Anpassung von „Sonderhardware“ (z.B. I/O-Geräte, Steckkarten und Behindertenhilfsmittel) an OS-Systeme ins Gewicht, die auch nicht durch die Ersparnis durch Lizenzkosten ausgeglichen wurden. Festgehalten wurde freilich auch, dass die Linux-basierte Lösung (längerfristig) 50% weniger haushaltswirksame Kosten verursacht. Aus der genannten Studie lässt sich die verallgemeinerbare Erkenntnis ableiten, dass eine Wahlentscheidung keineswegs immer zugunsten von OS-Software fallen, sondern im Einzelfall unter Berücksichtigung aller Migrationskosten entschieden werden muss. Erweist sich bei dieser Prüfung freilich, dass der Einsatz von OS-Software für die jeweilige Anwendung kostengünstiger sein würde, werden etwa Kommunen sich (angesichts ihrer bekannten finanziellen Engpässe) für diese entscheiden müssen und deshalb bei Auftragsausschreibungen zukünftig grundsätzlich immer auch OS-Anbieter zu berücksichtigen haben.

Unbeherrschbares Gewährleistungsrisiko? Ein häufig geäußerter Einwand gegen OS-Software ist, dass Anwender diese Software nicht gesichert einsetzen können, da die Gewährleistung für sie ausgeschlossen sei. Tatsächlich sieht die GPL in Nr. 11 einen Gewährleistungsausschluss vor („no warranty“), während die zugrunde liegende Open Source-Definition einen solchen Ausschluss nicht verlangt. Ein solcher Gewährleistungsausschluss wurde als unwirksam angesehen, wenn die GPL als Standardbedingungen (und damit allgemeine Geschäftsbedingungen) verwendet werden [3]. Würde diese Auffassung zutreffen, müsste das gesamte Modell des entgeltfreien Verfügbarmachens von OS-Software zusammenbrechen, da für wesentliche Teile von OS-Software die einzelnen Autoren entweder nachträglich kaum mehr identifizierbar sind oder jedenfalls technisch und/oder wirtschaftlich nicht ausreichend Ressourcen haben, um für eine Gewährleistung in Anspruch genommen werden zu können. Umgekehrt würde niemand mehr weiterhin OS-Software entwickeln und zur Verfügung stellen, wenn er weltweit Nutzern Gewähr leisten müsste. Die Kritik an der GPL beachtet aber nicht ausreichend, dass die OS-Software entgeltfrei überlas-

56

Informatik_Spektrum_20_Februar_2004

sen wird (von zulässigen Kopiervergütungen einmal abgesehen, die aber keine Vergütung für Nutzungen beinhalten). Deshalb wird auf die Überlassung von OS-Software nach weitaus überwiegender Rechtsauffassung Schenkungsrecht angewendet (da es an der Gegenleistung der Vergütungszahlung fehlt). Eine Verpflichtung zur Zahlung einer Vergütung für die Nutzung der überlassenen OS-Software ist in der GPL (und jeder den Kriterien der Open Source-Definition folgenden Lizenz) ausdrücklich ausgeschlossen. Aber auch eine Verpflichtung zur Weiterentwicklung des erhaltenen Codes besteht nicht (wenngleich diese Weiterentwicklung ein wesentliches Motiv der Open Source-Philosophie ist). Ein Anwender, der OS-Software einfach nur nutzt, handelt deshalb nicht lizenzwidrig. Schenker des Nutzungsrechts ist im übrigen nicht der weitergebende Entwickler, sondern der ursprüngliche Entwickler, der jedem Folgenutzer in der Weitergabekette das Nutzungsrecht immer wieder neu einräumt. Der weitergebende Entwickler bleibt hinsichtlich der bei ihm weiter vorhandenen Programmkopie deshalb unverändert nutzungsbefugt (da sein Nutzungsrecht nicht auf den Folgenutzer übergeht). Hingegen räumt dieser Entwickler selbst allen Folgenutzern Nutzungsrechte ein, soweit er selbst den Code individuell-schöpferisch ergänzt oder erweitert. Die Folgenutzer erhalten damit ein Bündel abgestufter Nutzungsrechte, die jedoch alle der GPL folgen. Der die OS-Software erhaltende und nutzende Anwender ist aus dieser Schenkung nicht frei, beliebig mit der Software zu verfahren, sondern an die Bedingungen der GPL gebunden, die insoweit als Auflage einzustufen sind, unter der die Schenkung gemacht wird. Zwei Argumente scheinen dieser Beurteilung entgegenzustehen: Einerseits bedarf das Versprechen einer Schenkung einer Beurkundung durch einen Notar (ein für die Nutzung von OS-Software völlig praxisfremdes Erfordernis), doch genügt es für die Wirksamkeit der Schenkung, dass die Software tatsächlich überlassen wird. Ohne diese Überlassung besteht freilich wegen des Formmangels kein rechtlich durchsetzbarer Anspruch. Andererseits wurde eingewendet, Schenkungsrecht sei nicht anwendbar, da unter der GPL eine Verpflichtung zur Preisgabe der eigenen Leistung bestehe [10]. Die GPL stellt insoweit aber nichts anderes als ein zulässiges, jedenfalls mit Vollzug wirksames Schenkungsversprechen dar.

Schenkungsrecht sieht freilich (anders als etwa Kauf- oder Werkvertragsrecht, die immer Vergütungszahlung als kundenseitige Gegenleistung voraussetzen) keine Gewährleistung (im Sinne eines verschuldensunabhängigen Einstehenmüssens für Mängel) vor. Ein vertraglicher Gewährleistungsausschluss ist deshalb auch nicht unwirksam (da dem Beschenkten mit diesem Ausschluss kein schenkungstypisches Recht „weggenommen“ wird, sondern insoweit allenfalls gegenstandslos. Allerdings haftet der Schenker auf Schadensersatz, wenn er dem Beschenkten arglistig Sach- oder Rechtsmängel verschweigt (§§ 523 Abs. 1, 524 Abs. 1 BGB). Die Ausschlussklausel GPL Nr. 11 ist aber so auszulegen, dass die Gewährleistung wegen der Vergütungsfreiheit entfallen soll („Because the program is licensed free of charge, there is no warranty for the program“), also auf die Besonderheit des vertraglichen Austauschverhältnisses als solches abgestellt wird und die Klausel in ihrer Reichweite auf dieses eingeschränkt ist. Nicht umfasst ist hier ein Ausschluss sonstiger verschuldensabhängiger Haftung („liability“) für rechtsverletzendes Verhalten wie Arglist, insbesondere auch nicht die Haftung des Schenkers für Vorsatz und grobe Fahrlässigkeit (§ 521 BGB). Selbst wenn man die Ausschlussklausel auf das Einstehenmüssen für solche Arglistfälle ausweiten würde, könnte sich der Schenker auf diesen Ausschluss nicht berufen (§§ 523 Abs. 2 Satz 2, 524 Abs. 2 S. 3 in Verbindung mit § 442 BGB). Damit ist der Ausschluss der verschuldensunabhängigen Gewährleistung als wirksam anzusehen. Als weitere Besonderheit ist zu beachten, dass das Schenkungsrecht keinen Nachbesserungs- oder Nachlieferanspruch vorsieht (sondern nur Ersatzansprüche). Mängelbeseitigung können Anwender von OS-Software also gegenüber deren Autoren nicht verlangen. Gewährleistungsansprüche bestehen aber, soweit etwa Distributoren eigene Software der Distribution hinzufügen und vergütet verlangen. Hier wäre jeder formularvertragliche Ausschluss von Gewährleistung unwirksam, da die Software-Überlassung als vergütete insoweit regelmäßig Kaufrecht folgt. Aus Gewährleistung können die Kunden hier insbesondere kostenfreie Mängelbeseitigung verlangen, außer, die hierfür erforderlichen Kosten wären unverhältnismäßig (§ 439 Abs. 3 Satz 1 BGB); in diesem Fall kann der Kunde Nachlieferung eines mangelfreien Exemplares verlangen (wenn ein sol-

ches in der Serie existiert) oder vom Vertrag zurücktreten und Schadensersatz verlangen. Risiken gehen Entwickler freilich ein, die für kommerzielle, proprietäre Softwareprodukte aus Kostenersparnisgründen OS-Entwicklungsumgebungen, sonstige OS-Tools oder -Programmbibliotheken einsetzen und bei Fehlern in diesen Kundenansprüche auf Mängelbeseitigung nicht an die Urheber der OS-Software „weiterreichen“ können. Außerdem dürfen Entwickler auf OS-Software basierende, in das kommerzielle Produkt nur übernommene oder bearbeitet übernommene Programmteile nicht wie den Rest des Produktes veräußern, sondern nur kostenfrei überlassen. Enthält zudem das jeweils erstellte Programm (z.B. ausführbare) Teile einer unter der GPL verbreiteten Software, muss sogar der Vertrieb des ganzen Produktes unter der GPL und damit kostenfrei erfolgen (GPL Nr. 2 Abs. 1 b). Der „virale“ Code unter der GPL „infiziert“ so gewissermaßen das gesamte Programm, allerdings nur auf Source-Code-Ebene, während sonstige Verbindungen von offenen und proprietären Programmen nicht betroffen sind [7].

Müssen alle Codeänderungen offengelegt werden? Immer wieder taucht in der Praxis die Frage auf, ob ein Anwender jede Codeänderung an unter der GPL erstellter Software allen Nutzern (im Internet) zugänglich machen muss. Dies würde jeglichen Einsatz von OS-Software zu Zwecken ausschließen, die etwa Know-how-Schutz verlangen. In der Tat wurde aktuell vertreten, dass jeder, der OS-Software benütze, um Software selbst zu erstellen, gehalten sei, jedermann ohne jede Beschränkung die Sourcen zugänglich zu machen ([3]: S. 8; einschränkend hingegen S. 52). Eine solche Verpflichtung enthält die GPL nicht. GPL Nr. 2 sieht nur vor, dass die Sourcen dann verfügbar gemacht werden müssen, wenn der Code mit den Änderungen verbreitet werden soll. Bleibt der Code im eigenen Gebrauch, muss auch nicht der Quellcode von Änderungen offengelegt werden [4]. Niemand ist aus der GPL verpflichtet, überhaupt Code Dritten zugänglich zu machen. Wird geänderter Code (weiter)verbreitet, ohne dass die Sourcen beigefügt sind oder zum Download bereitgehalten wird, kann ein – allerdings von der Rechtsprechung noch nicht bestätigter – klagbarer Anspruch von Nutzern auf Herausgabe der Informatik_Spektrum_20_Februar_2004

57

} OPEN SOURCE SOFTWARE

Sourcen für diese Änderungen gegen deren Ersteller bestehen, sofern diese Änderungen von diesem zumindest im Objektcode tatsächlich überlassen wurden.

Entwicklung von OS-Software im Arbeitsverhältnis? Wenn es das Wesen von OS-Software ist, vergütungsfrei überlassen zu werden, tritt ein Problem auf, sobald angestellte Programmentwickler gegen Gehalt, also doch eine Vergütung, OS-Software erstellen sollen. Bedeutet dass, das die Entwickler solche Software nur in ihrer Freizeit für ihren Arbeitgeber entwickeln dürfen? Noch nicht abschließend geklärt ist, wie sich dieser Regelungskonflikt lösen lässt. Er hat erhebliche praktische Bedeutung, da Open Source-Software zunehmend auch etwa durch Mitarbeiter von Distributoren entwickelt wird und sich die Frage stellt, ob ein solches Entwickeln im Arbeitsverhältnis als vergütetes nach der GPL überhaupt zulässig ist. Immerhin weist § 69 b Abs. 1 Satz 1 UrhG alle Verwertungsrechte an von Arbeitnehmern erstellten Programmen dem Arbeitgeber zu. Der Arbeitgeber vergütet aber hier, so ein möglicher Lösungsansatz, die Arbeitsleistung des Arbeitnehmers als solche, nicht die (ohnehin schon durch Gesetz erfolgte) Einräumung der Nutzungsrechte vom Arbeitnehmer an den Arbeitgeber ([1]: S. 751). Als Hauptargument hiergegen wird vorgebracht, dass nach dem Urhebervertragsrecht 2002 der Arbeitnehmerentwickler nunmehr aus den §§ 32, 32 a, 43 UrhG einen Anspruch auf angemessenen Ausgleich habe, dessen es nicht bedürfte, wenn der Arbeitnehmer von vornherein keine eigenen Verwertungsrechte hätte ([3]: S. 54). Dieses Argument übersieht aber, dass die gesetzliche Rechtszuweisungsregel in § 69 b UrhG als Sonderregelung in der Reform des Urhebervertragsrechts unberührt blieb und der Arbeitnehmerentwickler gerade keinen zusätzlichen Ausgleichsanspruch hat [5]. Auch das weitere Argument ([3]: S. 54f), dass als „author“ im Sinne der GPL hier der Arbeitgeber zu verstehen sei, nicht der Arbeitnehmer, vermag nicht zu überzeugen. Ihm steht entgegen, dass der Arbeitgeber nach deutschem Recht aus § 69 b UrhG immer nur Verwertungsberechtigter sein und niemals volle Urheberstellung erwerben kann. Abzuwarten bleibt, wie die Rechtsprechung entscheiden wird. In der Zwischenzeit kann sich der Arbeitgeber damit behelfen, die Software wie

58

Informatik_Spektrum_20_Februar_2004

sonst im Arbeitsverhältnis entwickeln zu lassen und sie anschließend aus seiner Rechtsposition als allein Verwertungsberechtigter zur Open Source Software umzuwidmen. Dann ist solche Software aber bei bzw. während der Erstellung durch den Arbeitnehmer noch nicht Open Source, da gegen Vergütung entwickelt. Diese Entwicklung kann ohne rechtlichen Konflikt mit der GPL vergütet erfolgen.

Können Serverrechner mit OS-Software vermietet werden? Da OS-Software nicht gegen Vergütung überlassen werden darf, ist es unzulässig, z.B. Hostrechner mit Linux als Betriebssystem an Kunden zu vermieten ([1]: S. 747; [3]: S. 46). Auch Miete führt zu einer Vergütung, nämlich der Mietzinszahlung durch den Kunden. Die GPL sieht deshalb konsequenterweise auch nicht die Einräumung eines Mietrechts an der Software vor. Außerdem will sie, wie erwähnt, nur das Vervielfältigen, Verbreiten und Bearbeiten regeln, nicht aber andere Verwertungsformen. Damit scheidet eine ausweitende Auslegung aus. Dies schließt auch das Leasing von OS-Software-basierten Systemen aus. Nicht tragfähig erscheint das Argument, es genüge, nur die Hardware zu vermieten, da die OS-Software ohnehin kostenfrei (von einer Kopierpauschale abgesehen) überlassen werde. Dies ist einerseits keineswegs durchgängig Praxis und begegnet andererseits dem Einwand, dass ohne mietweise Überlassung auch der OS-Software der mietende Kunde nicht verpflichtet wäre, mit der Hardware auch die Software bei Mietende zurückzugeben. Dennoch wird hiermit, entgegen ([3]: S. 46), nicht jede Form des Application service providing (ASP) ausgeschlossen. Dieses bleibt nämlich – auch mit OS-Software – zulässig, soweit nur die „reine Funktionalität“ (wie im klassischen Rechenzentrumsbetrieb) zur Verfügung gestellt wird, nicht aber ein bestimmtes Programmexemplar. Der Kunde lässt hier z.B. einfach seine Lohnbuchhaltung auf dem ASP-Serverrechner durchführen und erwartet definierte Verarbeitungsergebnisse, nicht aber den Zugriff auf bestimmte Programme. ASP ist hingegen unter der GPL unzulässig, wenn der Anbieter dem Kunden etwa dedizierte Rechner mit Linux vermietet, das der Kunde dann für eine zeitlich begrenzte Zeit nutzen können soll. In der Praxis bleibt hier nur, jedenfalls am Open Source-

Teil der angebotenen Software klar und deutlich im Vertrag alle Nutzungsrechte auf den Kunden zu übertragen (bzw. wegen GPL Nr. 6 der Übertragung zuzustimmen).

Erfasst die GPL das Bereithalten zum Download? Mit dem neuen Urheberrecht 2003 wurde (in Umsetzung europäischen Richtlinienrechts) das Recht der „öffentlichen Zugänglichmachung“ (§ 19 a UrhG) eingeführt. Hier wurde berechtigt kritisiert ([3]: S. 44, [1]: S. 749 f), dass ein solches Recht in der GPL nicht geregelt ist. Diese will, wie in Nr. 0, Abs. 2 Satz 1 ausdrücklich festgestellt, nichts anderes regeln als „copying, distribution and modification“, also nicht ein „making available“ von Programmen. Dem wurde entgegengehalten, „distribution“ sei nicht eng im Sinne des deutschen Urheberrechts als Verbreiten (gemäß den §§ 17, 69 c Nr. 3 UrhG) zu verstehen (nämlich als Weitergabe eines auf Datenträger, z.B. CD-ROM, verkörperten Vervielfältigungsstücks), sondern im Sinne des US-Rechts weit, also auch die Online-Übertragung umfassend [6]. Dagegen spricht aber, dass dieses US-rechtliche Verständnis im deutschen und allgemeinen EU-Urheberrecht nicht geteilt wird, das vielmehr Verbreiten auf Datenträger und Online-Verfügbarmachen strikt trennt ([3]: S. 44, [1]: S. 750), und für Nutzungshandlungen in der EU allein das in der Computerrechtsrichtlinie geregelte Recht maßgeblich ist. Demzufolge kann das nunmehr in das Recht der EU-Mitgliedsstaaten eingeführte Recht des „making available“ jedenfalls nicht auf der Basis der GPL in der vorliegenden Fassung wirksam Nutzern eingeräumt werden. Diese dürfen hiernach also nicht OS-Software und an dieser durch sie durchgeführte Änderungen online verfügbar machen. Dies stellt ein gravierendes Defizit der GPL dar, da die GPL in ihrer Nr. 2 gerade ein Verfügbarmachen von Sourcen gegenüber jedermann verlangt. Dies wird nur durch Online-Verfügbarmachen auf Serverrechnern möglich sein, da ein Datenträgerversand weltweit von niemandem finanziert werden könnte. Deshalb dürfte es dem Regelungszweck der GPL entsprechen, Nr. 2 der GPL wie folgt zu ergänzen (Ergänzung kursiv markiert): „You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute

and make available such modifications or works ..., provided that you also meet all of these conditions: a) ... b) You must cause any work that you distribute or publish or make available, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.“ Auch in weiteren Absätzen ist jeweils das „making available“ zu ergänzen, soweit „distribution“ geregelt wird. Freilich kann diese Ergänzung nicht in Einzelverträgen erfolgen (da die GPL sonst gewissermaßen zersplittern würde und unklar wäre, welche Rechte der ursprüngliche Lizenzgeber nach GPL Nr. 6 den Anwendern einräumen kann (weshalb GPL-Änderungen im Vermerk vor der Präambel auch ausdrücklich ausgeschlossen sind). Vielmehr ist hierfür eine GPL-Änderung durch die Verfasserin der GPL, die Free Software Foundation erforderlich (und möglich). Sie wird hiermit empfohlen.

Fazit Einige erörterte Probleme lassen sich mit vorhandenen rechtlichen „Bordmitteln“ lösen. Das Recht, OS-Software online verfügbar zu machen, sollte hingegen explizit in die GPL aufgenommen werden, da solche Online-Übertragungen nicht nur für das Proliferieren von OS-Software, sondern auch die Kommunikation der Entwickler untereinander unverzichtbar erscheint. Insgesamt lässt sich aber feststellen, dass das Open Source-Modell in seinem in der Praxis bereits feststellbaren Erfolg nicht durch Rechtsrisiken gefährdet scheint, wohl aber Anstrengungen erforderlich und wünschenswert sind, die rechtlichen Grundlagen noch besser abzusichern. Freilich bleiben alle vorstehenden Ausführungen unter dem Vorbehalt, dass bisher keine (jedenfalls veröffentlichte) Rechtsprechung zur Entwicklung und Nutzung von Open Source-Software vorliegt, also abweichende Beurteilungen nicht auszuschließen sind. Gerade der Umstand des mehrjährigen rechtsstreitfreien Einsatz von OS-Software könnte aber ein Indiz für die interessengerechte Ausgestaltung der GPL sein.

Informatik_Spektrum_20_Februar_2004

59

} OPEN SOURCE SOFTWARE

Literatur Die Ernst Denert-Stiftung für Software-Engineering vergibt unter der Schirmherrschaft der Gesellschaft für Informatik und betreut durch den Stifterverband für die Deutsche Wissenschaft in diesem Jahr erneut ihren Software-Engineering-Preis. Prämiert wird eine hervorragende Arbeit aus dem Gebiet der Methoden, Werkzeuge und Verfahren der Softwareentwicklung. Sie muss anwendbar und praxisorientiert sein. Der Preis ist mit 5.000 € dotiert. Zudem wird eine herausragende Diplomarbeit mit 2.000 € prämiert. Die Jury bittet, aktuelle Arbeiten (2002– 2004) aus Wissenschaft und Wirtschaft bis zum 1. Juni 2004 einzureichen. Erwünscht sind Beiträge über Konzepte des Software-Engineering, über ihren Einsatz in der Praxis sowie Berichte über Werkzeuge. Ausgeschlossen sind lediglich kommerziell vermarktete Produkte.

Software-Engineering-Preis 5.000 € 2.000 € Die Jury: Prof. Dr. Manfred Broy TU München Prof. Dr. Ernst Denert IVU / TU München Prof. Dr. Eike Jessen TU München Prof. Dr. Florian Matthes TU München Prof. Dr. Heinrich C. Mayr Universität Klagenfurt Prof. Dr. Jörg Raasch FH Hamburg

Ernst Denert-Stiftung Software Engineering www.denert-stiftung.de

60

Informatik_Spektrum_20_Februar_2004

Der Preis wird verliehen anlässlich der Informatik 2004 am 22. September 2004 in Ulm. Es ist beabsichtigt, die prämierte Arbeit, falls noch nicht geschehen, in geeigneter Form (auszugsweise) zu publizieren. Die Jury erbittet Arbeiten oder Hinweise auf solche und Fragen an Lehrstuhl für Software Engineering betrieblicher Informationssysteme Ernst Denert-Stiftungslehrstuhl Prof. Dr. Florian Matthes Boltzmannstraße 3 85748 Garching Tel. (089) 289 171 32 [email protected]

Gesellschaft für Informatik e.V.

1. Koch: Handbuch Software- und Datenbank-Recht. Springer, Berlin Heidelberg New York Tokio 2003, S. 127 ff 2. Projekt Client Studie der Landeshauptstadt München, Kurzfassung des Abschlussberichtes, Stand 02.07.2003,Verf. Unilog Management, http://www.muenchen.de/aktuell/clientstudie_kurz.pdf 3. Spindler: Rechtsfragen der Open Source Software, Studie im Auftrag des Verbandes der Software-Industrie Deutschland e.V. (VSI) 2003,http://www.vsi.de/inhalte/aktuell/studie_final.pdf, S. 77 f 4. Koch: Open Source und Urheberrecht – ein Paradigmenwechsel? In: Weber, Berger, auf der Maur (Hrsg.): Geschäftsplattform Internet IV, Open Source, Bd. 22, 2003, 33. (Zur Weitergabeverpflichtung auch: Redeker: IT-Recht in der Praxis, 3. Aufl. 2003, S. 33) 5. Lejeune: IT-Rechtsberater 2002, S. 145, 146 6. Jaeger, Metzger: Open Source Software, S. 33 7. Lee: Open Source Software Licensing, 34, 36; verfügbar unter: http://eon.law.harvard.edu/openlaw 8. DiBona, Ockman, Stone (eds.): Open Sources.Voices from the Open Source Revolution 1999 9. Raymond:The Cathedral & The Bazaar. Musings on Linux and Open Source by an Accidental Revolutionary 1999 10. Schneider: Handbuch des EDV-Rechts, 3. Aufl. 2003, S. 1623