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
_______________________________________________
FSFE-de mailing list
[email protected]
https://lists.fsfe.org/mailman/listinfo/fsfe-de
