Bevorzugung von Open Source Software in öffentlichen Ausschreibungen

Hailfinger, Carl-Daniel Carl-Daniel.Hailfinger at bsi.bund.de
Mo Mär 18 21:43:12 UTC 2019


Hallo zusammen,

das Folgende ist meine private Meinung.

Erik Albers <eal at fsfe.org> schrieb am Mittwoch, 27. Februar 2019, 16:54:25
> On 27.02.19 08:40, Christian Imhorst wrote:
> > Hallo zusammen,
> >
> > die Bundesregierung hat gestern auf eine Anfrage zur "Verhinderung von
> > digitalen Monopolen durch verstärkte Nutzung freier Software"
> > geantwortet:
>
> Ich finde ja insbesondere auch diesen Passus relevant:
>
> 	Wird bei Ausschreibungen der Bundesbehörden für Software-
> 	Dienstleistungen eine freie Nachnutzung im Sinne von freier Software
> 	vorgeschrieben?  Wenn nein, warum nicht?
>
> 	Nein. Eine grundsätzliche Forderung von freier Nachnutzung
> 	widerspricht in vielen Fällen dem Sparsamkeitsprinzip der
> 	Bundeshaushaltsordnung (BHO), da sie den einzelnen Vergabegegenstand
> 	unnötig verteuern würde. Die Behörden sind gehalten zu prüfen, welches
> 	Ausmaß an Nutzungsrechten sie benötigen, um die gestellte fachliche
> 	Aufgabe zu lösen. Das haushalterische Sparsamkeitsprinzip verlangt
> 	grundsätzlich, keine den Bedarf übersteigenden Anforderungen zu
> 	stellen.
>
> "... da sie den einzelnen Vergabegegenstand unnötig verteuern würde"?
>
> Das ist doch gedanklicher Humbug. Wenn ich das richtig verstehe, dann sagen
> sie quasi, dass der Einkauf Freier Software einmalig teurer kommt als der
> Kauf einer einmaligen Nutzungslizenz.
>
> Das dem so ist kann ich gut nachvollziehen, weil der Hersteller Freier
> Software eben nicht eine eimalige Entwicklung per Lizenz beliebig oft
> melken kann. Aber das Argument der Sparsamkeit zu verwenden schreit doch
> hier vor lauter nicht-Nachhaltigkeit und macht für mich so viel Sinn wie
> eine Aussage a la "Das Sparsamkeitsprinzip verbietet den Kauf eines
> Dienstwagens, da die einzelne Fahrt mit einem Taxi günstiger ist" ...

Den Zahn musste ich mir leider schon mehrfach ziehen lassen, und ich hab es 
wirklich versucht. Das NIH-Syndrom ist bei freier Software so stark wie bei 
proprietärer Software, dass es mehr kostet oder sich gar kein Bieter findet, 
existierenden Code erweitern zu lassen, und daher oft die wirtschaftlichste 
Lösung ist, den ganzen Code nochmal neu zu schreiben oder den alten 
Auftragnehmer nochmal zu beauftragen.
"Igitt, Python, wir machen PHP" "Igitt, PHP, wir machen Java" "Igitt, Hadoop, 
wir machen Elasticsearch" usw.
Und nein, Einpersonenklitschen, die sowas prinzipiell stemmen könnten, 
scheitern schon daran, dass sie keine sinnvolle Vetretungsregelung bei 
Krankheit etc. anbieten können.
Größere Anbieter machen das dann mit fremdem Code prinzipiell schon, aber zu 
den üblichen Schmerzensgeld-Stundensätzen, und da kann man den Code auch 
gleich zu normalen Stundensätzen neu schreiben lassen.
Effektiv wird oft die initiale Programmierung billig angeboten, weil davon 
ausgegangen wird, dass auf Folgeaufträge eh niemand anders bietet.

Die rühmliche Ausnahme waren Auftragnehmer, die alle Änderungen immer sofort 
Upstream eingepflegt haben (und nein, wenn sie selber Upstream sind, zählt 
das nur eingeschränkt). Das schützt zwar nicht gegen NIH, aber mit 
ungepatchtem Upstream findet man wesentlich mehr Anbieter, die das für 
bezahlbar Geld pflegen und/oder weiterentwickeln.

Wo man mit freier Software punkten kann:
- Gebündelte Beschaffung: Zwei Behörden/Bedarfsträger brauchen die gleiche 
Lösung, wollen aber nur einmal bezahlen. Da müssen aber beide 
zusammenarbeiten, damit das geht.
- Bei proprietären Lizenzmodellen, die nutzungsabhängig abrechnen. Da muss man 
die geplante (realistische!) Ausbaustufe in die Wirtschaftlichkeitsrechnung 
mit reinnnehmen (d.h. eben nicht die Minimalvariante, sondern die 
Normalvariante), und das über den gesamten Nutzungszeitraum statt nur 1 Jahr.
- Bei Software, die im Hause weiter- oder fertigentwickelt werden soll, weil 
man dem Auftragnehmer nicht die Auswertealgorithmen nennen möchte 
(Betrugserkennung o.ä.).
- Bei erhöhtem Sicherheitsbedarf, und es existiert bereits eine auditierte 
Freie-Software-Codebasis. "Sie können ja gerne Ihren proprietären Code 
auditieren lassen, aber dafür zahlen wir nicht extra." Das ist eine sehr 
effektive Keule, aber man muss den Sicherheitbedarf gut begründen können. Es 
handelt sich auch nicht um eine unzulässige Markteinschränkung, da dem 
Auftragnehmer freigestellt ist, eigenen Code zu entwickeln und/oder fremden 
Code zu nutzen.
- Uneingeschränkte Quellcodeeinsicht für Dritte zwecks Analyse ohne Einbindung 
des Auftragnehmers. D.h. der vollständige Quellcode liegt dem Auftraggeber 
(mit oder ohne NDA) vor, und der Auftraggeber ist befugt, den Quellcode an 
einen Dienstleister seiner Wahl zu Analysezwecken zu übergeben. Der 
Analyse-Dienstleister ist dann nur ggü. dem Auftraggeber verpflichtet. 
Überraschenderweise eine sehr effektive Keule, aber man muss den 
Sicherheitsbedarf (Analyse) gut begründen können.

Stichhaltige Begründungen kosten Aufwand (die Beschaffer und die Juristen). 
Dito für Wirtschaftlichkeitsrechnungen. Es lohnt sich aber. Bei Beschaffungen 
sollte man auf die (harten) A-Kriterien fokussieren, nicht auf die (weichen) 
B-Kriterien.

Ende der privaten Meinung.

Viele Grüße
Carl-Daniel



Mehr Informationen über die Mailingliste FSFE-de