Legacy Code – aber ganz sicher

Jetzt habe ich sie ganz deutlich gespürt: eine Hürde für die Verbesserung der Softwareentwicklung.

Neulich hatte ich über die Clean Code Developer School ein Angebot gemacht: Kostenlose Hilfe beim Frühjahrsputz der Codebasis. Warum nicht mal im Legacy Code aufräumen, wenn die Sonne anfängt zu lachen? Und zu zweit macht das Refaktorisieren noch mehr Spaß. Vier Augen sehen auch mehr Schmutz im Code als zwei.

Als ich nun mit einem Bewerber für die Aktion den ersten Termin absprechen wollte, schrieb der alsbald, dass sein Datenschutzbeauftragter fordere, dass ich eine Geheimhaltungsvereinbarung unterzeichne. O-Ton:

“Wir müssen natürlich sicherstellen, dass keine Informationen das Unternehmen verlassen, bzw. der Quellcode und Kunden-/Unternehmensdaten sicher sind.”

Hört sich das für Sie normal und harmlos an? Für mich nicht. Ich zucke dabei innerlich zusammen.

Da hilft auch keine weitere Erklärung:

“[…] stellen [Geheimhaltungsvereinbarungen] für unser Unternehmen auch eine rechtliche Absicherung für den Fall dar, dass es zu Datenlecks kommt.”

Denn: Was soll abgesichert werden? Ich verstehe das nicht.

Aber ich will versuchen, mich in die Situation hineinzuversetzen:

Der Entwickler des Unternehmens, der sich um Frühjahrsputzunterstützung beworben hat, arbeitet mit mir online im Pair. Ich schaue über Screensharing auf seinen Rechner in die IDE. Wir arbeiten an seinem Legacy Code.

Wo sind da Unternehmensdaten, die nicht nach außen dringen sollen? Achja, der schlichte Fakt, dass es dort im Unternehmen überhaupt solchen immer schwerer wartbaren Code gibt, ist natürlich etwas Geheimhaltungswürdiges. Da geht’s schon los. Ich dürfte ja nie verraten, um welches Unternehmen es sich handelt, das da so tief im Brownfield watet. Davor hat das Unternehmen sicher zurecht Angst.

Oder vielleicht blitzen auf dem Desktop des Entwicklers auch Dokumente auf, die geheimhaltungswürdige Informationen enthalten. Wenn der dann mal eine Pinkelpause macht, nutze ich die Gunst der Stunde und sehe diese bestimmt leicht identifizierbaren Dokumente schnell mal ein oder lade sie gar herunter. Natürlich, um damit bei den zahlreichen Wettbewerbern des Unternehmens hausieren zu gehen.

Oder es könnte sein, dass im Code Featuretoggles zu erkennen sind, die nur für bestimmte Kunden gelten. Das könnte ich auch verraten. Hehe.

Oder wir schauen en passant mal in der Datenbank mit ihren 700 eng verzahnten Tabellen vorbei und ich mache Screenshots von darin gespeicherten Kreditkartennummern (inklusive Namen und Sicherheitscodes), vielleicht stehen auch irgendwo noch unverschlüsselte Passworte. Damit ließe sich bestimmt ein hübsches Sümmchen verdienen.

Nein, so würde es natürlich nicht gehen. Der Datenschutzbeauftragte hat selbstredend ein wachsames Auge auf die Programmierpraktiken der Entwickler. Solche Sicherheitslecks würde es dort nicht mal geben. Aber ich könnte einen Blick auf Kundendaten erhaschen. Dass jemand dort Kunde ist und was er dort als Kunde tut, ist bestimmt auch im Vorbeigehen leicht zu überblicken und zu kopieren und dann in mich bereichernder oder den Kunden schädigender Weise verwendbar. Hehe, hehe.

So stellt sich das der Datenschutzbeauftragte, nein, die Geschäftsleitung, die den Datenschutzbeauftragten beauftragt hat, bestimmt vor. Die Welt ist ein übler Ort. Das Böse ist immer und überall. Und wenn nicht das Böse, dann die Fahrlässigkeit oder Ignoranz. Vor allem bei Externen.

Und dagegen – das ist ja sonnenklar – hilft… eine Geheimhaltungsvereinbarung. Denn dann passiert das alles nicht. Nie. Weil mir natürlich nach der Unterschrift die Knie schlottern ob der Strafbewehrung. Der Kragen wird mir dann ganz eng und ich realisiere, wie vorsichtig, vorsichtig ich sein muss, wenn ich auf den Bildschirm des Kunden schaue. Bloß nichts memorieren! Und wenn, dann noch vorsichtiger in Zukunft sein, dass mir von dem, was ich noch erinnere, nichts über die Lippen kommt. Oder vom Laptop auf ein Speichermedium rutscht, das den Weg in eine Redaktion oder zum Wettbewerber oder auf Facebook findet.

Das war mir vorher natürlich überhaupt nicht klar. Ohne Geheimhaltungsvereinbarung hätte ich wahrscheinlich einen Livestream der online Sitzung geschaltet für alle Software Craftsmen zum über die Schulter schauen. Aber nun, nach Unterschrift… da wäre alles anders.

 

Merkt denn kein Datenschutzbeauftragter, wie lächerlich das ist? (Oder geht hier irgendeine Tragweite und Gefahr völlig an mir vorbei?)

In der aktuellen Ausgabe des Objektspektrum lese ich gerade von Prof. Gerd Gigerenzer die Formulierung “In unserer wachsenden Absicherungskultur…” Das passt wie die Faust auf’s Auge. Genau das ist hier nämlich am Werk: eine Absicherungskultur.

Zusammenarbeit beginnt mit Misstrauen. Wer ohne Ansicht der Sache – hier: online Refactoring-Sitzung – pauschal eine Geheimhaltungsvereinbarung fordert, der stellt sein Gegenüber unter Generalverdacht.

Eine Selbstverständlichkeit, dass man unter Geschäfts-/Kooperationspartnern das Gesprochene vertraulich behandelt, gibt es nicht (mehr).

Auch eine explizite Bitte, die in einer Email sogar dokumentiert werden könnte (und die zumindest dort sicherlich revisionssicher abgelegt wird), ich möge doch alles, was ich sehe/höre vertraulich behandeln, genügt nicht.

Nein, es müssen 1,2,3 Seiten hochoffizieller Geheimhaltungsvereinbarung her. Mit der hat sich eine Rechtsabteilung befasst, die muss archiviert werden und: Die muss ich vor allem erstmal in ihrer Tragweite verstehen. Ohne Rechtsberatung auf meiner Seite kann ich das aber nicht leisten. Für das kostenlose Angebot müsste ich also mal mindestens für 30 Minuten Anwaltskosten aufbringen.

Das ist unverhältnismäßig. Das ist nicht auf Augenhöhe. Das ist nichts, was eine flüssige, vertrauensvolle Zusammenarbeit fördert.

“Aber das Vertrauen kann doch nur entstehen, wenn mann sich sicher sein kann, dass der andere nichts Böses tut. Das erreicht eine Geheimhaltungsvereinbarung.” So lautet bestimmt die Rationalisierung des Datenschutzbeauftragten.

Ich erlaube mir jedoch, anderer Meinung zu sein. Vertrauen entsteht nicht durch einen Vertrag, sondern durch Verlässlichkeit. Wenn ich jemandem nicht vertraue, dann arbeite ich mit ihm nicht. Oder ich wage mich nur so weit vor, wie es mir bei Unzuverlässigkeit nicht schaden würde. Das ist normal und menschlich.

Eine Geheimhaltungsvereinbarung hingegen setzt sich über solch natürliches Vorgehen hinweg und versucht, eine unnatürliche Effizienz herzustellen. Man macht einen größeren Schritt als das eigene Vertrauen zulässt. Das bedeutet, man arbeitet im Misstrauen zusammen.

Kann das bekömmlich sein?

Kurzfristig vielleicht. Langfristig halte ich das für kontraproduktiv. Denn Misstrauen unterliegt auch dem Bestätigungsfehler (confirmation bias). Wenn ich misstraue, dann finde ich eher mein Misstrauen Bestätigendes. Ich stehe also dem Vertrauensaufbau tendenziell entgegen.

Daraus folgt: Ich tendiere dazu, mich noch mehr abzusichern. Und noch mehr. Nach außen, nach innen.

Ob das wirklich etwas bringt, außer Verwaltungsaufwand, ängstlicher Atmosphäre und reziprokem Misstrauen, ist natürlich völlig unklar. Ich erfahre ja nicht, wie es ohne das Misstrauen wäre. Also muss ich glauben, dass ausbleibendes Drama kausal auf diese Absicherung zurückzuführen ist. Die Selbstbestätigung der Absicherungsmentalität ist die Folge.

Klar, so kann man leben. Nur muss man eben auch die Konsequenzen tragen. Hier: Der Legacy Code ist ganz sicher. Sicher in zweierlei Hinsicht: sicher verwahrt und sicher auch noch auf lange Zeit existent.

Da sehe ich tatsächlich einen Zusammenhang, der natürlich dem Datenschutzbeauftragten nicht klar ist.

Dass in dem Unternehmen das Brownfield bis zum Halse steht und vor allem aus Code einer Programmiersprache besteht, die Cobol wohl einmal den Rang ablaufen wird, ist für mich kein Wunder. Absicherungsmentalität – zumindest wie gemeinhin gelebt – kann nicht anders, als am Alten festzuhalten, bis es nicht mehr geht. Neues ist einer Absicherungsmentalität tendenziell unangenehm. Neues ist unbekannt; Unbekanntem kann man kein Vertrauen entgegenbringen; also muss eine Garantie her, dass das Unbekannte keinen Schaden anrichtet. Die Garantie – die natürlich nie eine ist – besteht dann aus Verträgen und Beweisen.

Und am Ende ist das Eigentliche, die Sache, der Kunde zweitrangig. Dann ist Absicherung wichtiger. Das ist das Gegenteil von Agilität. Deshalb sehe ich in diesem Fall einen Bestätigung (klar, auch ich falle dem confirmation bias zum Opfer) für meine These der “Agile Organization Illusion“: nicht jede Organisation kann so agil werden, wie sie scheinbar möchte.

Hier ist es ja offenkundig: der vom Entwickler geäußerte Wunsch nach Verbesserung kann nicht erfüllt werden. Die aus der Organisations-DNA geborene Geheimhaltungsvereinbarung steht dem im Wege. Denn ich unterschreibe sie nicht.

Andere unterschreiben sie natürlich. Das Unternehmen kann sich woanders Unterstützung suchen. Aber damit ist das Grundproblem ja nicht behoben. Die Geheimhaltungsvereinbarung selbst ist ja nicht das Problem. Sie ist nur ein Symptom für das wahre Problem: Absicherungs- und Misstrauenskultur.

Ich finde das tragisch. Denn die einzelnen Menschen im Unternehmen wollen ja das Gute. Der Entwickler ist ehrlich an der Verbesserung des Codes interessiert. Auch der Datenschutzbeauftragte hat einen grundsätzlich wichtigen Job in der heutigen Zeit. Trotzdem wird nicht das Beste erreicht. Sehr schade.

Es wird an Stellvertreterschauplätzen gekämpft, z.B. mit mir als kleinem Dienstleister, der mal über die Schulter schaut.

Doch was ist eigentlich mit echten Risiken für Lecks? Was ist eigentlich mit dem Code? Hat der Datenschutzbeauftragte eine Ahnung, welches Datensicherheitsproblem Legacy Code darstellen kann?

Er hat Angst davor, dass Code das Unternehmen verlässt. Wie lächerlich! Code, den die eigenen Entwickler kaum mehr verstehen, ist für andere ohne Anleitung gar nicht mehr verständlich. Der Code könnte in vollem Umfang auch bei Github in einem öffentlichen Repo liegen und nichts würde passieren. (Naja, vielleicht gäbe es “überraschte” Kommentare ob des Brownfields.)

Wie steht es mit Regressionen? Macht der Datenschutzbeauftragte sich Gedanken darüber, dass durch unübersichtlichen Code und Regressionen Daten falsch gespeichert, falsch zugeordnet oder gar gelöscht werden könnten? Was ist mit unvollständigem Verständnis der Domäne und des Codes durch Kommunikationsprobleme innerhalb des Teams aufgrund von Kultur- und Sprachdifferenzen? Liegt darin kein Risiko, dass Code entsteht, der Daten leckt? Mitarbeiterverträge sichern dieserlei nicht ab.

Aber nun genug. Mir gehts um die Verhältnismäßigkeit. Ich kenne auch das Muster: lieber ein (vermeintliches) Problem lösen, das ich verstehe, als ein echtes und großes. Das scheint mir hier pars pro toto auch am Werk.

Schade. Ich hätte gern meine Zeit verschenkt, um bei der Säuberung des Codes zu unterstützen. (Naja, hoffentlich hätte ich dabei auch etwas gelernt.) Aber nicht unter diesen Umständen. Ohne Vertrauen habe ich keine Lust zu arbeiten. Auch wenn ich zugezogener Hamburger bin, finde ich das Hamburger Kaufsmannsbild erhaltenswert: man geht eine Kooperation per Handschlag ein. Das kann man, weil man ein Wertesystem teilt. Zu dem gehört natürlich auch Vertraulichkeit.

Posted in Deutsche Beiträge.

13 Comments

  1. nun ja, es gibt es eine eindeutige regeln im bereich datenschutz, die von unternehmen eingehalten werden müssen. Aandernfalls kann die verantwortliche führungsposition verantwortich gemacht werden – vertrauen hin oder her. D
    Dem Datenschutzbeauftragten/ der GF ist es – verständlicherweise – wichtiger sich an die gegebenen Regeln zu halten als von einer subjektiven “brownfield” beurteilung beunruhigt zu werden.
    Als Freiberufler (zugegeben nur für größere Unternehmen unterwegs) musste die letzten 5 Jahre immer eine solche Erklärung unterschreiben.
    Bevor du dich weiter auf den schlipps getreten fühlst mach es dir doch einfach: Biete deine Leistung ganz normal als Dienstleistung an, dann musst du nach deutschem Recht die Datenschutzvereinbarung so oder so unterschreiben. Falls dir das Thema Datenschutz und/ oder formale Vereinbarungen nicht passen geh doch lieber auf die Suche nach Unternehmen, die davon noch nix gehört haben.

    • Wenn ich dich richtig verstehe, spielst du auf § 5 BDSG an (https://dejure.org/gesetze/BDSG/5.html). Dabei geht es aber um die Verpflichtung auf ein sehr spezifisches Datengeheimnis (personenbezogene Daten), nicht um eine Geheimhaltungsvereinbarung, wie sie im vorliegenden Fall in Rede steht.

      Weiterhin bin ich nicht Angestellter oder Praktikant und schon gar nicht regelmäßig in dem Unternehmen tätig.

      Und schließlich: Es ging gar nicht um personenbezogene Daten, sondern Quellcode. Der ist dem BDSG ziemlich egal, würde ich sagen.

      Als Freiberufler musste ich übrigens auch in großen Unternehmen in den vergangenen Jahren nicht eine Geheimhaltungserklärung unterzeichnen.

      Eine Geheimhaltungserklärung fällt nicht unter das BDSG, sondern ist ein freiwilliger Vertrag. Deshalb spreche ich nicht von Gesetzestreue, sondern von Absicherungsbedürfnis. (Dass das auch auf gesellschaftlicher Ebene existiert, ist eine andere Sache.)

      Und das beginnt schon hier: Ich bin öffentlich – du bist geheim. Warum? Wovor fürchtest du dich? Du nimmst dein gutes Recht wahr. Das ist natürlich ok. Aber “gutes Recht” ist nicht immer “höfliche Umgangsform”. Sehr schade, dass du es vorziehst, eine Maske aufzusetzen. In so einer trivialen Sache. Meinst du, dadurch Chancen auf zukünftige Projekte in größeren Unternehmen zu verspielen? Das wäre bitter. Und sagt noch mehr über die Gesellschaft aus.

      Ich fühle mich übrigens nicht auf den Schlipps getreten. Die Sache habe ich ganz unemotional abgehakt. Es ging ja überhaupt nicht um meine Person.

      Dennoch habe ich darüber geschrieben, weil sich hier ein Muster in Bezug auf die Sache zeigt. Und es tut mir für den Entwickler leid.

  2. Wie wäre es, wenn du nach der Pair Session mit dem Entwickler geblitzdingst wirst? Dann weißt du nix mehr von dem Code.

  3. Ich sehe an einer rechtlichen Absicherung keinen Generalverdacht, sondern eher einen Nachweis, dass man seine Partner angewiesen hat, die gleichen Maßstäbe beim Thema Sicherheit anzulegen wie das eigene Unternehmen.
    Und auch, wenn der Quellcode selbst keine Persönlichen Daten enthält, ist es doch schnell geschehen, dass diese zugänglich werden. Von einem externen Dienstleister erwarte ich nicht, dass er das schamlos ausnutzt – sonst wäre er wohl ganz schnell in der Branche nicht mehr tragbar. Aber Sollte es irgendwo ein schwarzes Schaf geben, dass eben doch mal relevante Informationen abgreift und auf irgendeine Art und Weise ausnutzt, dann möchte ich doch mindestens unseren Kunden gegenüber nachweisen können (ja, ich weiß, Nachweiskultur…), dass wir unser möglichstes getan haben, um unser Versprechen zu halten.
    Vertrauen ist eine tolle Sache aber in der heutigen Geschäftswelt leider nicht viel wert. Man erlebt doch immer öfter, das derjenige, der vertraut am Ende der Dumme ist. (Das klingt jetzt wohl etwas pessimistischer als es soll, aber ich denke, die Aussage wird klar).
    Dem Datenschutzbeauftragten ist in diesem Falle vermutlich tatsächlich egal, wie der Code aussieht. Er hat sicher strikte Vorgaben / Regeln / Policies und die lassen für gewöhnlich keinen Spielraum. Wenn das Unternehmen festgelegt hat “Keine Zusammenarbeit ohne Geheimhaltungsvereinbarung”, dann wird der sich da sicher nicht drüber hinwegsetzen.

    Für den Entwickler tut es mir auch leid. Ganz so erschocken und zusammen gezuckt bin ich jedoch nicht, da ich in meiner beruflichen Laufbahn dieses Vorgehen als übliche Praxis in vielen Unternehmen kennen gelernt habe.

  4. Hallo Ralf,

    das prinzipielle Problem deines Artikels kann ich, glaube ich, nachvollziehen. Es gibt Gelegenheiten in denen Datenschutzbestimmungen einfachste Vorgänge ad absurdum führen und realitätsferner nicht sein könnten.
    Ich habe mal von einem Fall gehört, in dem sich die Beauftragten zweier Firmen stritten in welchem Firmengebäude das Meeting zur Kooperation stattfinden sollte. Beide Firmen beharrten darauf, dass Ihre interna in ihrem jeweiligen Hause blieben. So wurde nichts aus der Zusammenarbeit, die beide Seiten eigentlich wollten und für Sinnvoll erachtet haben.

    In dem von dir beschriebenen Fall kann ich nachvollziehen, dass Du irritiert warst diese Erklärung unterschreiben zu müssen, da Du ja schließllich kostenlose Hilfe angeboten hast. Ein Geschenk sozusagen. Letztendlich hast Du ja recht, dass man nicht einfach alles unterschreiben sollte, sondern sich vorher mit dem Inhalt auseinandersetzen sollte. Das ist unverhältnismäßig für das was Du bietest.

    Andererseits kann ich die Firma auch verstehen, da Du als externer eben ein “Risiko” darstellst. Du hast prinzipiell keine Loyalität oder anderweitige Bindung zu der Firma. Wenn Du, wie Du ja schon in deinem Beitrag ausgiebig dargestellt hast, den speziellen Legacy Code der Firma so schrecklich findest, was sollte dich davon abhalten einen Beitrag zu schreiben in dem Du den Namen der Firma und Beispiele dieses schrecklichen Codes erwähnst?

    Natürlich könnte die Firma das Ganze auch andersherum sehen und sich so darstellen, dass sie Größe gezeigt hat, indem sie externe Experten heranholt häßlichen Code professionell zu entfernen. Das wäre ein Klasse PR ala “Wir tun alles für unsere Kunden”. Letztendlich allerdings kommt es dann wieder auf den O-Ton dieses von dir verfassten imaginären Artikels an, ob potentielle Kunden das auch so sehen.

    Der Hamburger Handschlag ist eine super Sache, nimmt aber nur an, dass die Einschlagenden nach den selben Prinzipien verfahren. Ein Vertrag hält diese Prinzipien schriftlich fest.
    Verstehe mich bitte nicht falsch. Ich mag es auch lieber nach mündlichen Absprachen und Handschlägen zu arbeiten. Leider ist es aber auch schon häufig genug daneben gegangen. Und das ist dann sehr ärgerlich (und ggf. teuer). Gesundes Mißtrauen hat nichts mit Paranoia zu tun.
    Und so ein bißchen auf den Schlips getreten scheinst Du dich schon zu fühlen, dass deine Reputation als Autor und Mentor der Firma nicht gereicht haben zu scheint dir zu Vertrauen. (Was übrigens vollkommen verständlich ist)

    Vielleicht wäre in diesem Falle ein Datenschutz Light die richtigere Variante gewesen.
    Kritikwürdiger als den Datenschutzbeauftragten würde ich allerdings die steife Unternehmensstruktur sehen, die halt nur nach Schema F kann.
    Letztendlich Pech für die Firma.

    Ein bisschen mehr Vertrauen zurückgewinnen wäre eine super Sache. Dummerweise wurde es ja aber häufig genug ausgenutzt, sodass Verträge die Handschläge ersetzt haben. Ich würde dem anderen nicht gleich unterstellen, dass er mir böses unterstellt wenn ich eine Datenschutzerklärung unterschreiben soll. Jedenfalls nicht auf Geschäftsebene. Da sind halt schlechte Erfahrungen und viel Geld im Spiel.
    Schlimmer und ernsthaft verletzend ist, wenn Bekannte und Freunde einem Geschäftsideen nicht anvertrauen, weil sie meinen, sie werden um ihre goldene Gans gebracht.

  5. @Sebastian: Ich habe nicht erwartet, dass da ein Datenschutzbeauftragter mich kennt. Mir gehts um Verhältnismäßigkeit. Das sehe ich auch ganz unpersönlich. Deren Verfahren hat nichts mit mir zu tun. Und genau das ist der Punkt: so wird (fast) überall gehandelt. Erst mal absichern – der Rest ist dann schon fast Nebensache.

    Wie könnte es andersherum gehen? Wenn ich mein Gegenüber nicht kenne, ihm nicht vertraue, dann lasse ich es eben. Oder ich baue langsam ein Verhältnis auf. Schrittweise. Immer ein Stück mehr vertrauen.

    Und den Rest regelt normalerweise das BGB oder sonst ein Gesetz ohnehin. Mit mir macht ja auch niemand einen Vertrag, in dem er darauf hinweist, dass ich kein Eigentum mitnehmen darf.

    Auch habe ich nichts gegen Klarheit. Irgendwo zusammenfassend festhalten, was die Eckdaten einer mündlichen Absprache sind, ist doch ok. Eine Geheimhaltungsvereinbarung oder auch der übliche Beratervertrag sind keine solche Protokolle von Absprachen. Es sind diktierte Konditionen. Da geht die Augenhöhe verloren.

    Aber ich wiederhole mich 😉

    Den Fall wollte ich hier exemplarisch zur Kenntnis bringen. Ist für mich ein Symptom für die Behinderung von Veränderungen. Wer Veränderungen will (gar Innovation), der muss seine Absicherungsmentalität reflektieren und womöglich ablassen von liebgewonnenen Gewohnheiten. Innovation bedeutet, Neuland zu betreten. Neuland ist per definitionem risikobehaftet und unsicher.

    Nun, es jeder für sich entscheiden, wie absicherungsbedürftig er/sie ist.

  6. Eine höhere Person aus dem Unternehmen hätte dir vielleicht auch so eine Freigabe erteilt ohne den Vertrag. Der Datenschutzbeauftragte hat nur seinen Job gemacht. Sonst wäre er ja über.

    Bei freiwillig kostenloser Arbeit würde ich aber auch keinen Vertrag unterschreiben in dem steht, dass man 1 Millionen Euro zahlen “will”, wenn Informationen nach außen dringen. Da reicht schon ein Spionage Programm von einem Hacker, welches noch zusätzlich bei der Session dabei ist, und schon wird man zur Kasse gebeten.
    Das macht echt keinen Sinn.

    Wenn jemand beim Umzug kostenlos hilft und dem fällt der Fernseher runter kann der ja auch nicht in Regress genommen werden, wenn er das nicht absichtlich gemacht hat. Sonst müsste man ja auch allen die beim Umzug helfen erstmal einen Vertrag zum unterschreiben vorlegen. Mal schaun wie viele dann noch kostenlos helfen wollen 😉

    Ich denke mal, wenn man absichtlich einer Firma schadet (auch ohne Vertrag) kann man auch vor Gericht landen. Wäre das nicht so, dann wären die mp3-Tauschbörsen legal oder?
    Also wozu einen Vertrag? Anscheinend nur, um einen Schuldigen schnell benennen zu können und auch gleich die Straf-Auszahlungshöhe vereinbart zu haben.
    Noch ein Grund sowas nicht zu unterschreiben (falls sowas in deinem Exemplar geregelt war).

  7. Es geht bei diesen Vereinbarungen ja nicht immer nur um Kundendaten oder ähnliches. Manchmal steckt in einem Stück Quellcode (egal wie konfus er ist) ein Quäntchen Intelligenz, den die Konkurrenz nicht sehen soll. Und egal welche Absichten du verfolgst, wollen sich Unternehmen gegen die Verwendung dieser Intelligenz woanders schützen.

  8. Nun ja, ohne den Fall speziell zu kennen kann es doch auch der legacy code ein Kunden Projekt gewesen sein, bei dem eben die Firma selbst eine entsprechende Vereinbarung unterzeichnen musste. Das ist jedenfalls bei uns, wo es viel embedded Programmierung gibt, ziemlich üblich, bevor überhaupt mit einem Projekt angefangen wird. Bei sagen wir mal despektierlich “Business Gedöns” kommt das vielleicht weniger häufig vor. Egal wie realistisch nun die Bestimmungen einer solchen Vereinbarung sind, schlimmstenfalls bleibt es eben an dem hängen, der nicht aufgepasst hat. Letzlich wird damit eben eine “offizielle” Geschäftsbeziehung dokumentiert. Dass das für kostenlose Angebote sehr kontraproduktiv sein kann, ist ja unbenommen. Wie gesagt, da über die Firma und den Code nichts gesagt wird ist das Risiko schwer zu bewerten. Im Falle von Code für hoch kritische Infrastruktur Anwendungen (was vmtl. nicht der Fall war) würde ich mich aber nicht wundern, wenn Telesessions sehr kritisch beäugt würden. Wie gesagt, letztlich sind die allgemeinen Umstände ausschlaggebend, ob so eine Vereinbarung “lächerlich” ist oder nicht. Im Falle diverser Datenleaks auch kritischer Daten in der letzten Zeit finde ich jedenfalls die grundsätzliche Aussage ziemlich hemdsärmelig. Solange es nicht einem selbst passiert ist, und sei es ein blöder Verschlüsselungstrojaner kann man immer gut lästern.

    • “Hemdsärmelig”… hm… Das Problem ist doch, dass die Unterschrift am Ende nicht wirklich einen Unterschied macht. Sie stellt kein Vertrauen her. Damit wird es nicht weniger wahrscheinlich, dass Daten lecken. Ich erinnere mich an den Spruch “It’s not whether you win or lose. It’s how to place the blame.”

      Und nochmal: Ich behaupte nicht, dass es nie Sinn macht, etwas durch mehr als einen Handschlag zu besiegeln. Ich stelle nur anhand eines Beispiels in Frage, ob das wirklich so häufig der Fall sein muss. Eine “Absicherungsgesellschft” ist essenziell süchtig. Denn Sicherheitsbedürfnis kann nie durch äußere Maßnahmen endgültig befriedigt werden. Doch die Illusion herrscht vor: in Unternehmen, in der Politik.

      Nach Benjamin Franklin (?): Wer sicher sein will, gibt seine Freiheit auf. Oder eben seine Produktivität. Oder seine Wandlungsfähigkeit.

      Das ist ja auch völlig ok. Darf jeder leben, wie er mag. Nur muss man eben auch mit den Konsequenzen leben. Bürokratie ist das Gegenteil von Innovation und Wandlungsfähigkeit. Das ist auch ihr Sinn. Nur wie lange macht das Sinn?

      Die Antwort auf die heutigen Zeiten, in denen es um Flexibilität und Innovation geht, wenn man am Markt was werden oder bleiben will, ist im Moment anscheinend mehr Bürokratie. Das lässt mich den Kopf schütteln.

      • Die Unterscheidung zwischen dem konkreten Fall und der allgemeinen Sicherheitskultur ist sicher richtig. Und auch, das eine Unterschrift und ein Vertrag ohne den Willen, diesen auch einzuhalten unter dem Strich nichts wert sind. Nur ist es halt auch so, dass ja in vielen Fällen bei sicherheitskritischen Dingen eben sehr “hemdsärmelig” vorgegangen wird. Man muss sich ja nur mal die Sicherheitslücken im Code zahlreicher Medizinprodukte anschauen. Aber prinzipiell kann ich mich der Einschätzung anschliessen, dass ein inflationärer Einsatz von solchen “Geheimhaltungsvereinbarungen” sicher nicht das Ergebnis bringt, das man vielleicht gerne hätte. Und ob es wirklich wünschenswert ist, sei auch mal mit einem großen Fragezeichen versehen. Lustigerweise sieht man ja, dass Geheimhaltung immer seltener durchzusetzen ist, wie die vielen Leaks der letzten Jahre zeigen. Dem versucht man nun, so entgegenzuwirken. Mit sicherlich fragwürdigem Erfolg. Die Gefahr, dadurch wirklich sicherheitskritische Akspekte nur durch die wirtschaftliche Geheimniskrämerei zu übersehen ist sicherlich ein Nebeneffekt, den so die wenigsten sehen werden. Gerade das dürfte aber in der zunehmend vernetzten und softwareabhängigen Welt ein viel größeres Problem darstellen.

  9. Geht es hierbei wirklich um “Schutz”? … oder geht es eher um “Abschreckung”? … vielleicht ja auch um “Schadensbegrenzung”? … oder wenigstens um Risikominimierung”? … oder ist es gar ein “Drohung”? … vielleicht sogar eine “Existenzbedrohung”?
    Was kann man mit einem solchen Vertrag wirklich schützen?
    Wenn ich mit einem potentiellen Dieb einen Vertrag mache, fühlt sich dieser dann auf einmal genötigt nicht mehr zu stehlen?
    Oder wird eine ehrliche Haut ohne eine solchen Vertrag gar zum Dieb?
    Fragen über Fragen!
    Ich glaube solche Verträge gehen irgendwie am Thema vorbei. Und ich glaube auch, dass die Festsetzung einer pauschalen – meist unverhältnismäßig hohen – Schadensersatzsumme, oft nur die Rechtschaffenden abschreckt. Nämlich diejenigen, die sich nicht streiten wollen und sowieso Skrupel haben. Denn diese vertrauen ihrem Gegenüber – bei Vorlage eines solchen Vertrages – auch nicht mehr und haben Angst in die “Falle gelockt” zu werden oder zumindest versehentlich etwas falsch zu machen.

Comments are closed.