Massnahmeentscheid des Obergerichts Zürich vom 11. Oktober 2010 / Akten-Nr. LL090002/U

print
Nicht amtliche Leitsätze: Als unterste Grenze der Schützwürdigkeit für Software gilt (auch) in der Schweiz die in Deutschland entwickelte Lehre der „kleinen Münze“. Mit ihr werden einfache, gerade noch schützfähige Schöpfungen mit genügend individuellem Charakter bezeichnet. Die Glaubhaftmachung eine Kopiervorwurfs erfordert den Vergleich des Sourcecodes (E. 5.a). Eine Programmdatei kann als schüztbarer Teil des Computerprogramms betrachtet werden Es genügt daher, wenn die Übernahme eines substantiellen Teils der in der Datei abgespeicherten Programmteile glaubhaft gemacht wird (E. 6.b), Durch das Urheberrecht geschützt sind auch Programmteile, die für sich genommen schutzfähig sind (E. 6.a). Ein Änderung ist nur dann urheberrechtlich relevant, wenn sie einen urheberrechtlich geschützten Programmteil betrifft (E. 5.d). Ein nicht leicht wiedergutzumachender Nachteil kann darin liegen, dass die aus der Urheberrechtsverletzung resultierenden Beeinträchtigungen (Schadenersatz oder Herausgabe des Gewinns) nur schwierig nachzuweisen oder zu quantifizieren sind.

Zusammenfassung des Sachverhaltes: Die Klägerin vertreibt Software für die Aufzeichnung, Bearbeitung und Verbreitung von Lehrveranstaltungen. Die Beklagten 2 und 3 sind ehemalige Mitarbeiter der Klägerin; sie sind per 31. Juli 2009 ausgeschieden. Die Klägerin macht geltend, die Beklagten 2 und 3 hätten den Sourcecode ihrer Software „Switchcast“ unrechtmässig benutzt, um ihre eigene Video- und Bildungssoftware „V. Video MS“ zu entwickeln und über die Beklagte 1 zu vertreiben. Als nicht wiedergutzumachenden Nachteil macht die Klägerin geltend, es sein ihr nicht möglich, im Zeitpunkt eines späteren Gerichtsurteils bereits verlorene Kunden und Marktanteile wieder zurückzugewinnen. Die Beklagten behaupten demgegenüber, bei der ab 1. August 2007 von ihnen entwickelten Software handle es sich um ein neu entwickeltes Produkt mit eigenem Sourcecode.

Erwägungen:
III.

(…)

5. a) Computerprogramme gelten als Werke, wenn sie geistige Schöpfungen mit individuellem Charakter darstellen (Art. 2 Abs. 3 i.V.m. Art. 2 Abs. 1 URG). Individueller Charakter kann einem Programm bereits dann zugebilligt werden, wenn es aus Sicht von Fachleuten nicht als banal oder alltäglich bezeichnet werden kann (BBl 1989 III 523; D. Barrelet/W. Egloff, Das neue Urheberrecht, 3. Aufl., Bern 2008, URG 2 N 25). Als unterste Grenze der Schutzwürdigkeit gilt auch in der Schweiz die in der deutschen Lehre entwickelte „kleine Münze“, mit welcher man einfache, gerade noch schutzfähige Schöpfungen mit genügend individuellem Charakter bezeichnet. Der Grundsatz, wonach Urheberrechtsschutz von Computerprogrammen die Regel und die fehlende Schöpfungshöhe die Ausnahme darstellt (G. Schricker/U. Loewenheim, Urheberrecht, 3. Aufl., München 2006, UrhG 69a N 19), gilt auch in der Schweiz (E. F. Neff/M. Arn, SIWR II/2, 112 und 132; ZR 99 (2000) Nr. 105, 241 f.). Zu den schutzfähigen Elementen eines Programms bzw. der Software gehören der Sourcecode und der Maschinencode (Objektcode) sowie die Programmdokumentation (F. Thomann, in: F. Thomann/G. Rauber (Hg.), Softwareschutz, Bern 1998, 11). Die Glaubhaftmachung eines Kopiervorwurfs erfordert einen Vergleich der verwendeten Sourcecodes zweier Computerprogramme im Rahmen einer Kurzexpertise (Neff/Arn, 325; Thomann, 56).

b) Der Gutachter hat die einzelnen Komponenten der Software der Klägerin („Switchcast“) mit den einzelnen Komponenten der Software der Beklagten 1 („V. VideoMS“) verglichen. Dabei stellte der Gutachter fest, dass die Software der Beklagten 1 in verschiedenen Versionen vorliegt und insofern eine Weiterentwicklung stattgefunden hat. Dem Vergleich wurde die erste Version vom 22./29. und 30. August 2009 und die letzte Version vom 30. November 2009 unterzogen.

c) Die Software der Beklagten 1 dient dem gleichen Zweck wie die Software der Klägerin. Die Programme sind indes von deutlich unterschiedlichem Umfang. Der Gutachter ermittelte (ohne Open Source Software, Drittsoftware, Leerzeilen oder Kommentare) für das Programm „Switchcast“ 87047 Zeilen Sourcecode und für das Programm „V. VideoMS“ 14484 (Version vom August 2009) bzw. 28383 (Version vom 30. November 2009) Programmzeilen. Der Gutachter gelangt zum Ergebnis, dass beim Sourcecode folgende Übereinstimmungsgrade bestehen:

– bei den Komponenten „Switchcast_Recorder“ und „VideoMS_Recorder“ (Aufzeichnungssoftware): 25% (August 2009) bzw. 12% (30. November 2009)
– bei den Komponenten „Switchcast_Producer“ und „VideoMS_Rails“ (Webserverbasiertes Videomanagement bzw. Webserver-basierter Dienst zur Podcastaufzeichnung): 1% bzw. 0,3%
– bei den Komponenten „Switchcast_VideoPlayerAndCuttingTool“ und „VideoMS_Flash“ (Videoabspiel- und Videoschneidsoftware): 0.8% bzw. 0,2%
– bei den Komponenten „Switchcast_Workflows“ und „VideoMS_Tools“ (Zusatzfunktionen, Erweiterungen): 0% bzw. 0%

Einen vollständigen Kreuzvergleich von allen vorgelegten Quelltexten (jeder Codeblock von „V. Video MS“ in jeder Version mit jedem Codeblock von „Switchcast“) erachtete der Gutachter weder möglich noch gefordert. Der Aufwand wäre unverhältnismässig.

d) Der Gutachter hat dazu ausgeführt, die Übereinstimmungen oder Ähnlichkeiten würden sich nicht auf allgemein übliche Ausdrucksformen (banale Teile) oder Software Dritter beschränken. „Switchcast“ und „V. VideoMS“ würden teilweise die gleiche Drittsoftware verwenden. Drittsoftware sei, soweit klar als solche erkennbar, aus dem Vergleich ausgeschlossen worden, da sie für die Beurteilung der Codeähnlichkeit nicht relevant gewesen sei. Bei „V. VideoMS Recorder“ würden sich bei diversen Hilfsfunktionen sowie im „ScreenGrabber“ Übereinstimmungen finden lassen, die nicht banaler Art seien und bei unabhängiger Entwicklung nicht auftreten würden. Bei „V. VideoMS Producer“ und „Flash“ kämen nur in je einer Datei Übereinstimmungen mit „Switchcast“ vor, die sich nicht auf banale Teile beschränken würden. Bei „V. VideoMS Tools“ hätten keine nicht banalen Übereinstimmungen nachgewiesen werden können. Im Sinne einer Gesamtbetrachtung urteilt der Gutachter, die identifizierten Übereinstimmungen beschränkten sich mehrheitlich auf einige Hilfsfunktionen bei „V. VideoMS Recorder“ sowie auf je eine Datei bei „V. VideoMS Flash“ und „V. VideoMS Rails“. Aus den gemachten Untersuchungen, die den stark kleineren Umfang des Codes von „V. VideoMS“ belegten sowie nur eine sehr kleine Ähnlichkeit der Codefragmente aufzeigten, könne geschlossen werden, dass „V. VideoMS“ zum allergrössten Teil eine Neuentwicklung darstelle. Bei den im Bericht aufgezeigten wenigen Übereinstimmungen könne klar gezeigt werden, dass die einzelnen Codefragmente aus „Switchcast“ übernommen worden sein müssten. Im Vergleich zum Gesamtumfang der Software würden diese übernommenen Codefragmente aber einen verschwindend kleinen Teil des Produktes „V. VideoMS“ darstellen.

e) aa) Der Gutachter fand beim sog. Recorder in der Version vom 29. August 2009 15 (namentlich aufgeführte) Dateien und in der Version vom 30. November 2009 14 (namentlich aufgeführte) Dateien mit hoher Ähnlichkeit im Sourcecode, wobei die Zahl der identischen Programmierzeilen von 29% bis 98% pro Datei schwankt. Bei der näher untersuchten Datei „Utility.m“ sind 98% (erste Version) bzw. 70% (letzte Version) der Sourcecode-Zeilen identisch. Die Übereinstimmung bei den aufgeführten Funktionen der Datei „Utility.m“ geht von 47% bis 100%. Unbesehen darum schliesst der Gutachter, dass der grösste Teil der Kernfunktionalitäten des Recorders neu entwickelt worden sei und die Beklagten nicht im grossen Stil kopiert, sondern lediglich leichte Anpassungen vorgenommen hätten.

bb) Beim sog. Producer eruierte der Gutachter – abgesehen von Ähnlichkeiten bei Drittsoftware – die Datei „\lib\qt_info.rb“ mit teilweise übereinstimmendem Sourcecode: In der Version vom August 2009 betrug der Übereinstimmungsgrad 59% (100 von 169 Zeilen), in der Version vom 30. November 2009 noch 41% (45 von 109 Zeilen). Weitere Hinweise auf kopierte Daten wurden nicht gefunden.

cc) Beim sog. Video Player & Cutting Tool wurde nebst Drittsoftware mit hoher Ähnlichkeit wiederum nur eine (kopierte und dann angepasste) Datei gefunden: „htmltemplate\index.template.html“. In der Version vom August 2009 betrug der Übereinstimmungsgrad 71% (32 von 45 Zeilen), in der Version vom 30. November 2009 noch 11% (13 von 121 Zeilen).

6. a) Gemäss Art. 2 Abs. 4 URG sind auch Entwürfe, Titel und Teile von Werken geschützt, sofern es sich um geistige Schöpfungen mit individuellem Charakter handelt. Soweit der entlehnte Teil Werkcharakter besitzt, können auch kleinste Teile eines Werks geschützt sein (sog. Elementenschutz). Auf das quantitative oder qualitative Verhältnis des entlehnten Teils zum Werkganzen kommt es dabei nicht an (Schricker/Loewenheim, UrhG 2 N 67, und Schricker/Wild, UrhG 97 N 9; A. Reuter, Digitale Bild- und Filmbearbeitung im Licht des Urheberrechts, GRUR 1997, 27). Geschützt sind also Programmteile (Routinen), die für sich genommen schutzfähig sind. Insofern ist der Einwand der Beklagten, die gutachterlichen Aussagen betreffend einzelne Dateien seien für sich allein betrachtet nicht aussagekräftig, sie seien vielmehr stets in Relation zum Gesamtumfang zu betrachten, zurückzuweisen. Desgleichen erweist sich der Einwand, die wenigen Übereinstimmungen würden sich auf „Hilfsfunktionen“ und auf unwesentliche Codebestandteile beziehen, als unbehelflich.

b) Der Umfang des Unterlassungsanspruchs korrespondiert grundsätzlich mit dem Umfang des Schutzanspruchs des verletzten Rechts. Wurden nur geschützte Teile eines Computerprogramms durch einen Dritten unbefugt genutzt, erstreckt sich der Schutz nur auf den übernommenen Teil. Vorliegend erfolgte der Sourcecode-Vergleich auf Datei- und nicht auf Einzelfunktionsstufe; einzig die Datei „Utility.m“ wurde einem detaillierten Funktionenvergleich unterworfen.

Eine Programmdatei (als Teil einer Komponente) kann als schützbarer Programmteil qualifiziert werden. Theoretisch wäre sogar danach zu fragen, ob den einzelnen Funktionen als Zusammenfassung von mehreren Befehlen Werkcharakter zukommt. Dass bereits die einzelnen Funktionen als Werkteile mit entsprechendem (auf die Funktion beschränktem) Schutz zu qualifizieren wären, haben die Parteien nicht im Einzelnen dargelegt. Ein Vergleich der Sourcecodes auf Funktionsstufe (im Gegensatz zu einem Vergleich auf Dateistufe) bezeichnete der Gutachter zwar als möglich, aber unverhältnismässig aufwendiger. Weder die Klägerin noch die Beklagten haben einen solchen Vergleich beantragt. Für das Massnahmeverfahren muss es genügen, dass die Klägerin die Übernahme eines substanziellen Teils der in einer Datei abgespeicherten Programmteile glaubhaft machen kann.

c) Der Gutachter hat bei Dateien „mit hoher Ähnlichkeit im Sourcecode“ – insbesondere, was die Version vom August 2009 betrifft – eine fast vollständige, jedenfalls aber eine rund hälftige Übereinstimmung pro Datei festgestellt. Selbst bei der Version vom 30. November 2009 bleiben die vorbestehenden Programmteile der Klägerin für den Gutachter genau erkenn- und quantifizierbar: Die Übereinstimmung beträgt zwischen 11% und 100%. Auch der Sourcecode der Datei „html-template\index.template.html“, der in der Version vom 30. November 2009 nur noch zu 11% übereinstimmende Codezeilen enthält, stellt gemäss Gutachter eine Kopie und nachträgliche Bearbeitung der klägerischen Version dieser Datei dar. Der individuelle Charakter des Originals verblasst in der geänderten Version vom 30. November 2009 somit nicht vollständig.

d) Gemäss Art. 11 Abs. 1 URG verfügt der Urheber über das ausschliessliche Änderungs- und Bearbeitungsrecht. Eine Änderung ist immer nur dann von urheberrechtlicher Relevanz, wenn sie einen urheberrechtlich geschützten Programmteil betrifft. Im weiteren hat der Urheber das ausschliessliche Recht, Kopien von Werkexemplaren herzustellen und solche anzubieten, zu veräussern oder zu vertreiben (Art. 10 Abs. 2 lit. a und b URG). Indem die Beklagten 2 und 3 die vom Gutachter identifizierten Dateien mit (teilweise) übereinstimmendem Sourcecode kopierten, änderten bzw. bearbeiteten und in die von ihnen entwickelte Software integrierten, haben sie die Rechte der Klägerin verletzt. Dabei kann offen gelassen werden, ob die von den Beklagten 2 und 3 vorgenommenen Änderungen ein Werk zweiter Hand darstellen (Art. 11 Abs. 1 lit. b URG). Denn die Schaffung eines Werkes zweiter Hand setzt die Zustimmung des Urhebers des verwendeten Werks voraus (Art. 3 Abs. 4 URG). Ferner hat die Beklagte 1 unbestrittenermassen ihre Software für Videomanagement der Ludwig Maximilian Universität verkauft; sie beabsichtigt, ihre Software auch weiterhin auf dem Markt anzubieten. Indem die Beklagte 1 die geänderten und bearbeiteten Dateien als Bestandteil ihrer Software vertreibt, werden die Rechte der Klägerin ebenfalls verletzt.

7. a) In der Stellungnahme zum Beweisergebnis machten die Beklagten folgende Einwände geltend: Die im sog. Recorder in der Datei „Utility.m“ enthaltenen Funktionen würden meist banale Codefragmente enthalten und aus dem frei zugänglichen Internet stammen. Dabei gehe es immerhin um mehrere 100 Zeilen Code, die von öffentlichen, frei verfügbaren Quellen stammen würden. Zu den Funktionen „fastFolderSizeAtFSRef“ und „applicationSupportFolder“ bzw. „applicationSupportDirectoryPaths“, die mehr als 50 Zeilen Code enthielten, würden sog. Screenshots zum Nachweis eingereicht, dass die Funktionen aus dem Internet stammen würden. Die im sog. Producer enthaltene Datei „qt_info.rb“ enthalte lediglich eine Hilfsfunktion mit absolut banalem Code. Die im sog. Video Player & Cutting Tool enthaltene Datei „index.template.html“ werde lediglich zum Testen des Programms gebraucht, enthalte keinen substanziellen oder wesentlichen und damit geschützten Code. Bereits in der Massnahmeduplik hatten die Beklagten ausgeführt, die im sog. Recorder enthaltene Datei „ScreenGrabber“ stamme aus einem „Open-Source-Projekt“.

b) Ein Programm oder eine Programmsequenz, die mangels Individualität keinen selbständigen urheberrechtlichen Schutz geniesst, gilt als urheberrechtlich frei und darf beliebig geändert werden (Neff/Arn, 214). Nicht schützfähig ist aber lediglich das „völlig Banale“ (Schricker/Loewenheim, UrhG 69a N 19). Freilich kann die nicht naheliegende Auswahl und strukturierte Zusammenfügung unindividueller Bausteine geschützt sein (F. Rauber, Inhalt und Schranken des urheberrechtlichen Softwareschutzes, in: Softwareschutz und Softwarehaftung, Schriftenreihe des Schweizerischen Anwaltsverbandes, Bd. 9, Zürich 1992, 43). Auch an sog. Open Source Software kann die Klägerin keinen Schutz beanspruchen (Neff/Arn, 261; Schricker/Loewenheim, UrhG 69c N 4a). Mit dem Hinweis auf die Unwesentlichkeit (der Datei „index.template.html“) können die Beklagten ihrer Haftung indes nicht ausweichen (vgl. E. III/6.a).

c) Mit den von den Beklagten beispielhaft für zwei Funktionen eingereichten Screenshots lässt sich von vornherein nicht nachweisen, dass übereinstimmende Codefragmente anderer Funktionen auf Drittquellen beruhen. Im Übrigen hat der Gutachter – soweit für ihn als solche erkennbar – Drittsoftware (inkl. Open Source Software) und banalen Elementen Rechnung getragen. Ein formgehöriges Gutachten, das von einem Experten mit der nötigen Sachkenntnis erstellt worden ist, steht über den Parteibehauptungen
und ist beweisbildend. Es kann nicht mit blossen Bestreitungen oder gegenteiligen Behauptungen als Beweismittel entwertet werden. Offensichtliche Widersprüche oder irrtümliche tatsächliche Feststellungen des Gutachters sind nicht erkennbar. Mit den von den Beklagten eingereichten zwei Screenshots und den Hinweisen auf weitere „Open-Source-Bibliotheken“ lässt sich für den nicht fachkundigen Einzelrichter indes nicht sofort belegen, dass die zwei in der Datei „Utility.m“ enthaltenen Funktionen und die in der Datei „ScreenGrabber.m“ enthaltenen Funktionen Drittsoftware bzw. Open Source Software darstellen. Ebenso wenig liegt die Banalität der Dateien „Utility.m“, „\lib\qt_info.rb“ und „index.template. html“ auf der Hand.

d) In seinen ergänzenden Darlegungen vom 28. September 2010 hat der Gutachter aufgezeigt, dass der Inhalt der Datei „ScreenGrabber.m“ nicht Open Source Software darstellt und die Datei „\lib\qt_info.rb“ nicht als banal bezeichnet werden kann. Die Funktion „fastFolderSizeAtFSRef“ hat der Gutachter zwar in einem Internetforum aufgefunden. Doch handelt es sich dabei lediglich um eine Funktion der Datei „Utility.m“ mit 52 Zeilen. Damit verringert sich die Übereinstimmung bei „Utility.m“ von 70% auf 48%, was aber immer noch eine substanzielle Übernahme darstellt und an der Rechtswidrigkeit der Datei nichts ändert. Auch hinsichtlich der Datei „Utility.m“ ist Trivialität mit Rücksicht auf die ergänzenden Ausführungen des Gutachters („Man muss das System kennen, Programmierkenntnisse und Erfahrung haben.“) zu verneinen, weil auch einfache Programme bzw. Programmteile ohne qualitativen oder ästhetischen Wert urheberrechtlichen Schutz geniessen. Gerade die Ausbildung und Erfahrung spielt aber eine grosse Rolle für die Qualität eines Programms und bei der Auswahl von Strukturierungsmöglichkeiten (Neff/Arn, 141). Die Funktion „applicationSupportFolder“ kommt gemäss Gutachter in der Datei „Utility.m“ gar nicht vor.

e) Bei dieser Sachlage kann offengelassen werden, ob für allenfalls direkt aus dem Programm der Klägerin übernommene Drittsoftware der lauterkeitsrechtliche Schutz gemäss Art. 5 UWG greifen würde.

8. a) Art. 65 Abs. 1 URG setzt für den Erlass vorsorglicher Massnahmen einen nicht leicht wieder gutzumachenden Nachteil voraus. Nicht wieder leicht zu ersetzende Nachteile sind überwiegend Nachteile, die im Nachhinein kaum mehr beweis- oder bezifferbar sind (Neff/Arn, 325 f.; L. David, SIWR I/2, 179).

b) Die Beeinträchtigung der klägerischen Rechte ist zwar verhältnismässig gering. Trotzdem muss die Klägerin nicht hinnehmen, dass die Beklagten weiterhin (in geringem Umfang) Programmteile kopieren, bearbeiten und/oder vertreiben. Die daraus resultierenden Beeinträchtigungen, die in Schadenersatz oder Herausgabe eines Gewinns bestehen können (Art. 62 Abs. 2 URG), sind schwierig nachzuweisen und zu quantifizieren, zumal das Programm „V. Video MS“ überwiegend eine unabhängige Entwicklung darstellt und zu beurteilen wäre, inwiefern ein Schaden auf übernommenen Programmteilen beruht oder ein Gewinn der verletzten Rechtssphäre des Geschäftsherrn zugerechnet werden kann.

9. a) Die von Übernahmen betroffenen Dateinamen stimmen in den Programmen der Klägerin und der Beklagten überein. Die Beklagten 2 und 3 sind Organe der Beklagten 1. Es ergibt sich somit, dass den Beklagten 1 bis 3 unter Androhung der Bestrafung (der Beklagten 1 unter Androhung der Bestrafung ihrer Organe) gemäss Art. 292 StGB (Busse) im Falle der Zuwiderhandlung zu verbieten ist, den in nachfolgenden Dateien gespeicherten Sourcecode der Klägerin zu bearbeiten und zu kopieren:
Aus der Komponente Switchcast_Recorder: […]
Aus der Komponente Switchcast_VideoPlayerAndCutting Tool: […]

Der Beklagten 1 ist demgegenüber unter Androhung der Bestrafung ihrer Organe gemäss Art. 292 StGB (Busse) im Falle der Zuwiderhandlung zu verbieten, Software oder Softwarekomponenten zu vertreiben, welche die folgenden abgespeicherten Dateien (alle Versionen) enthalten:
Aus videoMS_Recorder: […]
Aus videoMS_Rails: […]
Aus videoMS_Flash: […].

Im Übrigen ist das Massnahmebegehren abzuweisen.

b) Damit der Inhalt der in den zwei Verboten genannten Dateien für den Vollstreckungs- oder Strafrichter genau bestimmbar bleibt und im Hinblick auf ein ordentliches Verfahren sind die im Urteilsdispositiv genannten (gesicherten) Datenträger und der weitere gesicherte Datenträger samt Schlüssel auch nach Ablauf der Rechtsmittelfristen für die Dauer eines allfälligen ordentlichen Verfahrens bei den Akten zu belassen. Die Schutzmassnahmen dauern fort.

10. In dem Umfang, in welchem die Klägerin mit ihrem Massnahmebegehren obsiegt, ist ihr Frist für die Einleitung des ordentlichen Prozesses anzusetzen, widrigenfalls die vorsorglichen Massnahmen dahinfallen (Art. 65 Abs. 4 URG, Art. 28e Abs. 2 ZGB).

IV. 1. Soweit die Klägerin unterliegt, sind die Kosten- und Entschädigungsfolgen definitiv zu regeln. Soweit die Klägerin obsiegt, wird die Regelung der Kosten- und Entschädigungsfolgen dem Richter im ordentlichen Verfahren vorbehalten.

2. Die Klägerin obsiegt nur in einem sehr bescheidenen Umfang. Insgesamt beträgt die prozentuale Übereinstimmung der Sourcecodes nur 5,1% (August 2009) bzw. 2,8%. Dennoch müssen sich die Beklagten eine Verletzung der klägerischen Urheberrechte vorwerfen lassen, wobei es für die Klägerin mangels Einsicht in den Sourcecode der Beklagten 1 schwierig abzuschätzen war, in welchem Umfang Rechtsverletzungen stattgefunden haben. Es rechtfertigt sich, der Klägerin die Kosten definitiv zu ¾ aufzuerlegen. Im Umfange von weiteren ¼ sind die Gerichtskosten von der Klägerin zu beziehen (§ 67 Abs. 4 ZPO), aber der endgültigen Regelung im ordentlichen Prozess vorzubehalten. Entsprechend ist mit der Prozessentschädigung zu verfahren. Die Klägerin ist zu verpflichten, den Beklagten als Solidargläubiger eine auf drei Viertel reduzierte Prozessentschädigung zu bezahlen. Über den restlichen Viertel wird der Richter im ordentlichen Verfahren zu befinden haben.

a) Die Klägerin hat den Streitwert mit CHF 200’000.- beziffert. Die Beklagten halten einen Streitwert in dieser Höhe für unverhältnismässig hoch, da das durch die Ludwig Maximilian Universität in München generierte Einkommen jährlich lediglich CHF 10’000.- betrage.

b) Die Beklagten setzten ein Vertriebsverbot dem Ruin der Beklagten 1 gleich. Die Beklagte 1 wird auch mit weiteren Universitäten und Hochschulen ins Geschäft kommen wollen. Der von der Klägerin genannte Streitwert erscheint nicht unverhältnismässig. Im Zweifel ist der höhere von den Parteien genannte Streitwert massgebend (§ 22 Abs. 2 ZPO).

[…]

Quelle: sic! 2011 S. 230 ff.
www.softwarevertraege.ch