Jawność źródeł oprogramowania, od którego zależy sytuacja prawna

Specjalistą od programowania mikro-kontrolerów nie jestem, ale sądzę iż firma, która pisała ten soft mogła by się wybronić ze sporej ilości rzekomych "błędów".

Nawet oprogramowanie "dobrze" zaprojektowane może zawierć błędy wliczając w to błędy architektoniczne.

Co do konsekwencji działania takiego oprogramowania, to jest to kwestia pewnych standardów. Zamawiający oprogramowanie (wraz z urządzeniem) powonień być świadom jakie normy takie oprogramowanie musi spełniać i jakie certyfikaty/audyty posiadać. Alkomat to jeszcze nie jest tak groźne urządzenie jak urządzenia, które sterują niebezpiecznymi procesami jak:
- elektrownie atomowe
- zakłady chemiczne
- aparaty rentgenowskie oraz tomografy

Czytałem kiedyś o tomografach, które uśmiercały nadmiernie naświetlając "stałych klientów". Z życia natomiast najczęściej miałem do czynienia z maszynami odlewniczymi i słyszałem historie od naocznych świadków, jak maszyna zamknęła w sobie operatora lub wystrzeliła przy otwartej formie. To ostatnie może być bardzo niebezpieczne bo to tak jakby strzelać ciekłym metalem (prędkości wylotowe dochodzą do 50m/s) a jak mamy do czynienia z magnezem wówczas są to bardzo niebezpieczne sytuacje.

Problem można też rozwiązać stosując odpowiednie technologie oprogramowywania, oprogramowanie sterowników PLC jest z natury bardziej bezpieczne bo jest mniej "błędogenne", choć też zawiera błędy. Ciekawą alternatywą dla oprogramowania mission critical jest projekt COSA.

Nie wiem jak wygląda sprawa przy elektrowniach i tego typu instalacjach, w pozostałych przypadkach jest najczęściej tak, iż w przypadku błędu oprogramowania jest ono sprawdzane czy faktycznie "awaria" wynikała z błędu w oprogramowaniu.

Pozdrawiam
Anonimowy tchórz - programista

Laboratoria akredytowane zgodnie z norma ISO/IEC 17025 mają obowiązek "certyfikowania" używanego oprogramowania. Sytuacja (w praktyce) jest bardzo trudna, bo z jednej strony w powszechnym użyciu jest niewolne od błędów oprogramowanie biurowe, a z drugiej: praktycznie każde urządzenie pomiarowe dziś to komputer z odpowiednim oprogramowaniem.

Na seminarium poświęconym różnym problemom certyfikacji laboratoriów badawczych przedstawiciel firmy HP (potężnego niegdyś producenta sprzętu pomiarowego) opisywał jak z prośbą o udostępnienie kodu źródłowego (w związku z audytem) zgłosił się przedstawiciel dużej firmy farmaceutycznej, kupujący w HP spore ilości sprzętu pomiarowego.

Na wysokim szczeblu zapadła decyzja pokazania kodu źródłowego. Zawieziono audytora i przedstawiciela laboratorium do ognioodpornego archiwum i pokazano im kupkę papieru -- wydruk oprogramowania inkryminowanego urządzenia.

Na zakończenie przedstawiciel powiedział, że i tak była to akcja wyjątkowa i w praktyce nie można liczyć na dostęp do kodów źródłowych oprogramowania.

Z drugiej strony polityka Microsoftu jest bodaj taka, że po podpisaniu odpowiedniej umowy i uiszczeniu właściwej opłaty (partnerzy?) można mieć dostęp do kodów źródłowych.

Ze strony trzeciej popatrzmy na dwa urządzenia pomiarowe: jedno skomputeryzowane, a drugie klasyczne (wykorzystujące jakieś zjawisko fizyczne do oszacowania wielkości mierzonej). Sytuacja prawna (że tak powiem) obu aparatów musi być identyczna! Jeżeli oba te urządzenia służą do prowadzenia pomiarów od których coś zależy, muszą mieć odpowiedni certyfikat producenta, a użytkownik ma obowiązek kalibrowania go co najmniej trzy razy dziennie (zalecenia dla laboratoriów): na początku pracy, w środku dnia i pod koniec dnia pracy.

Wyobrażam sobie, że kalibrowanie elektronicznego alkomatu jest sprawą skomplikowaną. Stąd orzeczenie alkomatu nie jest werdyktem ostatecznym i można domagać się bardziej obiektywnego badania...

ale mnie korci.

Skala ludzkiego zaufania do zaawansowanych urządzeń jest tym większa, im większy jest brak elementarnej wiedzy z jednej strony o istnieniu dziedziny zwanej epistemologią, najbardziej życiowej dziedziny filozofii, a z drugiej strony, wręcz "agnostycznemu" rozwinięciu teorii poznania we współczesnych naukach ścisłych, w postaci choćby nieoznaczoności Heisenberga.

To przecież jasne, że zanim podejmiemy czynności poznawcze winniśmy uświadomić sobie, jakie możliwosci poznawcze posiadamy, a wybór postaw wykracza daleko poza powszechne: koń jaki jest, każdy widzi. Wystarczy zapytać, czy aby narzędzie obserwacji nie zmienia obserwowanej rzeczywistości, aby dojść do muru niepewności własnych przeświadczeń o świecie.

Mam ledwie świadmość istnienia tych kwestii, a mimo to jestem w stanie, jak mi sie wydaje, wyprowadzić pewne konsekwencje w odniesieniu do nieomylności protez, jakimi próbujemy naprawić nasze ograniczenia biologiczne.

A jak to się ma do odpowiedzialności tworcy oprogramowania? Ano tak, że wobec jednoznaczej możliwości błędu cena jest wynikiem kalkulacji ryzyk. Im mniejsza świadomość uzytkowników, tym mniejsze ryzyko producenta i wieksza łatwość odnalezienia popytu, również po stronie aparatu poszukującego skutecznych ścieżek wykonywania sprawiedliwości.

Im jednak większa świadomość, tym rozsądniejszy wybór protez i ich racjonalne używanie w zastosowaniach krytycznych, szczególnie tych dla ludzkiego życia.

Jak zwykle jestem nie precyzyjny. Ale prościej nie umiem.
____________
3,14159otR3G

Argument, że w oprogramowaniu do badania stężenia alkoholu we krwi wykryto 20 tys. błędów jest argumentem demagogicznym. Oczywiście, nie dziwię się, że wykorzystano go w sądzie.

Największym problemem podczas analizy kodu źródłowego - czym zajmuję się na codzień - jest właśnie ogromna liczba "błędów" jakimi zasypują badacza narzędzia, do tego celu stworzone. 99% tych "błędów" to błędy, które w piśmiennictwie określilibyśmy błędami indentacji czy stylistycznymi ale nie mającymi wpływu na finalny wynik programu.

Darmowe narzędzia dla średniej wielkości programu potrafią wyrzucić np. 5000 błędów pomimo, że do jego funkcjonowania nikt nie ma zarzutów. Z tego można potem ręcznie wyłuskać 2-3 błędy mające wpływ na funkcjonowanie programu.

To już lepiej dać sobie spokój z audytem i przygotować dobry scenariusz testowy (patrz Test-driven development). W ten sposób zresztą bada się poprawność działania większość urządzeń diagnostycznych - robi się to od wieków i nazywa się to kalibracją. Kalibracja termometru rtęciowego niewiele różni się od kalibracji termometru elektronicznego, tyle że zamiast wysokości słupka rtęci kalibruje się napięcie czy jakiś inny parametr elektryczny.

W pełni natomiast zgadzam się, że kod źródłowy urządzeń, od których zależy ludzki los (systemy eksperckie w sądach, e-voting itd) powinien być poddawany niezależnemu audytowi. Problem z tym postulatem polega z kolei na tym, że nie ma ludzi ani firm, którzy potrafią to zrobić dla administracji publicznej. Rynek ludzi posiadających takie kompetencje i rynek wygrywaczy przetargów to zbiory rozłączne.

Rok temu z kolegami zaśmiewaliśmy się ogłoszeniem rekrutacyjnym jednego z wiodących producentów oprogramowania dla administracji publicznej w Polsce, który w serwisie rekrutacyjnym opublikował taki anons: "firma C. poszukuje studentów ostatnich lat na stanowisko starszego analityka bezpieczeństwa kodu źródłowego". Pewnie potrzebowali do przetargu, ale ten przykład wiele mówi o tym rynku w tym kraju.

Podsumowując, bardzo proszę kolegów prawników o wielką ostrożność w formułowaniu postulatów, które będą później przekuwane na przepisy. W szczególności należy unikać pochopnych wniosków, które doprowadziły na przykład Komisję Europejską do szafowania poronionymi pomysłami na żądanie gwarancji od producentów oprogramowania.

Jeśli ktoś chciałby ten temat zgłębić, to możemy się w jakimś dogodnym terminie spotkać na telekonferencji (mam taką dla stowarzyszenia od koni kabardyńskich), gdzie postaram się opowiedzieć parę słów jak to wygląda od strony tworzenia oprogramowania.

--
Podpis elektroniczny i bezpieczeństwo IT
http://ipsec.pl/

Heh, miałem do czynienia z oprogramowaniem poduszek powietrznych.
1) klient żąda źródeł - jest to wpisane do umowy,
2) MISRA-C, OSEK itd. - wszystko to po to, żeby później w kodzie zobaczyć
#define ONE 1
Co prawda w narzędziu sprawdzającym nie generuje to błędu tak, jak
void func(int *c)
{
if(!c) return;
//do something
}
ale co tam... W końcu istotne są procedury, nie zdrowy rozsądek. "Doświadczeni" programiści - nie polscy - nie byli w stanie zrozumieć, dlaczego to pierwsze mi się nie podoba, a do drugiego nie mam zastrzeżeń.
To kod poduszki. Co się dzieje w kodzie alkomatu? Może lepiej nie wiedzieć?
Jaki wniosek z tego wyciągam? Ano taki, że firma może by się i wybroniła, ale istotne jest, kto sprawdzałby kod. Sztuczna inteligencja, czy naturalna (nie mylić z biologiczną).