Hallo zusammen, das Folgende ist meine private Meinung.
Erik Albers <[email protected]> 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 _______________________________________________ FSFE-de mailing list [email protected] https://lists.fsfe.org/mailman/listinfo/fsfe-de Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt. Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu behandeln: https://fsfe.org/about/codeofconduct
