Felelősnek kellene-e lennie a programozónak az általa írt programokban hagyott biztonsági hibákért?

 ( trey | 2007. január 21., vasárnap - 9:54 )
Igen.
54% (281 szavazat)
Nem.
46% (239 szavazat)
Összes szavazat: 520

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Bár én finomítanám azzal, hogy ne a programozó legyen egy személyben felelős, hanem a software gyártó cég. Ha egy autó hibás, akkor se a tervezőmérnöknek kell kifizetnie a kártérítéseket.
Egy software gyártó cégnel sokkal több lehetősége és eszköze van a tesztelésekhez és a hibák kiszűréséhez mint egy darab programozónak.

Ave, Saabi.

Illetve pontosítok: felelős, ha ő forráskódnak nemcsak
szezője, hanem tulajdonosa is! Amennyiben cégnél dolgozik
és olyan munkaszerződése van, hogy a forráskód
tulajdonjogáról lemond, akkor a felelősség a cégre hárul.

Azaz szerintem az a felelős, aki birtokolja a forrást.

(ez egy amatőr vélemény, a jogászok majd finomítanak
rajta.)

> Sol omnibus lucet.

cégen belül úgyis a programozón csapódik le, már amennyiben előveszik a céget emiatt.

Az egy dolog, hogy miként csapódik le a programozón a
hiba. Az meg a másik hogy egy 3. fél felé az esetleges
milliós nagyságrendű kártérítést ki állja. A programozót
legfeljebb kirúgják. Képzeld el, mi lenne, ha olyan
munkaszerződésed lenne, hogy a munka közben elkövetett
hibákért teljes kártérítési felelősséggel tartozol.

A cég nagy büszkén jelenteti meg a csilivili szoftvert,
kaszál belőle rendesen, míg a programozónak annyi joga
sincs (amúgy szerintem van, mégpedig elidegenithetetlen),
hogy a nevét feltüntessék a terméken. Láttál pl már olyan
windowsverziót, amelyen fel van tüntetve a stáblista?

> Sol omnibus lucet.

igen. asszem win95nél volt valami cheat hogy megjelenítette a team-et.

Valamelyik Excel-ben is volt egy ilyen 3D-s repülő akármi. Asszem 97, de lehet, hogy a 2000.

Kétféle felelősségről lehet szó:

1. Szándékosan benthagyott biztonsági hiba. Ebben az esetben akár a keresztre feszítés is szóba jöhet.

2. Menetközben felfedezett programozási hibából adódó hiba. Ebben az esetben a javítás gyorsasága és a programozó hozzáállásától tenném függővé a felelősségre vonást.

--
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!

Nehez bizonyitani, hogy egy ugyesen otthagyott "veletlen" az szandekos :)

pl.: egy egyszeru buffer tulcsordulasi hiba.....

Annyira nem: ahogy Pontcho és Gabucino is rámutatott a MOAB fél POC-nál a szándékos kód futtatásra. Kb első körben ilyenekre gondoltam.

--
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!

A 'szandekosan otthagyott biztonsagi hiba' az mar nem a nem publikalt ficsor kategoria inkabb? :-)

Remelem valaki megtalalja a linket, de van valahol a neten egy "nemes" verseny, amiben olyan kodot kellett irni, amiben van egy szandekolt hiba, ami teljesen szimpla programozoi hibanak latszik (pl. a klasszikus = vs == C-ben), es ettol a "jol" mukodo kod mellesleg csinal meg valami mast is. Olyasmi remlik, hogy pl. digitalis vizjelet rak egy feldolgozott kepfajlba. No ezt bizonyitsd, hogy szandekos, vagy veletlen.
(Az altalad felvazoltnal azert meg a jelenlegi jogi szabalyozas is sokkal jobban korulirja a dolgokat.)

/*
'=' vs '==' : egy rendes szerkesztő más színnel hozza a
'='-t és a '=='-t pont emiatt! Én ilyet használok.
*/
> Sol omnibus lucet.

hát szerintem látszódik, melyik melyik, az egyik 1, a másik 2 karakter hosszú. Előtte, utána úgyis szóköz áll, ezért észre lehet venni.

Nem az a lényeg, hogy észre kell-e venni és hogy miként
kell "szép" kódot írni, hanem az, hogy elkövetik-e ezt
a hibát a programozók vagy sem. (Én amúgy nem vagyok
ráhajlamos, pedig nem használok szóközt.) Ha el szokták
követni, akkor segítsünk nekik, hogy ne kövessék el. Pont
az ilyen apróságok tesznek komfortossá egy szerkesztőt.

> Sol omnibus lucet.

igazad van :) Csak megnéztem az emacsot, (g)vimet és az mceditet, egyik sem emelte ki.

Sorry, mindenre (n)vi -t hasznalok, az meg nem tudja. (Vagy en nem tudom, hogy tudja-e.) Es vannak ezzel masok is igy, azaz hogy nem olyan szerkesztot hasznalnak. A fenti pelda amugy osszesen egy kiragadt dolog volt, de mondhatnank azt, amit anno en csinaltam: strcmp -t es strcpy -t kevertem ossze. Volt izzadas, mire kiderult.

http://www.meditor.hu/pic/srnshot_06.jpg

Látszik hogy a '==' másként van színezve, mint a '=', ugyanígy a '++', '--' is másként van kezelve.

A biztonság a programozói hibák valószínűségének csökkentésénél kezdődik. Amúgy meg minden program SZÜKSÉGSZERŰEN tartalmaz bugot.

> Sol omnibus lucet.

Csak zárójelben jegyzem meg, a screenshoton látható kód enyhén szólva átláthatatlan számomra, több parancs egy sorban, behúzások sajátos stílusban, goto parancs :), így nem nehéz programozói hibát véteni... És ezen a színezés sem sokat segít. Mondjuk ha te átlátod a kódot, és 2 év múlva is át fogod, akkor ok :)

Hát erről sokat vitatkoztam másokkal is. Azért ennyire tömör a szerkesztés, hogy egy képernyőre több info férjen el. Mondjuk szerintem semmi átláthatatlan nincs abban,
ha egy rövid ciklus vagy egy if ág egyetlen sorban szerepel, sőt. Ha modjuk kommentezned kell sokkal könnyebb a dolgod. Összességében megszokás kérdése szerintem. Nekem így jó. De tekinthetjük egyfajta titkosításnak is (-::

Ha meg más is szokott dolgozni a kódon, akkor áteresztjük egy formázón azt kész.

> Sol omnibus lucet.

Aztán még egy csemege: memmove - memcpy! Hú de nagyon nem mindegy. Ha nem átfedő a memóriaiterület, akkor tökmindegy, hogy melyiket használod, ha igen, akkor a memmove helyesen műxik, a memcpy nem biztos. Én mindig memmove-t használok pont emiatt.

> Sol omnibus lucet.

1. Tényleg különbséget kell tenni a szándékosan benne felejtett és a véletlenül elkövetett hiba között.

2. A hiba károkozásának mértékét is figyelembe kell venni, pl.:
- eltünik a családi fotóalbum a vinyóról, ez hiba, teendő a programozó részéről: javítás
- a motorvezérlő szoftver miatt 200 km-es sebességgel egy falnak repül egy család az autójával, ez
k**va nagy hiba, a programozó(ka)t és a céget felelősségre lehet vonni a nem megfelelő tesztelés/programozás miatt

Hogy a fenébe fogod alaposan letesztelni pl egy repülőgép vezérlőszoftverét? Tetszőleges pontossággal meg tudod közelíteni a 100%-os biztonságot, de elérni soha nem fogod.

Pl a Gripen, és az F-22 prototpusai is zuhantak le szoftverhiba miatt. Pedig azokat a szoftvereket nem Pistike írta a garázsban, és valószínűleg le is tesztelték, amennyire csak letesztelhető volt.
Have a nice day :-)

En kulon valasztanam, hogy fizettel a programert vagy nem.

Ha fizettel akkor az felelos erte akitol a programot vetted: ceg, programozo, stb.

Ha nem fizettel erte mondjuk egy opensource program eseteben, akkor eleg gaz a programozon leverni az ilyen hibakat. O a szabadidelyet raaldozta es irt egy jo programot. De mondjuk nem olyan jo programozo meg, es nem tudja mire kell figyelni egy programnal, hogy biztonsagos is legyen. Kulonben is ott a kod kijavithatod te is.

Nem veletlen, hogy benne van az oszes opensource license-ben, hogy nem vallalnak felelosseget semmifele hiba miatt. Ez szukseges is, ha en irnak magamnak egy jo programot hasznalnam stb. De ha felelosseget kene vallalni az altala okozott oszes hibaert biztos nem adnam ki opensource license alatt, hanem megtartanam magamnak. Engem ne pereljenek a jotekonysagom miatt.

Egyebkent az opensourceban pontosan nem a felelossegre vonas a lenyeg, hanem tudni kell szepen kerni...

A legtöbb zártforrású programra sem kapsz garanciát. A legtöbb program készítője vállalja, hogy a média amin terjesztik nem hibás, de nem maga a program.

--
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!

Igen én is ilyesmire gondoltam.
Ha a Licence arról gondoskodik, hogy nincs abszolute semmi garancia, akkor nem kell kövezni, mert mindenki saját felelősségére használja a programot. Ha mind emellett szabad a program és a forráskódja is, akkor pedig szó sem érheti a ház elejét.
Tudomásul kell venni, hogy a programozó is ember, vagyis akár fatálisan is tévedhet.

Szerk: Erkölcsilebb felelősebbnek érzem a kereskedelmi programok készítőit. Az összehasonlítgatásnak nincs sok értelme, de az ingyen_elvihető_autó és a szalonból kihozott autó a különbség. Mindenki tudja, mit visz el, mit várhat. Kb. ilyesmi a szoftverek esete is.

Én általában olyan mentalitással találkozok, hogy a megrendelőnek minden azonnal, és lehetőleg ingyen (vagy ahhoz nagyon közeli áron) kell. Ebbe a fejlesztési modellbe nem fér bele semmiféle garanciavállalás, örüljön, hogy a pillanatok alatt olcsón összekalapált szoftver többé-kevésbé a speckóknak megfelelően működik.
Ha minőségi kódot akar akkor nagyon mélyen a zsebébe kellene nyúlnia. Ha mondjuk a mai fizetésem 10-30X-osát kapnám, akkor még talán vállalnék is valamilyen - limitált - felelősséget.
Ha meg biztonságos szoftvert szeretne, akkor meg nem lehet megkerülni a külső auditáló cégek bevonását, akik meg szintén nem 2 fillérért dolgoznak.

Tehát a válasz egyértelműen nem, hacsak nem ennek megfelelően fizet az ügyfél.

errol van szo.

Erdekes, hogy kepzelik egyesek ezt a felelosseg kerdest akar egyen akar ceg szinten.

Ha egy programert felelosseget kell vallalni (pl. mi van, ha egy ceg megveszi a progidat, ami valami konfiguracios kulonbseg miatt letorol egy fontos dokumentumot, amin a ceg tobb honapig dolgozott..), akkor a programok arat azonnal meg lehet szorozni kb 100-zal (talan ennyiert lehet formalisan ellenorzott, hasonlo tudasu programot irni..)

Azt kellene eszrevenni, hogy jelenleg nem megoldott az ilyen biztonsagu programok irasa, es nem lustasagbol nem alkalmazzak a cegek.

Idézet:
"örüljön, hogy a pillanatok alatt olcsón összekalapált szoftver többé-kevésbé a speckóknak megfelelően működik"

Igy van, raadasul nem is biztos hogy letezik specko. Vagy ha letezik, akkor a megrendelo elolvasta es megertette.

De azert csak a gondolatmenet kedveert, tegyuk fel, hogy bevezetik ezt a felelosseg kerdest. Mi tortenhet ekkor?

1. A programok ara azonnal szorzodik mondjuk 2-3-al. Egy winxp home OEM mondjuk 50e ft. Jobb lesz ezek utan a winxp, jobban fog figyelni az M$? A nagy fenet. Az extra bevetel megy a jogaszokhoz, akik az esetlegesen perelo ugyfeleket majd jol megszopatjak.

2. A programok ara mondjuk 100-al szorzodik es az esetleges hibas mukodes eseten tenyleg kifizetik az okozott kart.

3. A programot csak dedikalt kornyezetben engedik futtatni. Pl veszel egy winXP-t, akkor a hardvert es minden egyeb szoftvert is az MS-tol kell venni, kulonben nem garantalhato a hibamentes mukodes. Ez szinten jot tenne a HW es SW araknak.

Akkor kerdezem, melyik lehetoseg a 3 kozul ami annyira kivanatos?

Akinek ma biztonsagos kod kell, az meg tudja vasarolni. Akinek nem kell, az tud venni nem biztonsagosat. Akkor mivel van a problema?

Hat, ha te rendelsz egy hazat, amit a valalkozo felepit neked, es utana radomlik, akkor az nem analog azzal az esettel, hogy veszel egy tuzfalat, ami szar, es ennek koszonhetoen mondjuk a diplomamunkadat bukod?
Elmeletileg nem csinalhat senki olyan hazat, ami raddolhet.
---
http://betegmedikus.blogspot.com
seredi@gmail.com

Gyakorlatilag meg nem fizetik meg a szoftvert mer' úgyis lehet letőteni ingyen.

Nem teljesen analóg, mert házat nem szoktak sokszor szándékosan ráddönteni, de szoftvert (pl. tűzfalat) nem kevés esetben támadnak szándékosan. A tűzfalban nagyobb a rizikó.

--
trey @ gépház

"nem csinalhat senki olyan hazat"

- Ha a tervező kellően méretezi (ráhagyások, stb.)
- Ha megfelelő a környezet (nem utólag derül ki, hogy a föld ilyen meg olyan)
- Ha nem minimálbéres román munkaerővel dolgoztatsz, illetve ha legalább magyarul tudnának (ismerősöm építőmérnök, kiment egy építkezésre, fél órát magyarázta a tervrajzot, hogy mit b@sztak el, és utána esett le, hogy a csávó baromira nem beszélt magyarul. Sőt, más sem.)
- Ha nem ótvar alapanyagokból dolgoznak
- Ha nem a mindegycsakgyorsanésolcsónlegyen szemlélet uralkodik
- Ha az ellenőrzés folyamatos és az ellenőröket nem lehet megvesztegetni

Persze kártérítést is kérhetsz, amennyiben nem szűnik meg a cég jogutód nélkül, akivel építtetsz..

Ugye, hogy nem is olyan egyszerű...

A szavazást inspiráló cikk itt.

--
trey @ gépház

Kisherceg után, szerintem mindenki felelős azért a rózsáért, amit megszelídít :))

Mulder

ui: szerintem ez nagyon komplett kérdés. Ha az ügyfél szolgáltatásért fizet, akkor vállalható a garacia. Ha nem, akkor elvárható, hogy a szoftver ne tartalmazzon hibákat, de egy ilyen hiba kiderülése esetén plusz költség nélkül javítania kell a szoftber előállítójának a hibát... szerintem.

Ez a kérdés sajnos nem egyértelmű igen/nem-mel dönthető el, igennel szavasztam, de azóta 5x átértékeltem a dolgot. Akié a kód azé a felelősség, amennyiben erre bármilyen szerződés kötelezi a tulajdonost.

Ki-é a kód? De az legtöbb esteben nem a programozó-é! A minőségellenőrzés, felelősség...???? Mi van ha külső-, rendszer-libeket használ és az rossz....

Szerintem a kodtulajnak kevesebb koze van a kodhoz, mint a programozonak.
Nagyanyam mondta mindig, hogy ha csinalsz valamit, akkor azt csinald jol.
---
http://betegmedikus.blogspot.com
seredi@gmail.com

A foglalkozas koreben valo hibazast a torvenyek szabalyozzak. Vannak olyan hibak, amiket a torveny szankcional, vannak, amiket nem. Ez termeszetes, hiszen nem lehet az egyen korlatlanul felelos, mert:

* van egy adott muszaki/tudomanyos szint, ami egy adott kort jellemez, es ebben eleve lehetnek teves elgondolasok, hibas megkozelitesek, vagy hianyossagok (ez alatt nem az egyen esetlegesen teves tudasa vagy gondolatmenete ertendo, hanem a tudomany mindenkori allasa)
* van egy un. elvarhato gondossag (nem vagyok jogasz, de ez valahol a hanyagsag ellentetekent jelenik meg, nemi ertelmezesi szabadsagot hatrahagyva, tehat a torveny szandeka elsosoraban a kifejezetten hanyag magatartas szankcionalasa, es nem az, hogy pl. 12 ora munka utan vki tevedett)
* a korlatlan felelosseg gyakorlatilag megbenitana a termelest

Ezen kivul nem veletlenul vannak komoly eloirasok, nemzetkozi szabvanyok olyan muszaki feladatokra, amiknek a nem megfelelo elvegzese (pl. hibas tervezes, vagy kivitelezes okan bekovetkezo meghibasodas) jelentos kart okozhat embereletban, kornyezetben, vagy anyagiakban.

De itt is korlatozott felelosseg jut az egyennek, hiszen a szabvany betartasa, illetve a szabvany betartasanak ellenoriztetese minosito szervezettel (pl. TUV) gyakorlatilag leveszi az egyen vallarol a kozvetlen felelosseget. Raadasul cegek (szervezetek) eseteben a vezeto viseli felelosseget, es nem a munkat kozvetlenul elvegzo mernok.

Ezek a szabvanyoknak pedig az alapgondolata ket tenyezobol taplalkozik:
* nincs tokeletes (100%-os) biztonsag (semmilyen ertelemben), csak megfeleloen alacsony kockazat
* az emebreknek van egy kockazatvallasi szintje (mennyi esellyel halhatok meg, vagy mennyi esellyel bukok ennyi vagy annyi penzt, stb.), illetve az allamoknak van egy gazdasagilag racionalis kockazatvallalasi celkituzese (mennyi allampolgarom halhat meg evente, mennyi gazdasagi veszteseget szenvedhetnek el, hogy ne rojon ram kulonosebb terhet)

Ezert szerintem a fenti kerdes nem jol van megfogalmazva. En ugy tennem fel a kerdest, hogy allapitsunk-e meg torvenyi kartereitesi kotelezettseget a programhibak altal okozott vesztesegek okan. Ugyanis ennek egyenes kovetkezmenye, hogy letre fognak jonni minosigbiztositasi szabvanyok, illetve a mar meglevok kotelezo ervenyuek leszenk bizonyos esetekeben. Ennek az lesz az eredmenye, hogy sokkal biztosnsagosabb szoftverek leszenk, de sokkal dragabban. Ugyanakkor a nyilt forrast meg is lehet ezzel buktatni, hiszen egy nyilt forrasu projekt certifikaciojara valoszinuleg nem lesz penz.

Tehat velemeynem szerint a programozot kozvetlenul nem lehet felelosse tenni egy hibaert, kiveve, ha nem a tole elvarhato gondossaggal jart el.

Ennyi naív hozzászólás után jó látni egy racionálisat is.

--
Aries
http://aries.mindworks.hu
http://mindworks.hu/blog/aries

Ha nem szándékos a hiba, akkor az a felelős, aki a véletlenül bennehagyott hibát ártó szándékkal kihasználja.

Felelősnek kellene-e lennie a QA csapatnak az általuk nem észrevett biztonsági hibákért?

Hali,

Pontosan, ez a kerdes is felmerul. A managerek kijelolnek egy idopontot, vannak hataridok, aztan van valamennyi QA idoszak. Aztan megy a cucc elesbe, ami nem derult ki addig, az kinek a felelossege? Nem a programozokon kene ezt elverni.

Amugy meg el lehet olvasni a warranty-t meg ezeket a legal szovegeket a programokhoz, aztan mindenki olyat hasznalhat, amilyet akar. Ha valaki annyira emberkedni akar, hogy namarmost o bepereli az egesz tarsasagot mert a program egy sz*r, akkor legyen szives nyuljon a zsebebe, hogy meg tudja vasarolni azt a programot, aminek a licensz szerzodese lehetoseget ad erre.

Talán nem csak azt kellene megvitatni, hogy a programozó felelős -e az általa írt programokban hagyott biztonsági hibákért, hanem azt is, hogy felelősségre vonható -e ezekért. Vagy csak én érzem különbözőnek a két kérdést?

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

Fuu, ez egy tok jo gondolat; szerintem en felre is ertettem az eredeti kerdest, es felelossegre vonhatonak ertelmeztem. Hat fura dolog ez, vegulis mindenki felelos a tetteiert, nemdebar? :)

Bevallom én az igenre szavaztam, meg is mondom miért:
Még bohó Windows only koromban volt egy kedves kis lejátszóm, amit BSplayer-nek hívtak (miért nem ismertem én már akkor is az Mplayer-t ).. Használtam én minden jóra, mi csak kitelt tőle, felirat és hangsáv váltásra / csúsztatásra, ám egyszer egy nap különös viselkedést mutatott a drágája: Amikor egy film lejátszása véget ért, vagy akár közben is megszakította azt valaki/valami a program csak error message-el tudott kilépni, majd csodálatomra azt a file-t amit épp lejátszásra megnyitottam vele törölte annak rendje és módja szerint (furfangos volt, mert véletlenül se a lomtárba dobta ).. Na akkoriban pár "b* meg"-et úgy tényleg jól esett kimondani teljes őszinteséggel.
Bár igaz ez a fajta hiba nem kifejezetten security eredetű ( csak mint utólag kiderült nekem pont eg olyan verziót siekrült letöltenem és tárolnom, amit rá 2 nappal javítottak, csak én meg lusta voltam leszedni a legfrisebbet ) még is hasonló problémákat okozott ( ugyebár security problémákból eredően destruktív is tud lenni bárki/bármi ).
Bár ezek után ( és akkor is) csak kb annyi a véleményem, hogy amennyiben az adott programozó/cég mindent megtett akkor, hogy a programban lévő hibákat elhárítsa még a végleges kiadás elött, ámde a kiadás után még is valami nagy rést találtak benne, akkor annyi felelősséggel tartozik, hogy azt a hibát minél elöbb ( max 2 nap!) kijavítsa és ismét egy olyan programot tegyen elérhetővé, amelyben nincsenek ismert lyukak (ezért is szeretem az M$ féle havonta 1x frissítünk módszert..)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

Ez szép, csak akkor mi a helyzet, ha a cég nem akarja megcsinálni? akkor jogilag felelőséggrevonható? Ha van szerződés, hogy x ideig szupportolja, ha nincs akkor TSÁ!

Mivel akkoriban még nem volot fizetős ez a program, így így is úgy is buktam ezt ( igaz létezett fizetős verziója is ).. De ha nem javították volna a hibát akkor a minimum az, hogy neten közzéteszem a talált bug-ot és rendesen lerontom a BsPLayer használók nem kicsiny táborát.. Azt meg döntsd el, hogy szted ez jó e a programozóknak, ha egy ilyen baromság miatt buknak egy csomó pénzt ( mondjuk kiesett reklám miatt )..

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

A BSplayer készítői valószínűleg nem egy menüvezérelt delete parancsot akartak megvalósítani, szerintem a hiba miatt felelőségre vonni őket nem korrekt. Anyázni és hibajelentéssel zaklatni őket viszont teljesen normális. Felelősségre vonást akkor tudnék elképzelni, ha a BSplyert használatából eredendően maradandó
károsodást szenvedsz (testileg).

Engem ez szemely szerint is erint, mert egy kozelebbrol meg nem nevezett open source program fejlesztoje es jogtulajdonosa is vagyok egyben. Ezzel egyutt mondom azt, hogy igen, a program keszitoje/jogtulajdonosa/stb. legyen felelos a program hibaja miatti kar eseten.

Nezzuk meg, hogy pl. egy kenyerpirito eseten mi a helyzet. A garancia levelen vagy a manualban le van irva az un. rendeltetesszeru hasznalat, es csak ennek betartasa mellett ervenyes a garancia. Ennek szoftverek eseten is igy kell lennie. Mert az finoman szolva nem koser, hogy pl. a cisco ios eseten (hallomas alapjan irom, nem jartam utana) meg arra sem vallalnak garanciat, hogy elindul az ios. Pedig nem 2 fillerbe kerul.

Egy okos irasban azt olvastam, hogy open source eseten az a bolcs magatartas, ha a karteritest/felelossegvallalas csak azoknak jar(hat), akiknek ervenyes - penzbe kerulo - support szerzodesuk van. Akinek ilyen nincs, az ne reklamaljon sok M HUF-ot kovetelve, ilyen esetben max. kisirhatja magat a vallamon.

A licence meg egy erdekes dolog. Az en programom zlib/png licence alatt lett kiadva, ami kb. annyit tesz, hogy azt muvelsz a programmal, amit akarsz, (logikai) es semmi garanciat nem nyujtok arra nezve, hogy nem okoz a program hibat, nem eszi meg eloled a szendvicsedet, stb.

Egy spamszuronel meg kulon erdekes ez a hibazas dolog, mert egy szuro termeszetenel fogva nem lehet tokeletes. Azaz - ha lenne garancia hozza - belefoglalnam, hogy a program <100% pontossaggal dolgozik. Az meg tovabb bonyolitja a kepet, hogy a program kulso lib-eket is hasznal. Mi van, ha a felhasznalo egy olyan verzioju lib-et telepeit, amiben megvaltozott az API, es a program siman elhasal minden levelnel? Ez mennyiben az en hibam? Ha pl. van benne egy buffer overflow, de azt kijavitom, az mennyiben csokkenti a karteritest? Ha a felhasznalo nem frissit idoben, az kinek a hibaja? Aztan a garanciaba azt is belefoglalnam, hogy x, y es z hibakra vallalok karteritest, a tobbire meg nem - mert "az ellen nem ved". Ja, az meg egy szinten nem elhanyagolhato kerdes, hogyan bizonyítja a felhasznalo, hogy a program hibazott.

Szoval az ilyen es ehhez hasonlo kerdesekre is valaszt kell adni, mielott a programozokat ki akarnak nyirni a T. felhasznalok. Gondolom, ido kerdese, hogy ezekre valami szabvanyszeru ajanlas kialakuljon. De nem akarok kibujni a felesosseg alol, es meggyozodesem, hogy mindenkinek felelosseget kell vallalnia az o hibajabol bekovetkezo karokert. En azt mondanam 1. korben, hogy amennyit a felhasznalotol kapok penzt, legfeljebb akkora osszegig vallalok garanciat.

ASK Me No Questions, I'll Tell You No Lies

Idézet:
Ezzel egyutt mondom azt, hogy igen, a program keszitoje/jogtulajdonosa/stb. legyen felelos a program hibaja miatti kar eseten.
...
Az en programom zlib/png licence alatt lett kiadva, ami kb. annyit tesz, hogy azt muvelsz a programmal, amit akarsz, (logikai) es semmi garanciat nem nyujtok arra nezve, hogy nem okoz a program hibat, nem eszi meg eloled a szendvicsedet, stb.

Én itt érzek egy hangyányi ellentmondást.

ezek felett talan elsiklottal:

- max. akkora osszegig vallalok felelosseget, amennyi penzt fizettel erte (en eddig 0.00 HUF penzt kerestem vele)
- ha nincs fizetett support szerzodes, akkor nem akarom azt hallani, hogy hany M HUF kart okozott a program

ASK Me No Questions, I'll Tell You No Lies

Ha kritikus helyen (atomerőmű, repülésirányítás) használnak egy szoftvert, ott komolyabban kell venni a garanciát, nem perek meg kártérítés miatt, hanem hogy amennyire lehetséges, hibamentes legyen a cucc.
Ehhez persze meg kell fizetni a fejlesztőt annyira, hogy úgy érezze, megéri háromszor annyi időt fordítania egy-egy funkcióra. Ehhez persze több idő szükségeltetik, hacsak nem tapasztalt fejlesztőről van szó, aki tudja hogy milyen a hatékony hibakeresés.
Jópár űrszonda, rakéta viselkedett hibásan, szoftverhiba esetén. Nem lennék ilyenkor a fejlesztő helyében, nem az esetleges kártérítés meg álláselvesztés miatt, hanem mert rossz érzés hogy a saját hibám miatt megy tönkre egy projekt.
Felelőssé kell-e tenni egy fejlesztőt? Igen, mint ahogyan szemrebbenés nélkül letartóztatják egy épület tervezőjét ha az tervezési hiba miatt összedől. Csak valahogy nem akarják a szoftverek fejlesztőit annyira megfizetni mint az építészeket. Megrendelőim mindig azt hiszik hogy egy fejlesztés már meglévő elemekből sitty-sutty elkészül. Hát a lóf*ßt. Minden rendszernél újra kell definiálni az elvárásokat, a támadási felületet, a mozgó adatokat, funkciókat újraírni, illeszteni. A virtuális építményekért nem akarják megadni azt az árat amennyibe a felelősség és munka kerül. Ennek tükrében, nem csoda ha nincs garancia, és így persze ne lehessen felelősségre vonni egy fejlesztőt, vagy pedig fizessenek a supportért.

Kritikus helyen, pl egy repülőgép vezérlőszoftverénél komolyan is veszik ezeket a dolgokat. Ott pl. azt csinálják, hogy 3 db különböző számítógép működik, amiken más-más team-ek által írt szoftver csinálja ugyanazt. Normális esetben mindháromnak ugyanarra a bemenetre ugyanazt a kimenetet kell produkálnia, ha valamelyik ettől eltér, azt az egységet hibásnak jelöli meg a rendszer.
Tehát ebben az esetben többszörös túlbiztosítással lehet növelni a biztonságot. Egy ilyen komplett rendszer költségei viszont az nyilvánvalóan az egekbe szöknek. Van ahol még így is megéri, és van ahol nem.

azért a kritikus helyen nem egyszerűen megírják a szoftvert, hanem mellette helyességbizonyítás is van, vagyis matematikai módszerekkel is ellenőrzik. Jó, nyilván mindent nem tudhat a bizonyító eszköz, de valamilyen szinten mégis meg lehet bizonyosodi arról már a kód készítésekor, hogy hibátlan a kód (!!). Erre példa a SPARK rendszer...

A fizetés meg tényleg szánalmasan alacsony szokott lenni. Dolgoztam rendszergazdaként, csak nem tetszett a bérezés (az okokat hagyjuk), és az volt rá a reakció, hogy máshol olyan 220 ezer körüli összeg egy nagyon jó fizetés (teljes munkaidőben) + hajnali 3kor is kereshetnek telefonon + szabadság is olyan, hogy bármikor visszazavarhatnak dolgozni. Hát nc. Ilyenek sztem erősen befolyásolják a munka minőségét - negatív irányban.

A helyességbizonytás jó, de mi van, ha elrontották el a specifikációt?

KisKresz

természetesen az is előfordulhat. Ez azonban nem jelenti azt, hogy maga a program is hibás lesz, hiszen ha a kód helyessége nem látható be, akkor az csupán annyit mutat, hogy a specifikációnak nem felel meg. Lehet, pontosítani kell a specifikációt, vagy átírni úgy, hogy a bizonyítást végző eszköz már be tudja látni. Sokszor előfordul, hogy a kód túl bonyolult, csak egy egyszerűbb megvalósítás helyessége látható be az adott eszközzel, az általánosabb változat nem. Tipikusan ilyen terület a sablonok használata és a párhuzamosság. Sőt, ha már itt tartunk, akkor nem feltétlenül önállóan dolgozik az adott program, mert lehet, hogy vannak olyan állítások, amelyet ő maga már nem tud belátni, ezért inkább a felhasználóra bízza az állítás belátását. A kézzel bebizonyítandó állítás nem az eredeti, hanem abból levezetett, egyszerűsített állítás, amelynek helyessége kellene ahhoz, hogy bebizonyítsa az eredetit. Tehát vannak olyan eszközök, amelyek interaktívak, vannak, amelyek nem.

> A fizetés meg tényleg szánalmasan alacsony szokott lenni.
> Dolgoztam rendszergazdaként, csak nem tetszett a bérezés (az
> okokat hagyjuk), és az volt rá a reakció, hogy máshol olyan
> 220 ezer körüli összeg egy nagyon jó fizetés (teljes
> munkaidőben) + hajnali 3kor is kereshetnek telefonon +
> szabadság is olyan, hogy bármikor visszazavarhatnak
> dolgozni. Hát nc. Ilyenek sztem erősen befolyásolják a munka
> minőségét - negatív irányban.

Es ha ennek a haromszorosat kapod, akkor ilyen korulmenyek kozott hatekonyabban/jobban/megbizhatobban dolgozol?

k.

ez egy kicsit összetettebb kérdés :) Bizonyos keretek között a több pénzt motiváció is egyben. De mint tudjuk, a pénz nem boldogít, sőt, minél jobban növelik a fizetést, annál kevésbé növeli a motivációt az azonos növelés. Továbbá elengedhetetlen, hogy a munkavállaló meg is legyen becsülve.

De itt mar messze nem a motivaciorao van szo ...
Nem lehet valakit arra "motivalni", hogy 24/7-ben felelossegteljesen keszenletben alljon, mert az ember faradt, meg neha a csalad is sir "apuciert", es azzal, hogy veszel a tobb fizudbol nekik narancsot, nem biztos, hogy boldogabbak lesznek ... (meg te sem ...)
Kb ugyanaz a helyzet, mint az orvoseknal, azzal a kulonbseggel, hogy ott egy cseppet jobban tervezheto a dolog (?), mert ho elejen egy papirra kiirjak, ki mikor ugyeletes, es a szabira is lehet licitalni ... (gondolom en).
De a leirt pelda - akarmannyire is altalanos, ha az - mar a "17 tonna" cimu dalolmanyra hasonlit ... mikor mar a lelked sem a tied ...

Erre kerdeztem ra ...
k.

Érdemes egy másik oldalról is megrágni a ugyanazt a csontot. Az elv az egy dolog, hogy mondjuk valamit csinálunk és akkor felelősek vagyunk érte, hogy azt jól csináljuk. Viszont mint személy van egy pénzügyi korlát, ami felett értelmetlen a felelőségre vonás, mert nem személy léptékű a dolog, holott a személy fog hibázni. Mondok példát.
Mondjuk a NASA csinál egy űrhajót X csillió dollárból. Valaki hibázik. Füstbe megy. Le lehet verni rajta? Lehetetlen. Valaki vezet egy vadászgépet, elszúrja, katapult, boom. Lesz rá esély hogy behajtsák rajta? Esélytelen.
Csinálok egy mailservert, megtörik, ipari kémkedés, hatalmas kár. Erkölcsileg enyém a felelőség, gyakorlatilag? Nem hiszem.

Szerintem...
A programozó mindig felelőséggel tartozik a kódjáért, de csak akkor vonható felelőségre, ha biztosítottak számára a feltételek ahhoz, hogy minőségi kódot állítson elő, de csak is az ő kódja által okozott károkért. Értem itt a feltételeken a megfelelő anyagi támogatást, a kellő időt a program tervezésre és a megfelelő fejlesztési modell alkalmazására, a kellő technikai és szoftveres háttért a tesztelésre, etc.

Az a baj, hogy sokan gyorsan akarnak programokat kézbe kapni és elfelejtkeznek, hogy egy program megtervezése legalább olyan bonyolult, mint a technikai eszközök megtervezése, így gyorsan kevés pénzből ne várjanak minőségi terméket. Ha nincs meg a megfelelő háttér a munkához, akkor ne várjanak el olyan munkát amiért vállalom a felelőségre vonást. Vagy, ha elvárják, akkor fizessék meg nekem azt, hogy olyan feltételekkel tudjak dolgozni, amivel tudok garanciát vállalni.

1. Másik, hogy a programozók többségének a hírnév, az elismerés fontos, és mint ilyet csak úgy tudják elérni, hogy a lehetőségekhez képest a legjobb munkát végzik. Oda figyelnek arra, hogy minél kevesebb hibával és biztonsági réssel dolgozzanak. Nekik se érdekük a biztonsági lyukak és bugok garmadája, de sokszor bele kényszerülnek abba, hogy nem megfelelően ellenőrzött kódot adjanak ki a kezükből.

2. Másik, kit terhel a felelősség akkor, ha egy csoport által készített programban olyan hiba van, hogy a benne lévő két modul mindegyike megfelelően működik, de nem megfelelően működnek együtt, és az ebből adódóan elvész mondjuk egy fontos állomány?

Az Erő Legyen Veled!

Idézet:
2. Másik, kit terhel a felelősség akkor, ha egy csoport által készített programban olyan hiba van, hogy a benne lévő két modul mindegyike megfelelően működik, de nem megfelelően működnek együtt, és az ebből adódóan elvész mondjuk egy fontos állomány?

Ó, nem csak állomány veszett már el így. Gondolom mindenki emlékszik a Mars Climate Orbiter-re :-)

Ezt csak azért kérdeztem meg, mert klasszikus értelemben véve hibát nem vétet egyik programozó se, de nyilván program tervezési hibát vétettek, azok, akik ezt a specifikációt átadták nekik, hogy programozd le. Vagy egyszerűen nem volt megfelelően tesztelve, akkor is hibát vétettek. Így ebben az esetben felelősségre lehet vonni vagy a tervezésben résztvevőket, a tesztelőket is.
Azért előferdülhet az is, hogy nem volt elegendő idejük a tesztelésre, vagy nem állt rendelkezésükre az a közeg, ahol ez a hiba előkerült. Etc. Így akkor már nem vonhatók felelőségre, ha nem álltak rendelkezésre önhibájukon kívül a megfelelő feltételek. Szerintem. :)

Az Erő Legyen Veled!

A tesztelőkhöz: 100% lefedő tesztet ésszerű időn belül NEM lehet csinálni. Funkciókat meg lehet nézni, lehet próbálgatni, de a lehetőségek száma olyan nagy, hogy fizikailag lehetetlen teljes, vagy akár csak közel teljes tesztelést csinálni. A tesztelők nem is biztos, hogy minden hibát megtalálnak, a customertől is rengeteg hibabejelentés érkezik, mert ők használják az adott sw-t production környezetben. Ezt úgy szokták megoldani, hogy először egy teszt rendszeren futtatják az új software-t, és csak utána vezetik be, ha a customer ugynevezett acceptance tesztjeinek is megfelelt... Szoftvertermék esetén gyártó és vevő közötti együttműködésről van szó (kellene hogy szó legyen)...

Nyilván nem lehet az esetek többségében 100%-kos tesztet összehozni. (Minnél bonyolultabb egy program annál nehezebb megfelelően tesztelni) Itt arra akartam helyezni a hangsúlyt, hogy azért elégé nehéz bárkit is felelőségre vonni sokszor.

Az Erő Legyen Veled!

Ott a masik foldreszen vannak olyan foglalkozasok (oktatjak), amit mernokoknek neveznek, project-mmanagement-et vegeznek, de legalabb 2-3 kulonallo mernoki diplomajuknak kell lenniuk ( ezen speckos - nemjuteszembeaneve - mernokdiploman kivul). Ezek az emberkek a feje egy teamnek - rendszermernokok, ilyen-olyan professional-ok - akik az eccerutechnikus-programozo-rajzolo-izemize mernokurakat baszogatjak ... Es naluk a felelosseg ...

OK, en specialisan tudomanyos projectrol (megspecialisabban a Hubble-rol) beszelek, de valahogy igy lehetne jol/hatekonyan/nagy hibaturessel dolgozni ...

k.

Tudom, hogy ok is buggal kezdtek ...

nem hinném, de nézőpont kérdése. az oss világban, ha megnézzük, mind a bsd licenszben, mind a gpl-ben ott virít, hogy nincs garancia arra, hogy a program tényleg azt fogja-e csinálni, amit kéne. a Windows(C) biztonsági hibáiért sem lehet kártérítést követelni, vagy igen?

ettől függetlenül (1-2 embernek) nem így kéne megtanulnia programozni, "nyilvánosan" :) magyarán, ha ő is tudja, hogy nagyjából sz*r, amit csinál, akkor ne osztogassa minden arra menőnek :))

Pont az a jó a nyilvánosságban, ha aktív, hogy ha hibát talál valaki, kijavíthatja.

igen, csak ezt egy user nem fogja látni a kódban, ő csak használni fogja

És erről a fejlesztő tehet?

"magyarán, ha ő is tudja, hogy nagyjából sz*r, amit csinál, akkor ne osztogassa minden arra menőnek :))"

Pont az a jó a nyílt fejlesztésben, ha valaki talál hibát, kijavíthatja.

Vagy írhat rá exploitot, és azt árulja :-)

És erről a fejlesztő tehet?

jaj, végtelen ciklus, mi is bénák vagyunk :))

Hopsz egy hiba. Kösz a bugreportot! :)

=))

már elmondták előttem a lényeget: nem tanácsos felelősségvállalást kérni a programokért.

Különböztessük meg élesen a közvetlen és a közvetett felelősséget. Pl közvetett: ha leszakad a táskám füle, a táskagyártót európában nagyjából csak a táska árának megfelelő kárért perelhetem, míg amerikában a táska füle miatt elmaradt 1 milliárd dolláros üzletkötésemért is.

Közvetlen felelősséget (európai út) meg lehetne követelni: vagyis hogy alapvetően arra alkalmas a program, amire hirdetik. Ez azonban sokkal gondosabb fejlesztési, tesztelési metodikát igényelne, kb 10-szeresére növelné a költségeket.

Közvetett felelősség (amerikai út) megkövetelésével bármely cég valószínűleg csak matematikai bizonyítás elvégzése után vállalna felelősséget. Ez előrelökné a világot a deklaratív, bizonyítható viselkedésű nyelvek felé, és a költségeket legalább 1000-szeresére növelné meg.
Igaz, cserébe valószínűleg sokkal biztonságosabb programok lennének, amelyek sokkal lassabban futnának, sokkal kevesebbet tudnának.
Velük szemben jönne létre a "fekete" programok piaca (mint a fekete gyógyszerpiac), ahol nem ellenőrzött, ámde több nagyságrenddel gyorsabb és feature gazdagabb, bugos programok élnének illegalitásban, hatóságok által üldözve.

Talán tényleg jó lenne a javulás, de ne felejtsük el, hogy a világban egyszerűen nincs annyi jó programozó, amennyi jó programra szükség lenne. Tehát egy darabig még gyorsan kell dolgozni, tökéletlenül, hogy valamilyen program kijöjjön a határidőre. Aztán úgyis jön a mesterséges intelligencia, és a programozóknak befellegzett.

Idézet:
Igaz, cserébe valószínűleg sokkal biztonságosabb programok lennének, amelyek sokkal lassabban futnának, sokkal kevesebbet tudnának.

Olvass utána egy kicsit :) Van statikus és van dinamikus helyességbizonyítás. Az egyiknél fordítási időben ellenőrzi a dolgokat a program, a másiknál meg futási időben, ami nyilvánvalóan lassítja, ámde nem sokkal. Ma is szokás egy tesztelés alatt álló szoftverbe assert()-eket rakni, ámde az sem sokkal fogja vissza...

Arra kíváncsi vagyok, hogy egy repülőgép irányítását végző bizonyítottan helyes kód hogy lehet lassú, és hogyan lehet olyan programot írni rá, aminek nagyobb a funkcionalitása. Az utóbbi gondolom olyan lenne, hogy nem csak a hajtóművet vezérelné, hanem még kávét is főzne, nem? :(

"Ma is szokás egy tesztelés alatt álló szoftverbe assert()-eket rakni, ámde az sem sokkal fogja vissza..."

én numerikus algoritmusok, képfeldolgozás területen dolgozom.
ott még 2 kódsor felcserélése, esetleg 1 sor assembly betéttel helyettesítése tud hozni 100%-os gyorsulást.
Debug és release mód között is kb 3-szoros (!) gyosulás van. Nem benchmark: éles alkalmazás.

Egyébként a "sokkal lassabban futnának" kitételnél arra gondoltam, hogy más eszközöket, futtatási környezetet, VM-et használnának a jövő alkalmazásai, ahol nem a sebesség, hanem a korrekt működés lenne az elsődleges prioritás.

Sztem nem a programozot kell kozvetlenul egy felhasznalonak felelossegre vonni. Legeloszor is szerintem az az elso kerdes, hogy fizetos, vagy ingyenes termekrol van szo. En ugy velem, hogy az ingyenes szoftverekkel kapcsolatosan elnezobbnek kell lennem, hiszem en megiscsak mindenfele ellenszolgaltatas nelkul hasznalom azt a programot amit a fejlesztok a sajat idejukbol keszitettek. Valamint, ha bizonyos foku elvarasom van, ami a felelosseget illeti a fizetos szoftverek iranyaba veszem az utam, hiszen ott a penzemert cserebe adnak egy szerzodest, amelyben alt. felelosseget vallalnak azokert a problemakert, amelyeket az o szoftveruk hoz letre. Ha a fizetos szoftvernel valami hiba folytan problemam lesz, a szoftvert kiado ceg a felelos szvsz. A ceg alkalmaz olyan embereket akik letrehozzak a szoftvert, igy en csak a cegnek elhetek panasszal. A ceg a hibas, hogy olyan embert vett fel, aki nem tud annyira programozni, a projektvezeto a felelos azert, hogy a hibat nem vettek eszre, es nem javitottak. Persze mindenki szerintem probal minnel hibatlanabb kodot letrehozni, de sajnos ez szinte kivitelezhetetlen. Emiatt gondolom ugy, hogy nem azt az egy szem embert szabad csak hibaztatni, hanem a teszteloket, a menedzsereket, meg a ceget akik vallaltak, hogy olyan programot adnak nekem a kezembe, amelytol elvarhatok jo nehany dolgot.

Kicsit hasonló lehet az orvosi műhibák problémája. Ha egy páciens maradandóan megsérül, esetleg elhalálozik a beavatkozás során, akkor az orvosokat/kórházat is elő szokták venni. De ez nem busszóállás, hanem inkább kártérítés. Ha az orvos saját létbiztonsága is benne van a játékban, akkor (az értelmesebbje legalábbis) nagyobb felelősséggel fogja végezni a munkáját. Annyiban is hasonlít a két eset, hogy mind programhibák, mind műhibák mindig is lesznek, bármekkora felelősséget is vállalnak az egyes felek.

Viszont, ellenben az orvosokkal, a programozók nem mindig vannak úgy megfizetve, hogy bármilyen anyagi felelősséget tudjanak vállalni. Ráadásul a bérezés nem is egyenesen arányos a szoftver környezetének kockázatosságával. Egy agysebészt rendesen megfizetnek azért, hogy felelősségteljesen nyújtsa a magas szintű teljesítményét, de gondolom hogy az autógyárak 10. alvállalkozójának programozói nem akasztanak le ahhoz fogható pénzt. Márpedig az anyagi megbecsülés és az embert terhelő felelősség igenis együtt jár.

"Viszont, ellenben az orvosokkal, a programozók nem mindig vannak úgy megfizetve, hogy bármilyen anyagi felelősséget tudjanak vállalni"

Te hol élsz?

Pl. Magyarországon tudod te, hogy mennyit keresnek az orvosok? Ha tudnád, akkor biztos nem irnál ilyet. És már kezd ide is eljutni, hogy perel a páciens, mert nem elég jól tájékoztatta előre a doki, és nagyobb fájdalmai vannak mint amire számitott, vagy az előzetesen várható 2 hét helyett 4-ig tart a lábadozás, stb, és nem csak az agyműtéteknél ...

Megsúgom, hogy én pl. önképzett programozóként (alkalmazott vagyok, éppen hogy már nem kezdő), majdnem dupláját keresem mint az orvos faterom aki már végigtanulta+gürizte+ügyelte az egész életét.

Nehogy már szegény programozókat kelljen sajnálni a lové miatt az orvosokkal szemben...

Szvsz a lehető legrosszabb példát hoztad fel, főleg most, hogy épp teljesen esik szét a magyar egészségügy :-(

Vegyünk egy banki programot, ami rosszul számolja a zárlati elszámolást, emiatt mondjuk 200 ezer ügyfélnek keletkezik egy-egy hibás tétele, amitől hirtelen nem tudjuk, hova lett 1 milliárd HUF. Ezt tessék behajtani a programozón.

Ez csak egy példa, tudomásom szerint eddig ilyen nem volt, de majd lesz, ui. a szabályozások gyakran változnak, ami a szoftvereseknek állandó szivatást jelent.

--
CCC3

Az általad említett példa egy küldetés kritikus rendszer, hisz nagy értéket kezel és nem szabad hibáznia. Namost egy ilyen rendszernek megvan a fejlesztési technológiája, ami ott kezdődik, hogy megfelelő projektvezetés, csoportkialakítás, kritériumrendszer kialakítása és tesztelési, validálási rendszer kialakítása. Ebből ilyen esetben a specifikációt és a validálást érdemes a megrendelőnek csinálnia.
Vagyis a példádnál maradva szerintem az az egy szem programozó csak annyiban felelős, hogy nem tudta, hogy nem vállalhatja el a munkát, mert nem ez a dolgok menete.
Igazából ilyen rendszerek fejlesztése esetén az kellene, ami az építészetben is van: a tervezés engedélyhez kötött, az engedély meg megfelelő képesítésekhez (építészmérnöki diploma).

A pénzügyi világban az a baj, hogy külsőleg meghatározott határidők vannak. Pl. azt modják, hogy szept 1-tól 3-8-5 szerkezetű számlaszám helyett 8-8-8 számlaszám lesz, azaz minden számlaszám megváltozik. Az elméletileg tökéletes technológia kicsúszik a határidőből, jön aug. 25,26,... (az igazgató megőszül) és valahogy működni _kell_.

--
CCC3

Erkolcsileg?
Igen. Mindenkinek jo munkat kell vegeznie a sajat erejehez merten. Nyilvan ennek ellenere lesznek benne hibak.
Szegyellje magat mindenki, aki rusnya/rossz munkat vegez. Aki nem hajlando tanulni a hibaibol es javitani azokat, az nem alkalmas semmilyen magasan kvalifikalt munkakor betoltesere.

Torveny elott? Nem.
Azert mert ez is csak legalizmust szul. Szaporitja a betarthatatlan es betartathatatlan eloirasokat.
Arrol nem is beszelve, hogy csak az aprobetu fog megvaltozni, tehat novesztjuk a jogszabalyok halmat es nem jutunk tole elorebb.
Mindenki bele fogja irni, hogy ez a kod (mint minden mas) tartalmazhat nem szandekosan bekerult hibakat, melyek esetlegesen biztonsagi kozkazatot is jelenthetnek a kedves felhasznalo szamara.

Innentol kezdve lett meg egy jogszabalyod, lesz egy csomo pered belole, fizetik az adodbol a birokat/ugyeszeket, fizeted az ugyvedeket, megsem tortent semmi...
Arrol nem beszelve, hogy a bizonyotas is maceras lehet.

A bugok osztalyozasa sem kispalyas...
Elmeletileg kihasznalhato szamit?
Akkor is ha eveken at senkinek sem sikerul PoC kodot osszerakni hozza?
Mi az a biztonsagi hiba ami meg elmegy?
Helyi root exploit er?
DoS? Egyaltalan biztonsagi hibanak tekintjuk?
Igen?
Kit erdekel, hogy az ntp szogaltatas nem elerheto arra az idore amig az ember el nem inditja, mert jott riasztas?
Nem?
DoS bug miatt megallt a hitelkartya feldolgozo rendszer. Par millios kieses. Na bumm.

Mi van ha az adott programozo mar nem proggramozo? Elment gatornek? Eloveszi az ugyesz, leulteti a gep ele es addig nem mehet haza amig kesz nincs a javitas?
Vagy csak egyszeruen lecsukjak? Vagy karteritest fizettetnek vele?

Sokkal inkabb a tamadasok elkovetoit kellene elfogni es torveny kezere juttatni.
Persze ez sem egyszeru. Mi az eselye annak, hogy valakit el is kapnak?
Aztan meg mennyi idore ultetik le? Mert hat tulajdonkeppen nem is okozott kart. Csak allt a webszerver egy kicsit.

Igennel szavaztam, de ennél árnyaltabb a kérdés:
Csak annyira legyen felelős, ami az ő munkaköre. Ha ő csak kódoló és kapja az utasításokat meg a terveket és van kód átnézés, meg tesztelés meg minden, ami hozzátartozik a szoftvertechnológiához, akkor értelemszerűen a kész, tesztelt szoftver hibáiért csak nagyon mérsékelten lehet felelős, ott a projektvezetésen van a felelősség. De ha egyszemélyben fejlesztget, akkor bizony legyen felelős azért, amit csinál. Én pl. mindig átnézem a kódot saját magam mielőtt bevágom a repoba, mert bár eddig anyagilag nem húztak le amikor valami hiba volt (belső használatú szoftverek), de azért a cégnek elég komoly gondokat lehet okozni, aminek a helyreállításában nekem is aktívan részt kellett vennem (program kijavítása, ha olyat cseszet el, akkor megtenni mindent az adatok megmentéséért). És bizony ha a saját bőrödön is érzed a szoftverhiba következményeit (még ha csak annyira is, hogy hétvégén rohanhatsz be a munkahelyre, hogy éjszakázva kijavítsd a hibát mielőtt mégtöbb gondot okoz), akkor ráébredsz, hogy többet ér inkább rászánni a plusz időt az alaposabb kód átnézésre és tesztelésre.

A kérdés közösségileg fejlesztett szoftvereknél mégnehezebb: ki is követte el a hibát? az aki valamit rosszul írt át a szoftverben miközben valamit fejlesztett benne (nagy szoftvereket forráskódját átlátni általában elég nehéz), vagy az aki vezette a projektek és hagyta, hogy a forráskód egy szemétdombbá váljon, amit nem lehet felelősségteljesen fejleszteni, vagy az alőző fejlesztő?

összességében azt mondom, hogy a fejlesztőknek felelőségteljesen kellene fejleszteniük és bizony valamilyen jellegű kártérítésre is lehessen őket kötelezni: pl. adott időn belüli hibajavítás kisebb hibák esetén, maximális kumulált kártérítés (mert azért az szép lenne, ha csinálsz egy progit, eladod 10 embernek és a 10 ember összesen többet követel, mint amennyit tőlük kaptál + adó. és mindeközben a szoftver nagyjából használható és a 10 emberkének bizony ebből anyagi előnye van)

Nehéz kérdések ezek!

Most nézem, hogy biztonsági hibákról kellett nyilatkozni. Az mégnehezebb kérdés, de az előbb említettek igazak rá. A többi meg a kedves vevő gondja: Ha biztonságot akar, akkor ne a legújabb, agyonmarketingezett terméket vegye meg, hanem azt, ami már egy ideje bizonyított és sok hibája kiderült és kijavításra került. Amúgy az űrkutatásban alkalmazzák ezt a szemléletet hw és sw terén, hisz egy apró hiba is nagyon komoly károkat tud okozni (akár a teljes küldetés kudarcát is, ami sok-sok-sok millió dollár kárt jelent + ha kutatási projekt volt, akkor a kutatások elcsúszását, a tudományos eredmények késését, akár bizonytalan időre is)

Egyertelmu nem.
Na azert talan megsem egyertelmu. Felvetodott itt a repulogepiranyitas problemaja. Szerintem fel kell osztani a programokat ket csoportra, megpedig a szerint hogy fugg e emberelet a program helyes mukodesetol vagy nem es maximum anyagi kar keletkezik.
Amenyiben a program mukodesenek nincs koze emberelethez akkor egyertelmu hogy nem lehet felelosegre vonni a programozot. A Programozo ir egy szoftvert egy bizonyos funkcio ellatasara , ha azt a funkciot ellatja akkor o teljesitette a sajat reszet. Az hogy programban maradt hibakat valaki kihasznalja karokozasra az mar nem a programozo sara, meg a fent emlitett bsplayeres estben sem.
A masik csoport azon programok amiknek emberelethez lehet kozuk. Ezeknel a progaramoknal nyilvan kovetelmeny a leheto legnagyobb biztonsag es helyesseg , de ezt meg kell fizetni mind penzben mind idoben. Biztositani kell a szukseges eroforrasokat hogy a szoftver keszitoinek legyen lehetosege a programot biztonsagosra es helyes mukodesure megirni. Amennyiben a feltetelek adottak es megis a hibas mukodes miatt katasztrofa tortenik akkor mar elo lehet venni a fejlesztoket de inkabb a ceget. Valamint az is biztos hogy ilyen szoftvereket nem lehet letolteni a sourceforge.net -rol.

Fel vannak osztva, ha emberélet függ tőle, akkor "life critical system" és a kritikus rendszerek fejlesztésének menete vonatkozik rá. Ezenél a tesztelés a teljes fejlesztési költségeknek akár a 90%-át is elérheti.
Eleve ilyen szoftvert végfelhasználó nem vásárolhat hisz ezek beágyazott rendszerek, adott célhardverre fejlesztik őket. Jól is nézne ki, ha otthonra megvennéd a "lélegeztetőgép v1.0 for windows ce" nevű programot, rátöltenéd a pda-dra és rákötnél egy pumpát, a pumpát meg a mamára, aztán elmennél bulizni. Hazaérsz és azt látod, hogy a pda elment sleep módba (vagy lefagyott), a mama meg meghalt...

Túl sarkított a kérdés. Valamennyire nyilván felelős most is: ha sz*rt ír, nem tesz jót a cég hírnevének.
Ugyanakkor elég abszurdnak látom azt a helyzetet, hogy a világon szinte mindenre van garancia, egy-kétezer forintos kütyüket simán vissza lehet vinni, ha elromlik, de ha egy százezer forintos nagyságrendű szoftverben nem működik valami, akkor nem lehet visszakérni az árát.

Az árnál nagyobb felelősséget persze csak seciális esetkeben tartom szükségesnek (atomerőmű, repülésirányítás, ...).
De szerintem a "pénzvissza" típ. garancia azért is lenne nagyon hasznos, mert így
a) az ember nem teljesen zsákbamacsekot vásárolna
b) a szoftvercégeket legalább egy kicsit ösztönözné a minőségi termék előállítására.
Persze a szoftvercégek rögtön tiltakoznak, elkezdenek egymásra mutogatni (nem azért sz*r a program, mert én elszúrtam, hanem mert az x library bugos), de hát ki mondta, hogy azt kell használni?
Ezt a felelősséget szerintem nem csak a biztonsági, hanem minden, a használatot lényegesen befolyásoló hibára ki kellene terjeszteni (azaz, ha a program a könyve szerint tud valamit, de én mégsem tudom arra használni, akkor adják vissza az árát).

Az árnál (lényegesen) nagyobb felelősséget alapból nem tartanék szükségesnek, mert feleslegesen megdrágítaná a szoftvert akkor is, amikor nem akarok fontos adatot rábízni, vagy úgy gondolom, hogy megoldom a backupolást magam.
Az már a felhasználó felelőssége, hogy kiválassza a neki megfelelő konstrukciót (alap garancia vagy valami külön szupport+felelősségvállalási szerződés).

Ha a megvásárolt szoftverhez járna néhány alkalomnyi támogatás + garancia, akkor az ember tényleg úgy érezné, hogy vesz valamit, és nem úgy, hogy védelmi pénzt fizet a BSA-nak, miközben rásóznak valami garancia nélküli szemetet.
Sajnálatos, hogy az IT ipar az "AS IS" licenszel maga is elismeri, hogy nem tud, és nem is akar minőségi terméket előállítani, ahelyett, hogy tenne valamit.

"Az árnál nagyobb felelősséget persze csak seciális esetkeben tartom szükségesnek"

Szóval veszek 899Ft-ert egy kalapacsot es az elso suhintasnal elszall a feje, osszetorve ezzel egy 100eFt-os valamit. Hogy fog az a 100eFt-os kar megterulni?

Ha olyan helyen akarsz kalapálni, ahol 100eFt-os valamik vannak, akkor a kalapács mellé megveszel egy 10000Ft-os support csomagot: ha laza a feje, kijönnek és visszakalapálják (mondjuk 2 éven belül), és max 150eFt-is megtérítik a kárt, ha ennek ellenére lerpül a feje.
Ha viszont nekem van annyi eszem, hogy az értékes cuccokat elpakolom, mielőtt kalapálni kezdek(=backupolok rendszeresen), akkor nekem megfelel a kalapács support csomag nélkül (ha a feje lejön, visszaütöm=ha adatvesztés van, visszamásolom, és többször nem használom ezt a sz*rt), de ha nem lehet vele szöget beverni (=nem képes pl. a szövegszerkesztő a munkahelyen egyel régebbi verzióban írt dokumentumot helyesen megjeleníteni), akkor visszaviszem.
Tehát garantálják, hogy valamire jó a sw, az már kezdetnek jó lenne (azért az zavaró lenne, ha egy lezárt dobozt kapnál a boltban, "szögbeverő 1.0" felirattal, rajta egy EULAval, hogy ha felbontod, már nem adhatod vissza, nem reklamálhatsz, és különben is borulj le a fejlesztők nagysága előtt, és nem tudhatnád, hogy kalapács van-e benne, vagy egy negyed tégla).

Na, en is valami ilyesmi megfejtesre jutottam.

Maskepp fogalmazva szoftverre jotallast lehetne alapbol adni (ha hibas, akkor gyorsan kijavitani vagy visszafizetni az arat, ami ingyen letoltott cuccnal nyilvan semmi). De garanciat vallalni (biztositani a mukodest) csak sulyos osszegekert kell.

Bar leszarod, ez a kerdes igy nem valaszolhato meg.

Legyen e barmi felelosege a programozonak az altala irt kod-ert?

kerdesre lehet igen-el vagy nem-mel valaszolni. Erre nem. Mivel az igen fals perek sokasagat vonza. Hozzaertes teljes hianya van elektronikai szinten a birosagon most is pl: jozsika paszinanszan keresztul feltortek a prutty.hu szervert (igen a rendszeradmin ezt szereti jatszani) jozsikat odacitaljak az igen alapjan o meg kozli: nem a programja hanem a z library a hibas.....
A nem valasz meg azt jelentene szarunk bele. A legjobb egy ugynevezett biztositasi rendszer lenne, itt ugyanis a karesetek kiegyenlitese ugy folyik, hogy ha egyertelmuen bizonyithato hogy kizarolag a hibat a biztositas targya okozta, es mas "nem okozhatta" akkor fizet a biztosito.
Viszont mindenki az igen fele hajlana hisz egyre inkabb eletek mulnak azon hibaznak e a programok (nem csak biztonsagi teren)

Na nezzunk par kritikus szoftveralkalmazast, amit Magyarorszagon fejlesztenek. Fekrendszerek (pl. Knorr-Bremse), mobil es fix halozatok (pl. Nokia, Siemens, Ericsson) es ezernyi banki rendszer. Ezek nemzetkozi szinten is megjeleno komoly alkalmazasok, egy-egy hiba sulyos gazdasagi karokat vagy akar tarsadalmi panikot okozhat.

Sok fejlesztot ismerek ezekrol a teruletekrol. Gyartjak a hibakat tomegevel, koztuk en is. A sok szakerto altal ellenorzott tervezesi fazis utan jon a tobbszorosen ellenorzott kodolas, 5-6 szintu teszteles a kis modultesztektol a nagy osszerakott, mas gyartok termekeivel megspekelt nagy rendszerekig. Hibak marpedig maradnak.

Tegyuk fel, hogy valamit hibaztam, ezzel okozva 50MFt kart. Nagyon ritka, hogy ilyen sulyos esemeny bekovetkezzen, de egyszer az eletben megis realis az eselye. Akkor most egyszer az eletben semmizzenek ki, keruljek csaladommal a hid ala?

Annyival egészíteném ki, hogy a programozó se tud mindenre gondolni. Egy két php-s oldalamat többször is át kellett írnom kinézetre és adatkezelésre is, mert használat közben derültek ki a defektek/használati nehézségek.

---------------------------------------------------------------------
„Az Univerzum már elég nagy és öreg ahhoz, hogy egy fél óráig vigyázzon magára.”

látom kevés programozó van itt :))))