Lieber Matthias,
spontan will ich auch meine sichtweise hinzu fuegen.
- Qualität der Entwicklung
Ist nur nach vorgabe der kriterien bestimmbar. Das gilt auch bei propietaerer software.
Modularisierung, autonome bereiche, datenflusstrukturen, objektbildung, dokumentation der modellierung und implementierung, die textuelle struktur, laufzeit verhalten, vorhersagbarkeit der zeitlichen ablaeufe.
Das hat auch viel mit einzelaktion oder teamarbeit zu tun. Ebenso mit der gewuenschten lebenszeit und anwendungsdichte.
Nur auf der grundlage freier software ist dies ueberpruefbar, um der moeglichen kombinatorik gerecht zu werden. Bei propietaerer software nur mit Re-engineering.
- Life-Cycle-Management
Ich vermute, du meinst versionsverlaeufe. Die problematik ist an die kontinuitaet der entwickler(gruppe) gebunden. Allerdings sind wir nur mit freier software in der lage, selbst hand anzulegen.
- Bewertbarkeit von Sicherheit durch Dritte
Im eingeschraenkten funktionalen raum gilt es fuer beide bereiche. Auch fuer die kombinatorischen simulationen, die nicht real sein muessen. Also nicht in der anwendung entstehen. Wenn wir aber den raum der gesamten kombinatorik untersuchen wollen, brauchen wir den Source-Code, um das kombinatorische potential abschaetzen zu koennen, das auch intern vorhanden ist.
- Verfahren der Schließung von Sicherheitslücken, Reaktionszeit
Auch hier ist die basis bei freier und propietaerer software die gleiche. Erst wenn die entwickler(gruppe) nicht mehr existiert oder nicht reagiert, brauchen wir den Source-Code.
- Rechtliche Verantwortung
Das hat ja Hanne schon deutlich erklaert. Ich kenne mich damit nicht aus.
Generell:
Viele augen sehen mehr. Das setzt die teilnehmer voraus. Im propietaeren bereich ist das limitiert. Im freien bereich offen.
Unter der vorraussetzung, dass aktive anwender existieren, hat die propietaere software keine zukunft. Weder qualitativ, noch unter stabilitaet, noch unter anpassungsfaehigkeit.
Es ist aber nur ein potential. Wenn der konsumismus dominiert, ist es sowieso das gleiche. Dann koennen wir uns mit einer formalen checkliste behelfen, die immer nur einen kleinen teil des funktionalen raums pruefbar macht.
mit lieben gruessen, willi
On 7/4/2017 05:00, Matthias Kirschner wrote:
Ich bin übernächste Woche zu einer Tages-Veranstaltung eingelanden bei der es um die Sicherheitsbilanz von Freier Software geht. Könntet ihr mir noch etwas Rückmeldung dazu geben, wie ihr die Punkte seht?
Zu der Veranstaltung: Im ersten Schritt soll herausgearbeitet werden, welche (für Sicherheit erheblichen) Charakteristika freie Software und proprietäre Software unterscheiden:
- Qualität der Entwicklung (Hierzu habe ich z.B. gestern den Interessanten Artikel gelesen: https://lwn.net/Articles/718411/ )
- Life-Cycle-Management
- Bewertbarkeit von Sicherheit durch Dritte
- Verfahren der Schließung von Sicherheitslücken, Reaktionszeit
- Rechtliche Verantwortung
Im zweiten Schritt soll bei der Veranstaltung ein Raster entwickelt werden, das Anwender von Software anlegen können, um anwendungsspezifisch zu beurteilen, ob für die Sicherheitsanforderungen des jeweiligen Bereichs der Einsatz von freier oder proprietärer Software eine bessere Sicherheitsbilanz aufweist.
Freue mich über Eure Kommentare/Verweise/Anregungen.
Dankeschön Matthias