Felelősségre vonhatónak kellene-e lenniük a fejlesztőknek az általuk gondatlanságból a szoftvereikben felejtett bizt. hibákért?

Igen.
37% (214 szavazat)
Nem.
51% (299 szavazat)
Egyéb, leírom.
12% (72 szavazat)
Összes szavazat: 585

Hozzászólások

A szavazás apropója:

Should developers be sued for security holes?

tl;dr

Dr. Richard Clayton, a Cambridge Egyetem biztonsági kutatója szerint az olyan gondatlan szoftverfejlesztőket, akik egyébként odafigyeléssel elkerülhető biztonsági hibáik miatt az ügyfeleiknek kárt okoznak, felelősségre kellene vonni.

--
trey @ gépház

Szerintem ezt a szálat figyelmen kívül hagyhatjuk. Kártérítési perek minden bizonnyal kemény pénzét eladott szoftverek után indulnának. Legalábbis nem hiszem, hogy valakit azért citálnának bíróság elé, mert az általa fejlesztett ingyenesen hozzáférhető chatprogram kétszer összeomlott és ezért nem tudott a felhasználó a haverral egyeztetni az esti sörözésről.

--
trey @ gépház

Szokott lenni kártérítés, ha az benne van a szerződésben. Csak nem szokás leverni a fejlesztőn, a cég fizeti. Ha úgyis annyit és akkorákat hibázik egy ember, akkor megválnak tőle, de semmi értelmét nem látom a millió Euros kárt az ennek a töredékét kereső ember nyakába varrni. Kifizetni úgysem tudja, tegyük tönkre az egész életét, mert egyszer elfelejtett egy input ellenőrzést? Az én alapfeltevésem az, hogy csak az nem hibázik, aki nem dolgozik.

Persze, ne is akarjunk változtatni. Legyenek a programok nyugodtan szarok. Tegyük tönkre annak az életét, aki ezeket a programokat supportálja. Egyszer húzz fel egy üzemeltetői sapkát. Pl. gagyi programozás miatt betörtek egy világcéghez sorozatosan. Viszik a jelszavakat, az ügyféladatokat, amik akár clear text-ben vannak tárolva (láttunk erre példát nem is olyan rég, ugye?).

Ki szopja a legnagyobb faszt? Az üzemeltetés. Többszörösen is. Egyrészt neki kell takarítania. Neki kell bizonygatnia, hogy a hibát nem ő vétette. Neki kell a rendszert újraimplemetálnia. Neki kell a programozó sokszori próbálkozásait újramegvalósítania (patchek, most már jó, nem mégse, ne azt, küldök újat).

Teszem hozzá, hogy a programozó sokszor csak munkaidőben hajlandó a saját szarát feltakarítani, az üzemeltető meg sokszor éjszakázik, hogy a ganét takarítsa. Más hibája miatt.

Hol itt az igazság?

--
trey @ gépház

"Ki szopja a legnagyobb faszt? Az üzemeltetés."

Olcsó húsnak híg a leve. Vegyenek rendes rendszert rendes felelősségvállalást tisztázó szerződéssel és kész. Ez olyan, mintha a teszkó gazdaságos kötözött sonka miatt panaszkodnál, hogy az nem a legkiválóbb színhúsból készült. De ezt már mások is leírták, hogy joga van a vevőnek gagyit venni, de tudnia kell, hogy ez mivel jár. Engem pl. ne fossz meg attól a jogomtól, hogy ingyenes Fedorát töltsek le magamnak, aminek minden hibájáért maximum a saját fejemet verhetem a falba.

Ugye azt érzed, hogy ezen a piacon CSAK gazdaságos szállítók vannak?
Én még nem olvastam olyan EULA-t amiben a felelősség részleges vagy teljes kizárása ne lett volna kb 60%-a a teljes szövegnek.
Ha találsz céget aki nem teszi bele szólj, veszek tőlük valamit, aztán egy hét múlva a gatyájukat is leperelem.

hja, csak mikor sok pénzért megvett rendszerrel is ugyanez van, nem tudsz mit csinálni. Üzemeltetőként ezzel nap mint nap szembesülünk, hogy a fejlesztő szar@rik rá, nem érdekli a probléma, mert TUDJA, hogy úgyse őt veszik elő, ha egyáltalán elő tudnak venni valakit. ilyenkor persze mindig az üzemeltetés az, akivel megpróbálják elvitetni a balhét. Az üzemeltető meg magyarázkodhat, sokszor ok nélkül.
Nálunk is ez van. 10-ből 8 alkalommal más trehánysága miatt írhatjuk a riportokat, állhatunk a szőnyeg szélén, és lapátolhatjuk a trágyát. A fejlesztő meg megvonja a vállát, hogy majd a következő release-ben javítja a hibát. És ezt megteheti, mert az elméleti lehetősége sincs meg annak, hogy egy gondatlanságból elkövetett hiba miatt felelősségre vonják. Ha üzemeltetőként gondatlanságból hasonló probléma adódik, akkor az a jobbik eset, ha megúszod egy fegyelmivel. Rosszabb esetben már a belépőkártyád se megy, mire a nagyfőnökkel folytatott beszélgetés után mennél vissza az asztalodhoz...
Persze, aki dolgozik, az hibázik. Ez így is van. De nagy különbség az, amikor az ember megtesz minden tőle telhetőt és úgy lesz valami probléma, vagy tud a problémáról de pusztán hanyagságból nem foglalkozik vele, mert tudja hogy úgysem lesz semmi következménye a dolognak.

Nekem inkább az a gyanúm, hogy nem a megfelelő szerződéseket kötitek a megfelelő összegért. Én olyan szoftvercégnél dolgozom, ahol bizony a hibák után igen vaskos összegeket fizetünk az üzemeltetőknek. (Egy megőszült programozó teljes ingó- és ingatlanvagyona semmi hozzá képest.) De első körben is az azonnali problémamegoldáson van a hangsúly, még akkor is, ha nem kapunk érte egy fityinget, mert a hiba nem a mi készülékünkben, hanem máséban vagy két "tökéletes" eszköz ügyetlen együttműködése miatt alakul ki.

A legnagyobb problémánk persze az, hogy valahogy kiszedjük az üzemeltetőkből, hogy mi is történt. Általában nincsenek vagy hiányosak a logok, a konfigurációkat nem mindig szeretik kiadni. Így aztán szegény programozók sokat ülnek a hibajelenségek felett, míg megsejtik, hol lehet a gond. Közben pedig az üzemeltetők ütik a fejüket, pedig piszok komplex szoftverek milliónyi konfigurációs lehetőségéből az üzemeltető embereinek segítsége nélkül nem mindig triviális a probléma megfejtése. Lehet a programozókat, tesztelők hadát és a specifikáció írókat szidni, de én azt látom, hogy becsülettel dolgoznak, minden változtatásra milliószámra ugranak rá a tesztesetek. Így nem ártana, ha az üzemeltetők nem vásárolnának be olcsó bóvliból és a problémaelhárításban legalább logok szintjén hozzájárulnánk. Mi programozók partnerek vagyunk benne.

A gondosságra szánt időt és energiát valakinek sajnos meg kell fizetnie. Vagy a fejlesztő cégnek fizet az üzemeltető vagy a saját emberei viszik el a költségeket a problémák megoldásánál. Ez persze nem nulla vagy egy, hanem bizony pénz kérdése is, hogy milyen arányban oszlanak meg az esetlegesen felmerülő problémák orvoslásának költségei. Ilyen egyszerű a képlet, ha az ember a vendor lock-in-t tudatosan kerüli.

Ebből szerintem látszik, hogy a probléma nem a programozók felelősségre vonásának hiányával van, hanem azzal, hogy a szoftver és a hozzá kapcsolódó szolgáltatás minőséget meg kéne fizetni, illetve a fizetéssel arányos minőséget kéne elvárni.

Bocs, de ez a nyavalygas eleg amator hozzaallas.
Lehetne egy olyan szavazas is, hogy mikor felelos az uzemeltetes.
Mert mondjuk nincs tisztaban a sebezhetosegekkel/lehetosegekkel.
Hosszu am a lanc.
Egyebkent, ha ugy erzed megszivattak, es ennyire igazsagot akarsz, fogod magad, bepereled a ceget/akarkit, aztan lesz ami lesz.
Nincs egyetemleges felelossegvallalas, elfogadod a felteteleket es annak meg az igazsagerzetednek megfeleloen cselekszel.
Azert a legtobb open/free cucc csak sajat felelossegre hasznalando, oda is van irva, ha fizetos, akkor meg le van fektetve ilyesmi.
Szinte barkit be lehetne perelni, ha a kodja egy olyan kornyezetbe kerul, ahol barmilyen hiba veszteseget okoz.
Egyebkent a biztonsagi hibakat nem kotelezo kihasznalni.
Sot mi a biztonsagi hiba ?
Pl egy szar halokartya driver mi ?
Ez kb olyan, mint a szabadalmi perek, meg a vegen elszabadul a pokol.
Megfoghatatlan ez az egesz.
Ha valaki szar programozo, rakjak ki, mint barkit, ha szarul vegzi a munkajat, de ez legyen a cege gondja.

Az a baj, hogy próbálod a szőnyeg alá tolni a problémát. Kis ember vagyok én, hogy itt igazságot akarjak. Én max. megszavaztatom és elmondom a saját véleményem. Ennél magasabb körökben foglalkoztak / foglalkoznak a kérdéssel.

Tisztában voltam azzal, hogy darázsfészekbe nyúlok ezzel, de hát ez is volt a célom. Lehet személyeskedni, köpködni, de azzal tisztában vagyok, hogy a véleményemmel nem vagyok egyedül.

--
trey @ gépház

nem akarom a szonyeg ala soporni.
ha valaki perelni akar, pereljen, senki nem fogja megakadolyozni.
az eredeti cikkben hamburgek vannak, de ha etelmergezest kapsz, akkor a burger kinget pereled es nem azt aki elkeszitette a kajadat.
csak ahogy kihoztad, hogy a programozok hulyek/suttyok, az uzemeltetok pedig a csaszarok, mondjuk egy kicsit furcsa.
Mindenhol vannak idiotak, tehetsegtelenek, tehetsegesek, nincs olyan hogy a programozo ilyen, az uzemelteto olyan.
Viszont vannak lelkiismeretes, jo szakemberek, meg vannak szarok, es ennek minden fokozata, de ez minden szakmara igaz (rendszergazdakra, buszsoforokra, stb...)

"csak ahogy kihoztad, hogy a programozok hulyek/suttyok, az uzemeltetok pedig a csaszarok, mondjuk egy kicsit furcsa."

Én ilyet nem mondtam és nem is állt szándékomban ilyet még sugallni sem. Ha így jött le, akkor az szándékomon kívül volt és itt most ezt tisztázom.

--
trey @ gépház

Ugyan én fejlesztő vagyok, de teljesen megértem a problémád, nagyon nem jó dolog, hogy a fejlesztőt nem érinti ill. gyakran nem is tudja, hogy hogy viselkedik az alkalmazása production környezetben.

Ellenben a vitaindító cikkben az van, hogy

Today software generally comes with End-User License Agreements that require the user to sign away their right to sue software developers if their app contains security flaws that leaves the user’s computer open to attack by malware.

Clayton is arguing for regulations that remove the developer’s right to waive any responsibility for security flaws in their software

magyarul a fejlesztő nem háríthatja el a felelősséget a programja hibáiért, ami azt jelenti, hogy akkor is felelősséggel tartozik érte, ha ezt a megrendelő kifejezetten nem kéri. Mégegyszer: még akkor is felelősséget kell(ene, a javaslat szerint) vállalnia érte, ha szerződésben rögzítik a felek, hogy nem tartozik érte felelősséggel. Ez pedig - mint már fentebb leírták - a fejlesztés költségeit minimum 10szeresére növelné minden projektben, ami nyilvánvalóan nonszensz.

Egyébként nem igazán értem a pampogás okát, mert ugyan nem szokás - és mondjuk ingyenes szoftver esetén indokolatlan is - hogy a fejlesztő felelősséget vállaljon, de ettől függetlenül semmi nem akadályozza, hogy egy megrendelő úgy vegyen meg egy fejlesztést, hogy aláíratja a felelősségvállalást a fejlesztővel. Én is szerződtem már úgy projektre, hogy garantáltam, hogy az alkalmazás normál üzemi működése nem fog adatvesztést okozni a megrendelőnek, és ha bizonyíthatóan az alkalmazás hibájából mégis adatvesztés történik, akkor azért én vagyok a felelős. Nem volt ezzel semmi bajom, jogosnak éreztem és simán belementem.

Visszatérve az eredeti problémára mondjuk a devops azért jó, mert a fejlesztő egyben üzemeltető is, magyarul az szív az alkalmazással aki írta, aztán máris hamarabb ki lesznek javítva azok a bugok. Sokkal normálisabb megoldás, mint hogy úgy ültetjük a fejlesztőt a gép elé, hogy ha elb*ssza a programot akkor be lesz perelve.

--
CyclonePHP

"Nem volt ezzel semmi bajom, jogosnak éreztem és simán belementem."

Egy dolog, ha van dontesi jogkorod, es egy masik, ha koteleznek ra. En peldaul egy vecepapirtarto kifogyaserzekelojehez nem biztos, hogy alairnek egy ilyen tipusu felelossegvallalast. Az csak az egyik dolog, hogy rendeltetesszeru hasznalat soran elo sem fordulhat adatvesztes, de emiatt ertelmetlennek is tartom. Ha viszont koteleznek ra, akkor lehet, hogy az ar fog emelkedni, de lehet, hogy elmegyek uzemeltetonek.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Én ismerek programozóban is lelkiismeretest és üzemeltetőben is csocso-bajnokot. :)

Azért azt is megnézném, mikor egy szoftvert, amin 4-5 éve dolgozik mondjuk kétezer ember (tervezi, fejleszti, teszteli, üzemelteti, felhasználót szándékosan nem írok ide, az még párszáz/ezer ember) olyan üzemeltetői, vagy kár fejlesztői csoport "implementálna", akik minden problémáért a másik csoportot/kat okolják; meddig lesz életképes ill. mennyibe kerül a végén. Meg kell válogatni a szoftvert, a hardvert és akit engedünk ezekhez hozzányúlni, azokat is szerintem. Példát pedig mindkét oldal (infrastruktúra vs. fejlesztés) tud mondani, amikor a másik oldal hanyag volt, ettől még egyik fél sem alárendelt vagy kevésbé fontos a végcél (urambocsá' elégedett felhasználó) szempontjából.

Már csak azért sem volna korrekt a fejlesztőn leverni a kárt, mert az egy dolog, hogy ő elfelejtett egy input ellenőrzést, de nem kellett volna a tesztcsapatnak megtalálnia ezt a hibát? Akkor nem inkább rajtuk, a minőségbiztosításon kellene leverni? Vagy nem lehet, hogy már eleve a requirement-ek közül hiányzott valami fontos, ami okozza a hibát? Vagy nem lehet, hogy a PM volt hülye, és kevés teszt-effortot tervezett be? Stb...
Az összetettebb dolgokat cégek, alkalmazottak együttese végzni, és egyetemesen, a cég egésze felel az okozott kárért. Ezért (is) létezik a vállalati forma.

:wq

Szia,
És nem lehet, hogy jelen esetben a "fejlesztő" ezek összességét jelenti? Amikor csapat dolgozik, akkor a csapat kívülről nézve egy és konzisztens (még akkor is, ha belül ölik egymást)... Így is kell értékelni szerintem a "fejlesztő/programozó" szavakat ebben a kontextusban...
Az egyes programozók a saját felelősségi körükben mozognak, és annak kell eleget tenniük, ahogy rendre mindenki más is a saját feladat és felelősségi körének megfelelően...
A csapatnak, pedig az egészért...
Üdv,
LuiseX

"Kártérítési perek minden bizonnyal kemény pénzét eladott szoftverek után indulnának."

Miért kéne, hogy így legyen? Mi van, ha egy hobbiból készített, ingyenes kis szutyok daemon "gondatlanul" megírt kódján keresztül nyomják fel a szerveremet, törlik az adatbázisomat, ezzel mondjuk 100 millió USD kárt okozva? Pereljék szét a szegény figurát?

Ha a Google robotpilótája okoz századekkora kárral járó közlekedési balesetet, pereljék csak a Google-t, hiszen nem ingyenes cuccról van szó.

A probléma az, hogy ha minden fejlesztő felelős a munkájáért, akkor nem lennének olyan hobbi projektek, mint pl. ahogy maga a Linux is indult. És nem lennének free szoftverek, mert mindenki retteghetne, hogy jaj, nehogy valaki akár egy évtized múlva is egy buta bakit találjon a kódomban.

Szerintem előbb a törvényeket és rendeleteket megalkotók, megszavazók és törvények esetén az aláíró köztársasági elnök feleljen minden esetleges kárért személyesen, aztán ha a maguk háza táján már megértették, hogy miről is van szó, hát elkezdhetnek a szoftverekről egyeztetni a szakmával. De még ekkor se felejtsük el, hogy tudtommal egyetlen magyar törvény komplexitása sem ér a közelébe pl. a Linux kernelének.

Én nem mondtam, hogy így legyen, hanem _feltételeztem_, hogy így lenne.

"Mi van, ha egy hobbiból készített, ingyenes kis szutyok daemon "gondatlanul" megírt kódján keresztül nyomják fel a szerveremet, törlik az adatbázisomat, ezzel mondjuk 100 millió USD kárt okozva? Pereljék szét a szegény figurát?"

Nem fekete-fehérben kéne gondolkodni és nem is így gondolkodnak a való életben, de nagyon leegyszerűsítve azt gondolom, hogy ha valakinek a hanyagsága nekem kárt okozott, akkor valamilyen szinten feleljen a tettéért. Nyílt forrásnál ne feledjük, hogy ott a büntetés, hogy egy-egy ilyen bakiért akár egy egész világ hahotázik rajta. Ez akár rányomhatja a bélyegét az egész szakmai pályafutására. Zárt forrásnál könnyebb a maszatolás, sumákolás. Én ezt is a serpenyőbe tenném mérlegeléskor.

--
trey @ gépház

"egy-egy ilyen bakiért akár egy egész világ hahotázik rajta"

Hány privilege escalation bugos kód íróján hahotázik a világ?

"Nem fekete-fehérben kéne gondolkodni"

Szerintem meg teljesen végiggondolatlan az eredeti kérdésfelvetés, nem pedig a belőle származó gondolatok a hibásak. A világon szinte mindenkit nap mint nap frusztrálnak hülye szoftverhibák és gyakran okoznak anyagi kárt is ezek. Indulatok születnek bőven. Egy üzleti felhasználót nem nyugtatja meg, hogy igaz, hogy elszállt az adatbázisa, de a hibát épp egy ingyen írt ext4-es kódrészlet okozta. A másik hibáért viszont kártalanítják, mert pénzért írt ZFS kód a ludas.

Valakinek állni kell a kárt, de nagyon fontos, hogy expliciten látszódjon, hogy ki az. Ha pénzért írnak nekem kódot, akkor a kódot író vállalkozás. Ha ingyenes cuccokból pénzért összeraknak nekem rendszert, akkor a rendszert összerakó vállalkozás. Ha én felteszek magamnak egy ingyenes Fedora 17-et, akkor én kártérítem magamat.

"Valaki hanyagságáért fizessen más."

Pedig ez lenne szerintem a jobb választás, két okból is. Egyrészt szerintem a FOSS-t gyakorlatilag megölné a javaslat, a korábbi példámból következően. Másrészt a jogrendünkben van példa erre: Ha a gyártó nem vonható felelősségre (pl. mert a világ túlvégén élő forrasztó bácsika), az importőr/forgalmazó a felelős (ezt tudja is előre, a kockázatot beépíti az üzleti tervébe).

"Valaki hanyagságáért fizessen más"

Minden vállalkozásban van kockázat. Az ingyenes cuccok összerakásáért valaki pénzt kaszált, cserébe valamilyen szinten felelősséget vállal, szerintem ez teljesen normális. Nyilván nem _teljes_ és lehet, hogy nem anyagi felelősséget, de ezt a szerződésben szépen le kell írni.
---
;-(

Osztom, én is így látom. Ha élesbe veszek egy rendszert, akkor azzal szoktam kivédeni ezt, hogy a fejlesztö is szépen ügyeletben van, és ha gáz van, akkor ugrik. Mióta a fejlesztés felel az éles rendszerért minden egyes változtatás után két hétig, azóta érdekes módon megszüntek a "jajeztméggyorsanjáccukmabemerkurvafontosvesszöhiba" és hasonló kérések, és furcsamód tudják magukat tartani a határidökhöz és tesztelnek is rendesen. Hmm, kicsit furcsa, nem? ;)
( èppen ilyen felelösségáthárítás végett hagytam fel importöri tevékenységgel. Megveszed nyomott áron, de annyit nem keresel rajta, hogy a sok selejtet ki tudd gazdálkodni, gyártóra verni pedig nem lehet. )

Pont ezt akartam én is írni. Nyilt forrásnál és ingyeneseknél ott a kitétel, hogy saját felelősségre, fizetősöknél meg ott a licenc.

Az, hogy a fejlesztő a cég házon belül, hogy rendezi a fejlesztővel megint más kérdés. A fizetés összegétől függően el tudok képzelni olyan munkaszerződést is, ahol a fejlesztő(k) anyagi felelősséget is vállalnak.

Nem. A szomszed epit egy sima csaladi hazat, amit valaki ledont egy tankkal, mire eloveszik az epiteszt.

Ha egy bunker ajtajat siman be lehet rugni, az egy dolog. De ha egy csaladi hazba tornek be tankkal, akkor nem az epiteszt, hanem a tankos sracot kell bortonbe csukni.

Ugyanigy: ha vki egy desktop rendszerre trojait pakol, akkor be kell tenni a bortonbe, a szoftverfejlesztot meg beken hagyni.

----------------------
while (!sleep) sheep++;

Es mi van akkor, ha a csaladi haz biztonsagi ajtaja nem is annyira "biztonsagi" es bejarnak rajta a betorok? Akkor elo kell venni a betoroket, az ajto gyartojat meg beken kell hagyni, hiszen nem az o hibaja, hogy konnyeden atjutottak a vedelmen? Kicsit humoros ez a hozzaallas, de ha veled tortenne meg, maskepp gondolkoznal, ez biztos.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

A legnagyobb kulonbseg: osszedol vagy osszedontik.

A feltorhetetlen szoftver tokeletes termek, a nem osszedolo haz pedig 'eleg jo' termek. A ketto eg es fold.

Volt multkor egy jo pelda: valaki elojott valami bonyolult modszerrel, amivel pacemakereket lehet kinyirni. A kerdes: kicsereled-e az osszes pacemakert minden evben, amikor valaki rajon egy uj modszerre, amivel ki lehet oket utni, vagy inkabb azt akarod buntetni, ha valaki b*szakodik a pacemakerekkel?

Nem csak a szoftverek tokeletessegere kene figyelni, mert az sosem lesz 100%-ig biztos, hanem a megfelelo buntetesre.

Ja, aki szerint a szoftver olyan, mint egy lakat/haz/operacio, illetve a feltorese olyan, mint egy betores/osszeomlas/muhiba, az siman ne szoljon hozza a topichoz, mert fogalma sincs, mirol beszel, es a velemenye annyira relevans, mintha egy atlag velvetes vagy a noklapja.hu-s hozzaszolo lenne.

----------------------
while (!sleep) sheep++;

Hasonlóképpen, ahogy neki, a szakmában dolgozóként saját véleményem lehet a dologról. Nagyon-nagyon sokat szoptam már kretén programozók miatt, akik szerint mindig másban van a hiba (hardver, hálózat, fejlesztőkörnyezet, csillagok állása, ufók), de bennük semmi. Aztán az esetek 99%-ban kiderült, hogy a programozó urak basztak el valamit. Ráadásul, amikor erre a figyelmüket felhívták, akkor még be is vágják a durcát.

Bevallom, nekem ez annyira nem tetszik.

--
trey @ gépház

Csak én nem kapálódzok ez ellen. Elfogult vagyok. A programozók is azok. Viszont a szavazás állása alapján nem vagyok egyedül a véleményemmel.

Megvallom őszintén, engem meglep, hogy egy ilyen oldalon, ahol ennyi programozó van, ilyen nagy százalékot kapott az "Igen.".

Számomra ez elgondolkodtató.

--
trey @ gépház

Attól tartok, hogy az igenek száma korrelál a frusztrált rendszergazdák számával...
Én is utálok más bugjai miatt szívni, de vegyük észre, biztonsági hibákról volt szó a kérdésben.

És akkor hadd kérdezzem már meg a kedves igenes rendszergazdákat, hogy ugye ők minden általuk felügyelt rendszeren a legutolsó stabil verziót használják mindenből, ugye a laptop amiről ezeket a rendszereket elérik tökéletesen biztonságos, és nem használják semmi másra, ugye nincs távoli elérési lehetőség rendszereken csak kényelmi szempontok miatt, és ugye mindig mindenhol a legnagyobb biztonságot adó beállítások vannak.

Ha a válasz nemmel kezdődik, és az indoklásban szerepel a pénz vagy az idő, akkor helyben vagyunk, át lehet gondolni ezt a szavazatot még egyszer.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Az üzemeletető meg is kapja érte a felelősségre vonást. Nem is kérdéses, hogy az jár, ha hanyag volt. Senki nem is vonja szerintem ezt kétségbe.

A probléma itt az, hogy egyesek próbálják bizonygatni, hogy a programozónak nem járna felelősségre vonás akkor sem, ha bizonyítottan gondatlan volt.

--
trey @ gépház

Jó, akkor mondok fordítottat: munkatárshoz jött be bugreport, hogy szar a rendszer kurvagyorsan mert különben is. Kiderült, hogy hétvégén az egyik admin magánakciózott a mod_security-vel, mert pár lényegtelen joomla oldalt feltörtek, mivel, aki bérelte a tárhelyet, szart rá nagy ívben.

Konkrétan azt sem tudtam, mit rak fel, mit tör el vele. Aztán mikor szólt kolléga az adminnak, hogy "talán nem kellene berakni olyan szabályt a mod_security-be, hogy 100 input mezőnél többet ne fogadjon el", akkor meg bevágta a "és azt minek?" arcot. Az ügyvél 5x50 mezős táblázatához, mégis minek.

Vagy ugyanez az admin szólt ilyet, hogy az miért nem jó, hogy "ha majd változtat a mod_security szabályain, akkor majd mi utólag hozzáigazítjuk a szoftvereinket?" (Konkrét esetben pont mobiltelefonra kellett volna folyamatosan frissítgetni még WM6-ra).

Szóval azért nehogy már mindig a programozók legyenek a faszkalapok és az adminok az Istencsászárok.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

+1
És emellett sír a szájuk, hogy "jááj, miért nincs az a függvény, miért van letiltva, miért nem mehet a tűzfalon akárhova az app, miért nem tudja írni..."
Aztán mikor kérdezik, hogy miért nem megy a program/app/akármi, akkor az a válasz, hogy "kész, nálam megy, csak szar a rendszer, ezért az élesen nem."
Ilyenkor marha nagy harcokat kell vívni, hogy seggberúgják, hogy ugyan csináld meg rendesen. Teljesen egyetértek.
--
Discover It - Have a lot of fun!

Mindent lehet helyettesíteni. A lényeg, hogy viselkedésileg a szoftver számára a környezet ugyanaz legyen. Az, hogy nincs SMS szerver vagy hasonló, csak file-ba logol egy SMS-t egy processz (e-mail server, akármi), az lényegtelen, ha a szoftver számára az interfész funkcionálisan működik.

No, és itt a hiba. A szoftverek inputja sokkal nagyobb, mint amit ésszerűen kezelni lehet, annyi környezeti dologtól függ, amit sem nem ésszerű, sem nem lehetséges mind lemásolni, ha nagyon akarod, akkor is kimaradnak dolgok.
----
India delenda est.
Hülye pelikán

"A szoftverek inputja sokkal nagyobb, mint amit ésszerűen kezelni lehet"
Nem arrol van szo, hogy mekkora az input allapotter merete, nem errol beszelgetunk. Hanem arrol, hogy olyan nem szabad, hogy eloforduljon, hogy valami megy a tesztkornyezeten, de elesben nem. Ha ez igy van, akkor csak kornyezeti elteres lehet, azt pedig lehet reprodukalni mindenhol. Vas, OS, runtime, interfeszek mas rendszerekkel (ebben a tuzfal is benne van). Ha erre a vevo sem ad, akkor szokjon hozza, hogy valami nem fog menni. Uzleti kornyezetben alap, hogy akkor nevezunk tenylegesen tesztrendszernek valamit, ha az megegyezik az eles rendszerrel. Ha nagyon kell, teljesen szeparalt "internetet" is ki lehet alakitani, ugyanazokkal a MAC-cimekkel, csak sokba kerul. Van ahol ennyit nem er a dolog, de ott nem is vallalnak erte felelosseget, hogy az elesen menni fog.

Létezik-e olyan cég, ami garanciákat vállal a szoftvertermékére? Avagy létezik-e olyan, amiről csak az tudható, hogy minőséget állít elő, korrekten kezeli a felmerülő problémákat, és garanciában javít stb.

Ha igen, akkor mi a bánatért használja az "üzemeltetés" bárki más termékeit? Ja, hogy olcsóbb...?

Avagy rendszergazdák között mindenkitől ugyanazt várjuk el fizetéstől függetlenül?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Akkor ezek szar programozók, akiket nem kell többet megbízni. Ennyi.

De a kérdésben biztonsági hibákról volt szó és nem hibákról úgy általában. És akkor (az egyébként elég szar) házépítéses analógiára visszatérve: perelhető-e az építész vagy a kőműves, ha betörnek egy családi házba?
Ugyehogyugye.

Viszont perelhetők-e ugyanezek egy bank esetén? Igen, ha bizonyítható, hogy ők hibáztak. Csak akkor olyan volt a specifikáció is, és a tervekért-kivitelezésért fizetett összeg is eszerint alakult...

Egyébként vannak szoftvertermékek hasonló garanciákkal. Tehát a dolog nem kivitelezhetetlen. Csak épp annyira drága, hogy nem tud elterjedni egy szűk területen kívül.

A gond az, hogy a felvetés szerint ez a plusz garancia ingyen kéne. Ingyen viszont semmi sincs.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Lehet nem tűnt fel, de a legtöbbünknek a stílus csípi a szemét. Milyen felelősségre vonást vársz? Erre még mindig nem kaptam választ.

Ha szart csinálok és emiatt bedől a fél rendszer, nehogy azt hidd, hogy nekem nem csörögne a telefon és nem vonnának felelősségre emiatt cégen belül. Ha nálatok szarul megy ez a része, hát istenem, azzal én nem tehetek.

Az meg hogy csak munkaidőben vagyok (lennék) hajlandó szopni vele, azon meg légyszi ne lepődj már meg. Ennyire szerződtem, fejlesztőnek mentem, nem üzemeltetőnek, hogy ASAP ott legyek mindig mindenhol. Nem tetszik? Lehet menni autószerelőnek is.

Összecsapott munkát kell kiadni a fejlesztőkek a keze közül? Hát faszom, ne akkor szóljanak, hogy kell ez vagy az, amikor már működnie kellene, hanem időben. Könnyű egy válrándítással "a programozó urak basztak el valamit" kiáltani, ha mondjuk előtte nem kaptak normális specifikációt, hiányos infók alapján kellett elindulni, utánuk meg elmaradt a teljes tesztelés, mert "mindegy, csak menjen már" hozzáállással ment ki élesbe a cucc. Időnként az ügyfél kérésére. (Erre egy megoldás van: számlázni vastagon, legközelebb okosabb lesz előre.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ne haragudj, hogy ismét emlékeztetlek, hogy a téma nem tőlem származik. Max. egyetértek vele. Hogy mi lenne a jó megoldás, azt nem tudom, de ha fizetnek érte, akkor majd elgondolkodok rajta. Azt érzem, hogy ez nincs jól és ennek adtam hangot.

Hogy ez hol működik rosszul vagy jól, azt én nem említettem. Számtalan céggel állok kapcsolatban, hidd el, van honnan mintát venni.

--
trey @ gépház

Legalább a saját véleményed mellett állj már ki és ne másra mutogass. Nem egy random egyetem random professzora kardoskodik itt, hanem te.

És továbbra sem értem, hogy mi alapján mondod, hogy egy sw feljesztő nincs maga szintjén felelősségre vonva.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kiállok a véleményem mellett. Leírtam itt, el lehet olvasni. Annyit jegyeztem meg, hogy nehogy már azért legyen lehurrogva az ügy, mert ezt én találtam ki, mert ez egyszerűen hazugság. Itt én vetettem fel. Nekem is van véleményem róla. De nem én találtam ki és az eredeti kérdést sem én vetettem fel a világban. Csak a mihez tartás véget... Emlékezzünk erre.

"És továbbra sem értem, hogy mi alapján mondod, hogy egy sw feljesztő nincs maga szintjén felelősségre vonva."

Nem gond ha nem érted. Megértem, ha nem érted. Azt is tudom, hogy mi az oka.

--
trey @ gépház

"Az meg hogy csak munkaidőben vagyok (lennék) hajlandó szopni vele, azon meg légyszi ne lepődj már meg. Ennyire szerződtem, fejlesztőnek mentem, nem üzemeltetőnek, hogy ASAP ott legyek mindig mindenhol. Nem tetszik? Lehet menni autószerelőnek is. "
.
Na pont ez az a programozói hozzáállás amitől kinyílik a bicska a zsebemben. Nagyképű és pofátlan.
Te arra szerződtél hogy működik az a szar amit kiadsz a kezedből akkor is amikor te nem vagy bennt a munkahelyeden.
Ha nem tetszik hogy a munkádnak működnie kell akkor is amikor te épp nem dolgozol akkor lehet menni tesco pénztárosnak is, ott nincs ilyen kritérium.

"Nagyképű és pofátlan."

Arról nem tehetek, hogy olyan melót választottál, amely nem tetszik.

Másrészt nehogy azt hidd, hogy nem volt még olyan, hogy péntek este 11-kor is benn szoptam az irodában, holott 5-kor vége volt a munkaidőnek.

"Te arra szerződtél hogy működik az a szar amit kiadsz a kezedből akkor is amikor te nem vagy bennt a munkahelyeden."

Igen, és...? Kapok még két-három hetet tesztelni, vagy azonnal kell?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Még egy kis kiegészítés: amikor mondjuk a kedves salesesek voltak olyan fogyatékosok, hogy hagyják lealkudni a projekt költségét mondjuk 20-30%-al, a fejlesztési időt szintén és még bevállalnak plusz funkciókat és túlóra van keményen (persze, még elvárnák ugyanazt a minőséget is, haha), akkor ki a hülye és kinek nyíljon ki a bicska a zsebében?

Egyik barátom épp ezzel szív.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kevered az 'elfogult' es az 'ert hozza' fogalmat. A programozni tudas egy skill, nem egy ondefinicio. Kezdj el vitatkozni egy motortervezo mernokkel, es kerd szamon, hogy miert nem gyart 0.5l fogyasztasu, 500 loeros motort. Ha az mondja, h nem lehet, vesd a szemere, hogy elfogult.

----------------------
while (!sleep) sheep++;

Ne haragudj, de nem tudom milyen ívről beszélsz. A címben benne van a szó, hogy "gondatlanság". Semmi másról nem volt szó. A gondatlanság és a hanyagság nincsenek messze egymástól. Csak ismétlésképpen a cím:

Felelősségre vonhatónak kellene-e lenniük a fejlesztőknek az általuk gondatlanságból a szoftvereikben felejtett bizt. hibákért?

--
trey @ gépház

A motortervezesben van olyan, hogy fizikai korlat, a termeszet nem enged valamit. A szoftver eseteben a biztosang nem fizikai korlat olyan tekintetben, hogy ido es penz meg hozzaertes kerdese a dolog, nincs (mas) kulso korlatozo tenyezo, ami azt mondana: NEM LEHET! Ez egy l'art pour l'art dolog. Magunknak csinaljuk, mi hatarozzuk meg emberek, hogy milyennek kell lennie. Igen, sok helyen lehet hiba, ez teny. CPU-ban, OS-ben, runtime-ban, framework-ben, de arra nem is vallalhatsz felelosseget. De a sajat szoftveredre igen.

Először is definiálni kellene ki a szoftverfejlesztő?

szvsz az egy CSAPT összessége, és nem egy-egy programozó/tervező/tesztelő/auditor.
Így felelősségre is csak a csapatot (ami a gyakorlatban egy céget jelent) lehet vonni adott esetben... (Aztán persze házon belüle lehet tolni a szart egymásra, de az már az ő dolguk.)

A legtöbb programozónak pl fingja nincs a biztonságról, mert (sajnos) ezt nem tanítják nekik.
Sokszor egy egy ember csak egy-egy kódrészletet készít az egészből...

Az a cég aki minőségi kódot AKAR kiadni a kezéből, az:
- úgy tervezze a cuccait, hogy azok biztonsági szempontból is megfelelőek legyenek
- oktassa a fejlesztőit a cél elérése érdekében
- tesztelje a kódot mielőtt az bekerülne egy éles kiadásba
- auditálja a cuccot biztonsági szempontok alapján is.

Ezek meg ugye PÉNZBE kerülnek... innentől egyből ki lehet találni ki is a felelős a gyenege minőségű kódért ;)

Előre is elnézést a hasonlatért, de szerintem:

Egy ilyen folyamatban a programozó olyan mint a kőműves segédje. És ha összedől a ház amit építettek akkor sem a segédmunkást fogják felelősségre vonni...

Aki meg az open source cuccokon lovagol:
Olvassa már el a licenc ide vonatkozó részét.

--
zrubi.hu

Szia,
Majdnem annyit mondtam csak, hogy +1, de egy dolgot kérdeznék tőled: Miért is a kőműves segédmunkása a programozó? Szerintem az a kódoló... A kettő közt, akár kövezzenek meg érte, de hatalmas különbség van.
A kőműves tudja, hogy kell a falat felépíteni, és tudja, mitől is lesz malter a malter, s beton a beton. És, eszerint is csinálja, s ha kell valamiért, _képes_ korrigálni a munkát. A segédmunkás nem. Az ő dolga a tégla cipelés, és a nem problematikus falak felrakodása, de ettől még félszemmel figyelő őt a munka vezető, és a kőműves is...
A kódolókra igaz teljesen, amit leírtál, mivel ők csak terv-programkód fordító biodroid funkciót látnak el (elnézést mindenkitől, ez nem szakmai tudásra, hanem funkcióra utal), és aszerint is cselekednek/cselekedhetnek...
Lehet bárkit, aki tud írni egy hello-world-t írni, programozónak hívni, de szerény véleményem szerint, ez mind tudás, mind pedig elvárásbeli szint. S ehhez megfelelően egy bizonyos szakmai szint is.
Én úgy vélem, hogy a programozónak hívott alkalmazottak feladata, hogy egy tervet ültessenek át, egészében, a lehető legjobb tudásuk szerint. Nem részleteit, hanem az egészét, még akkor is, ha csak moduljait írják a teljes egésznek. A feladatuk az, hogy a terv megvalósítása sikeres legyen, nem az, hogy 12 millió sort írjanak naponta...
Ez utóbbira vannak a kódolók, akiknél más a minőségi ráta és elvárás is (ettől nem butábbak!), és a feladatuknak is az a lényege, hogy mechanikusan a kész implementációs terveket lefordítsák. De ez egy másik szakma, véleményem szerint, és nem megegyező a programozói munkakörrel...
Remélem sikerült érthetően megfogalmaznom a véleményemet :)
Üdv,
LuiseX

Nem szeretnék senkit sem megbántani, sem degradálni... a programozó vs kódoló témában igazad van.

A gyakorlatban viszont már egy php tanfolyamról kiesett egyedek is programozónak hívják magukat.

szóval nehéz ezt így bekategorizálni.

Ha meg egy multiról beszélünk, lehet bákri tényleg programozó, akkor is legtöbbször csak kódoló munkát végezhet...

---
zrubi.hu

Ahogy a fejlesztőket elnézem, nem igen lehet őket felelősségre vonni. Ismerek olyan fejlesztőt, aki nagyon is képben van azzal, hogy milyen programozási/figyelmetlenség beli problémák vezethetnek biztonsági problémákhoz, mégsem tud mit kezdeni vele, mert a vezetőséget nem érdekli, senkinek nem érdeke, hogy több időt adjanak neki azért, hogy jól megcsinálja, vagy a jelenlegi hibákat javítsa. Persze vannak fejlesztők, akiknek a hozzáállása nem megfelelő, de az előbb említett esetben pl. teljesen mindegy is.
Általában a vezetői pozíciókból érkezik az a nyomás/nemtörődömség, ami a rengeteg réshez vezet. Legalábbis nekem ez a tapasztalatom. A fejlesztő csináljon meg valamit fél óra alatt, amit egyébként 1,5 - 3 óra alatt lehetne értelmesen, megfelelő minőségbe kivitelezni. De ez nem jelent nekik problémát, mivel a fejlesztési modell olyan, hogy ha valami nem jó, akkor majd később foltozgatjuk, csak most legyen meg valahogy, gyorsan.

"nem hiszem, hogy valakit azért citálnának bíróság elé, mert az általa fejlesztett ingyenesen hozzáférhető chatprogram kétszer összeomlott"

Ha kétszer összeomlik, az senkit nem fog érdekelni, ez szinte biztos. Ha kétszer omlik össze azért, mert egy sérülékenység következtében valami olyan csúnya kód került a memóriába, amit a támadó arra használt, hogy egy hálózat többi gépét buherálja, vagy értékes infókat lopjon/szivárogtasson ki, az már kicsit súlyosabb eset. Ettől függetlenül nem feltétlenül a fejlesztő hibája, de el tudok képzelni olyan esetet, amikor a készítő(k) felelősségre vonhatóak lennének (bár, ez már kevésbé magát a fejlesztést érinti.

"tegyük tönkre az egész életét, mert egyszer elfelejtett egy input ellenőrzést" - by Zebra

Nem kell tönkretenni az életét, de az "elfelejtett" -re azért van megoldás... csak hát ugye, meg kéne tervezni a kódot is. Kis cégekre ez nem jellemző.

"Mit várnak a szoftvertől ha az OS amin fut tele van résekkel." - by Zolti

Az egy dolog, hogy az OS tele van lyukkal, de azért azt általában (persze nem mindig) nehezebb kihasználni, mint a rajta futó alkalmazásban található réseket, már csak azért is, mert az alkalmazásokkal egy lényegesen nagyobb közönség kommunikálhat. Az OS-ek önmaguk távolról manapság már valamivel kevésbé sebezhetőek, ellenben az alkalmazások lyukasak. Ha az alkalmazás kaksi, akkor könnyen hozzáférhetsz az OS szinthez, onnan pedig esetleg több, rajta található alkalmazáshoz. Persze itt az üzemeltetésnek is felelőssége van...

Szerintem egyszerű a dolog: mindenki válogassa meg jól, hogy milyen szoftvereket használ. Ha cégről van szó és nincs erre kompetencia, akkor fizesse meg, vagy vállalja a felelősséget. A fejlesztés, amennyire lehet, figyeljen oda és kérnék minden fejlesztési vezetőt, hogy jöjjön meg az esze, könyörgöm! :)

Morin
CEH / ECSA / ABC / NBC / FBI / KGB / NSA / STB

Ez egy nagyon érdekes topic, nem véletlen hogy ilyen nagyra nőtt a hozzászólások száma. Én amúgy rendszergazda vagyok és én is utálom ha egy szarul megírt szoftver miatt rugdossák a seggem (nem ritka eset), de ennek ellenére a válaszom mégis egyértelműen nem, a következő okokból:

Korábban már valaki írta azt hogy nem olyan az informatika mint az építészet aminek több ezer éves hagyománya van, és konkrét szabványoknak kell megfelelni. Ha a szabványoknak megfelel az épület de arra ráesik egy repülő ami megöli az épületben dolgozókat akkor egyértelmű hogy nem vonható felelősségre az építész, mert a szabványoknak megfelelt az épület. (Feltételezve hogy a megrendelővel nem egyeztek meg külön abban hogy ki kell bírnia hogy ráessen a repülő)

Innentől kezdve ezt lefordítva az informatikára, hogy határozza meg azt bármilyen bíróság hogy a programozó "gondatlanságból" vétett hibát? Mi van ha 0-val osztott mert nem ért annyira a szakmájához hogy tudja hogy ezt nem szabad, és a specifikációban sem volt külön rögzítve? Látszólag a hiba triviális, de ki mondja meg hogy az emberünknek tudnia kellett volna hogy 0-val nem osztunk? Talán benne van a diplomájában hogy ezt ő tudja? Vagy benne van az érettségijében ha diplomája nincs? Vagy mi garantálja? (A security az egy akkora terület hogy nem várható el minden programozótól hogy ismerje az összes behatolási technikát amik ellen felkészült kódot kell írnia...)

Ha pl. a gyerekem belázasodik meg napokig fáj mindene és én láz és fájdalomcsillapítóval tömöm mert azt gondolom hogy az elég, de a gyerek belehal, akkor elítélnek gondatlanságból elkövetett emberölésért ugyanis nem vagyok orvos én nem dönthettem volna úgy hogy az adott gyógyszerek megfelelőek lesznek.

Viszont ha írok egy programot akkor onnantól annak a programnak én vagyok a programozója, tehát programozó vagyok. Nem kellett diploma, nem is állítottam hogy van, hogy fognak így engem gondatlanság miatt pénzbírságra ítélni?

Másik gondolatom ezzel kapcsolatban: a feljelentő félnek kell bizonyítania hogy a hibát az adott szoftver gondatlan megírása okozta. (Adott esetben szakértő bevonásával persze). A feljelentő félnek lesz memória dumpja az esetről??? Vagy mégis hogy képzelik az egészet?
Tegyük fel hogy a hibás szoftvernek pont be volt kapcsolva a debug.log-ja, és abban látszik minden bemenő adat, meg a chrash időpontja is. A szekértő nekiáll reprodukálni a hibát a bemenő adatokkal, de a hiba nem jön elő. Letesztelte pedig 100szor. Mi van ha elő jött volna de pont csak 101-edszerre? Ki mondja meg hogy a teszteket helyesen végezték el? Újabb szakértők?
Mi van ha a hiba csak úgy reprodukálható ha a teljes szoftver környezetet összes benne tárolt adattal együtt vizsgálják, értem ez alatt a biznisz kritikus infókat, szerintetek ezekhez egy szakértő csak úgy hozzáférhet mert kijelenti hogy csak így tudja reprodukálni a hibát? Nem kellene ilyen információk kiadásához hosszas pereskedés? (Pláne ha ez már nem is a bíróság által kijelölt szakértő mert annak szakvéleményét az alperes nem fogadta el...)

Összefoglalva, én mindenképp támogatnám hogy felelősségre vonható legyen a programozó, de a válaszom mégis NEM, mert nem lehet meghatározni hogy pontosan miért is felelős egy programozó. Továbbá ha minden felelősségi kör le is lenne specifikálva, akkor is egy bizonyítási eljárás végtelenül hosszú lenne, ha egyáltalán a végére lehetne érni...

Ha az adott helyzetben a projektmenedzser lesz a felelős az általa áterőltetett dolgokért, akkor igen. Ha a végén azon a programozón csattan az ostor, aki elmondta, hogy az adott megoldás veszélyes, csak az "egyszerű gondolkodású" menedzserek nem fogták fel, akkor nem...

Arról, hogy a cég hajlandó-e erre. Lásd: bármely microsoft termék eula, ahol minden létező dolog ellen bevédik magukat. Elbassza a Word a formázást? Excel formula kerekítési hibát vét és ez neked üzletbe fájt? Mossa kezeit: eulát elfogadtad telepítéskor, nem felel a károdért.

Akkor majd - az addig - slampos és "laza gyerek" programozó hozzá fog szokni, hogy az ilyeneket írásban kommunikálja le a projekt menedzserrel és kinyomtatva el is tegye ezeket a leveleket.

A seggfej menedzser (mert sokszor azok, sőt a kiválasztásuknál szempont, hogy nem lehet szakmai képzettsége!!!) pedig be fog tartani bizonyos időket, tesztelési fázisokat, szakmai szabályokat, és nem nagyképűsködik, hogy "oldjátok meg rövidebb idő alatt!".

Oh, ha csak ilyen egyszerű lenne a kérdés...
Vajon mit nevezünk fizettethető biztonsági hibának? Olyan kondíciót, amin keresztül a termék helyileg privilégiumszint emelését okozza, vagy ami távolról kihasználható, vagy más az is elég, ha merevre fagyasztja a gépet?
Mi van akkor, ha egy rendszerszintű hívás hibás alkalmazása (értsd: nem dokumentált OS bugra pacsál rá a fejlesztő) miatt lesz biztonsági lyuk? Mi van akkor, ha adott rendszerkomponens frissítése után keletkezik a hiba?
Vajon ki fizet, ha az adott termékben felhasznált open-source komponens hibája miatt kerül a biztonsági hiba a kódba?
Ki fizet akkor, ha a termék azért jelent biztonsági kockázatot, mert implementációs eltérés van valamely szabvány az OS és az alkalmazás közt, és ebből az OS implementációja a hibás, viszont a javítása esetén az adott OS teljes szoftveres ökoszisztémáját érintené?
Mi van az open-source fejlesztőkkel? Vajon mi lenne, ha szénné perelnék mondjuk az Apache teamet, a bugjaik miatt?
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Szerintem felelősségre vonás szempontjából a szándékos és a gondatlanság majdnem mindegy. Kárt okozott. Ha bebizonyosodik, hogy nem gondatlanság, hanem szándékos, akkor kártérítés mellé még egy jó hűvös kis börtön is kinézne. Számtalan terület van az ilyen ügyeknél, ahol szakértők véleménye alapján hoznak ítéletet. Miben lenne ez más?

--
trey @ gépház

Komplexitási szint.
Pl. Egy közepes ügyviteli szoftver az alatta lévő operációs rendszerrel olyan, mint mondjuk egy pilótafülke a repülőgéppel. Az egyetlen probléma, hogy míg a repülőgépnél a fülkét a többi alkatrésszel együtt tervezik, az OS <-> alkalmazás viszony olyan, mintha utólag tákolnák rá, a fülkét a gépre. Ráadásul a fülkét úgy kell megalkotni, hogy repülőgép minden egyes alkatrésze cserélhető mögötte, és a dokumentáció fele nyomtatottan, a másik fele kézzel firkált szalvétákon van.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

És azt is tegyük hozzá, hogy egy pilótafülkének nagyon komoly limitációi vannak, pl csak megfelelő szakvizsgával lehet kezelni, szigorúan a több könyvet kitevő dokumentációnak megfelelően, büntetőjogi felelősség terhe mellett, míg a szoftvert üzemszerű használatban idomított majmok is nyomkodhatják összevissza, és azt is bírnia kellene.

Igen, érdekes dolog ez, ha lezuhan egy repülő, és kiderül, hogy a pilóták nem pontosan a kézikönyvnek megfelelő sorrendben nyomkodták a gombokat, az pilóta hiba.
Ha egy ügyviteli rendszer megfagy, mert Micike random nyomkodja a gombokat, akkor az rossz UI tervezés és szar program.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Mint minden szakmában ebben is vannak jobbak rosszabbak, figyelmesebbek és gondatlanok, mint mindeniknek lehetnek jó napjaik és rosszabbak. A fejlesztőt elővenni egy hibáért, olyan mint egy segédmunkás kőművest, elővenni, mert vékonyabb falat húzott fel, és ezért összedőlt az épület, az analóg példában a hibás a csoportvezető, a műszaki ellenőr ... stb. A fejlesztő hibáiért, az a cég felel aki alkalmazza, és kialakítja az a környezetet, amiben a fejlesztő dolgozik. Hiszen hogy nem derül ki egy hiba, ha van code review, tesztelés, kód minőséget tesztelő tool-ok, stb. az emberi tényező nagy mértékben minimalizálható. Ha ezek nincsenek akkor azért nem a fejlesztő a hibás, hanem a cég aki ezeket nem teremti meg. Sajnos az a baj, hogy a kereskedelmi szoftverek esetében nem vállal felelősséget a gyártó a termékéért. Még akkor sem vonható felelősségre ha tudott egy hibáról, és direkt nem javította ki.

Na ez a comment tetszik: az egy dolog, hogy vmi sw hibaert felelosegre vonhato-e barki, hogyan definialhato ez, stb. Amde az megint mas dolog, amikor van egy hiba, ami ismert, es nem javitja a gyarto megse, mert valami uzletpolitikai indoka van ra mondjuk (nehogy kideruljon, nem akar kolteni ra, whatever). Inkabb az ilyesmit kene buntetni valahogy (bar ezt sem konnyu): ha bebizonyosodik, hogy egy hiba ismert volt (XYZ bekuldte mar), akkor ne legyen mar olyan, hogy X evig le sem sz*rja a gyarto megse, es amikor emiatt valaki napvilagra hozza, meg nekik all feljebb, hogy ezt hogy mertek ...

Nagy minusz sok.

Egyrészt, a szakértő nem tudja megmondani. Nálunk senki sem tudja megmondani ki a hibás, a kirendelt szakértő még kevébé tudná.

Másrészt pedig nem a fejlesztő a hibás, hanem a cég. A szoftverfejlesztési processzek, a vállalati kultúra, az architektúra, a projectmenedzser, a hájfejű aki elvárja a gyors kommitot, mert megigérte a customernek...

Csak akkor, ha az ajtógyártó is perelhető, mert pl baltával, esetleg robbanóanyaggal meg lehet kerülni a terméke védelmét.

Persze, egy sima bevitel puffer-túlcsordulásánál talán elővehető, de ott sem csak ő hibázott. Pl miért nem a tesztelő a hibás, hiszen gondatlanságból nem próbálta ki azt az esetet, és visszaküldhette volna még egy körre. De a hibák jó része ennél sokkal bonyolultabb, és lehet, hogy eleve hibás tervezésből adódik. Vagy valaki olyan feature-t akart a kódba belerakatni, ami az egész eddigi fejlesztés megerőszakolása, az egész újratervezésére meg a pénzügyes nem bólint rá, mert az ügyfél nem fizetné, és a tulajnak csökkenne a profitja. Itt ki a hibás?

Szia,
De eszkalálhatja kicsit feljebb a tervezési hibát. Amennyiben csapatban dolgoznak, akkor pedig igényelheti a PM-től az erőforrások újra allokálását.
Tehát, van lehetősége gondolkozni, ezért is programozónak/fejlesztőnek vették fel, magasabb fizetésért is :) Bár, M.o.-n ahogy látom, ez nem divat, főleg, mivel a csapatban dolgozó "programozók" sajnos mindössze kódolók, tekintve semmi felelősségi körrel nem jár a munkájuk (legalábbis, az itteni hsz-ekből ítélkezve.)
Am. szerintem nem csak kiértékelheti, ha nem ki kell értékelnie, ha már programozó. A tervezőknek nincs lehetősége... pontosabban, nem lenne szabad, hogy figyelembe vegye a konkrét implementációs architektúrát (vagy , akkor nem tervezőkről beszélünk), ezért ha nem elég szabadsági fokkal tervezi meg a rendszert a programozók részére, akkor a programozónak kötelessége jelezni, hogy már pedig implementációs hibába futunk...
Ellenben egy kódoló kész algoritmust kell kapjon, amit csak interpretálnia kell az illetékes nyelvre, és ő tényleg nem rendelkezik hatáskörrel ez ügyben, sem felelősséggel... (csak a neki kiadott kódsorok elkészítése és minősége kapcsán, de a termék egészért nem...)
Csak, sajnos, azt látom, hogy nálunk nem divat ezeket így értékelni... Mindenki aki látott fordítót, programozónak számít, és mindenki, aki 2-nél több sort ír le, már programozói munkát végez.
És, korábban itt olvasható analógiával élve, a programozó a kőműves, és a kódoló a segédmunkása. A szoftvertervezője pedig az épület megtervezője, és a PM sem más, mint a kivitelező...
Persze, a példa sarkított, és rengeteg minden hiányzik, de talán megmutatja, mire is gondolok :)
Üdv,
LuiseX

A kulcsszó a gondatlanság. Ez mindent leír. Ami nem gondatlanság, az nyilván más téma. Megállapítják, hogy a tőle _elvárható_ gondossággal járt-e el a munkája során. Nyilván, ha külső körülmények kényszerítették, az más kérdés. De itt nem is erről volt szó.

Az én olvasatomban az, hogy a felettesének jelezte, hogy szerinte ez így problémás, de az rákényszerítette, hogy mégis azt alkalmazza, az felmentené a felelősségre vonás alól.

--
trey @ gépház

Szerintem, ha a cégek engednék a programozóknak, akkor a legtöbben azért elég biztonságos programokat írnának. Adott esetben lehetne egy BestPractices lista amin ott vannak a fontosabb szabályok.
De a legtöbb helyen ahol eddig megfordultam, bazira teljesíthetetlenek a határidők.
Egy mostani projekt ami belehalt a feature-creepbe nálunk, egy 2 személyes 3 hetes projektnek indult. Az utolsó backlog 15 hétről szólt. De mivel van más dolog is, ez elment a lecsóba. Pedig még csak nem is megrendelős cucc lett volna hanem belső használatra.

Ha a Menedzserek megtanulnák a programozókat kérdezni, hogy mi mennyi munka, és ennek megfelelő módon terveznének, akkor igen. Akkor programozóként én abszolút képes és hajlandó lennék egy Minőségbiztosítási rendszernek megfelelni.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # N210/Arch

"Ha a Menedzserek megtanulnák a programozókat kérdezni, hogy mi mennyi munka"
Ezen jót mulattam. Ugye ezt te sem gondolod komolyan?

Példa: kedves manager kezedbe nyom egy vaskos doksit egy, számodra ismeretlen hardware-ről, majd megkérdezi, mennyi idő kifejleszteni az interfészt hozzá, mit válaszolsz?

Példa2: valami nyilvántartót fejlesztesz, és érkezik a kérés, hogy a meglévőkön túl újfajta nyomtatványt is kell tudnia. A nyomtatványon olyan mezők is szerepelnek, amiket a rendszer nem tart még nyilván, és a meglévő adatbázisstruktúrával nem is lehet hatékonyan tárolni, refacktoring szükséges. Mennyi időt mondanál rá (több infóra ne számíts, a minta nyomtatványt megkaptad)?

Példa3: java fejlesztő vagy, és kiderül, hogy a library, amit használsz hibás, javítani nem fogják, ezért át kell térni egy teljesen új, számodra ismeretlen library-ra. Mennyi idő átírni a már meglévő kódot hogy az újat használja?

Példa4: webfejlesztő vagy, és a honlap, amit csinálsz, mindenhol jól jelenik meg, de IE-ben nem. Mennyi idő, míg ott is jó lesz?

Tudnék még példát írni, de remélem ennyiből is érted. Nem lehet előre látni, hány buktató és nem-egészen-úgy-működik-mint-ahogy-a-doksi-írja lesz egy implementálás során. Arra is kíváncsi lennék, hogy hogyan tudod egyáltalán előre megsaccolni, hogy hányszor kell majd hibát keresned, és hogy mennyi időbe fog kerülni egy konkrét debug. (És akkor arról még nem is beszéltem, hogy a managerek 99%-a egy büdös mukkot se ért abból, amivel az időigényt alátámasztod, ezért eleve úgy gondolják, inkább hagyjuk csak ki, mert úgyse tudná elmagyarázni a nagyfőnöknek, mi a késés oka).

Köszi. Én olyan példát vártam, hogy XXXX év XX hónap X napján a XY bíróság 3 év felfüggesztett börtönre ítélte Average Joe kódert XY foo és bar halált okozó programozási hiba elkövetése miatt. Bocs, ha volt benne ilyen, de tényleg nem volt erőm elolvasni.

--
trey @ gépház

http://en.wikipedia.org/wiki/Morris_worm
Ugyan nem volt halált okozó, viszont a hibás tesztelés miatti elszabadulása okán nyert Morris úr 400 óra közmunkát és 10kUSD büntit.

A komolyabb eseteknél ritka, közvetlenül a programozó elítélése, mert a cégük, mint jogi személy védi őket.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Szia,
Mert talán nem azt az ajtót vetted, ami direktben véd a dinamit ellen...
Egy mezei weblaptól nem várod el, hogy megvédjen a közvetlen hozzáférés problémáitól, ahogy egy OS-től sem, hogy tökéletes immunitást adjon a rajta futtatott webszerver és weblapok hibáitól...
Ugyan ez a helyzet az ajtókkal is, csak tudni kell, milyen célra veszed...
Üdv,
LuiseX

Egyesek pedig itt pont erre akarnak utalni, hogy ezeket tudnia kellene minden sw-nek :)

(Igazából a legtöbb megrendelő is kb. ilyesmit várna el, csak nincs kedve kifizetni a 10x-es összeget, meg túl késő neki a 3x akkora fejlesztési idő. Legtöbb szoftver azért is egy fos, mert általában, amikor a megrendelő kitalálja, akkor már azonnal kellene neki, hiszen egy aktuális problémára megoldás és nyilván lealkudja az időt a versenyelőny miatt.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Na igen, nehez ugy ez, mert szivem szerint azt mondanam, hogy ja, legyen felelosegvallalas! De aztan belegondoltam, tenyleg nem fair a sok pelda: egy sw-tol az ember e;varna, hogy az mindig kitart, barmi tortenik, kb akkor is, ha mondjuk a kerdeses ajto ellen egy szupernovat vetne be az ember: nyilvan nem arra keszult :) Tehat akkor definialni kene elobb, hogy az adott sw milyen korulmenyek kozott hasznalhato biztonsagosan/megbizhatoan, "latatlanban" barmilyen korulmenyek kozott nincs az az ember altal alkotott fizikai vagy nem fizikai kreacio ami barmit kiber, hiszen amit ember alkot az sose lesz tokeletes, mondhatni (plane nem ugy "barmi kapcsan") ...

Szia,
Ez már végfelhasználói hiba, de tényleg. Minden valamire is való, minőségi dokumentáció, ami komoly termékről szól, meghatározza a működés peremkritériumait, illetve a szükséges követelményeket, és definiálja a szabályszerű üzemelését is a terméknek... És ha nem is az elején, de tartalmaznia kell mindenképpen (ld. minimális/ajánlott konfig, vagy a működés definíciója)...
Az ellenben megint más kérdés, hogy a felhasználók ezt nem értelmezik, sőt, nem is olvassák el legtöbbször a dokumentációkat, hanem a tanult sémákat követve alkalmazzák a szoftvereket... Ezért él manapság, legalábbis ahol megfordultam, hogy a programozó alapból feltételezi a userről, hogy buta... Mert, másképp nem járhat el, ha gondoskodni akar a terméke működőképességéről...
De itt jelenleg, ha nem tévedek, a programozó/fejlesztő (vagy fejlesztő csapat) felelősségre vonhatóságáról van szó. Amit szerintem jogosan el lehet várni, a működési határokon belül (pl. egy TCP/IP-n kommunikáló szoftver legyen oly kedves nem elfogadni preparált UDP csomagokat egy teljesen másik porton, mint ahol figyelne hivatalosan...)
A fejlesztőket, tesztelőket, meg akikre minden egyebet, ami a termék egészének elkészültéért felelős, ezek után kell megítélni... Ellenben, ha elfelejtették hivatalosan definiálni, mik a működési feltételek (ami sajnos manapság nem ritkaság...), az bizony megint nem felhasználói hiba...
Üdv,
LuiseX

Itt biztonságról van szó, az meg elég egyszerüen definiálható: hozzáfér-e a támadó olyanhoz, amihez nem lenne szabad. A biztonsági működési feltételeket meg egyszerüen nem tudod lekorlátozni a szerzödésben (pl tilos sql injectiont alkalmazni), mert nagyon hangosan kiröhögnek. A támadót ugyanis nem igazán fogja édekelni a dokud, meg a szerzödésed. Ellenben egy ajtógyártónál mindenki egyértelmünek veszi, hogy bizonyos dolgok ellen nem fog megvédeni a terméke, pl ha egy T-72-es simán átmegy rajta, attól még az teljesen jó lesz a lakásba bejárati ajtónak. Szoftvernél ilyen nincs, mert tankot elég nehéz szerezni és betörésre használni, de ha kikerül egy exploit a szoftveredhez, legyen akármilyen bonyolult az elsö megírása, akkor onnantól a többi potenciális támadónak már csak Ctrl+C Ctrl+V a megszerzése, és a használata is két kattintás.
Ha lennének kártérítési perek biztonsági hiányosságokért, akkor nyilván csak a garantált 100% biztonságú szoftverek készülnének el, darabszám szerint pontosan nulla.

Szia,
Azért nem ennyire triviális, hogy nem létezik 100%-os biztonságú szoftver... De kérdés, minek akarsz megfelelni? Egy biztonsági rendszer, ahogy az ajtó is idővel korrodál, veszít védelmi értékéből,csak az ajtó esetén triviális, hogy idővel kevésbé lesz ellenálló.
És simán, probléma nélkül fizetünk az asztalosnak/ajtókreálószakmesternek, hogy javítsa az ajtónkat, akkor miért nehéz ezt applikálni a szoftver piacra is?
Bocs, sarkára fordítottam, de lényegében így kellene értelmezni, amire szerintem utalni próbálsz, mármint, a szoftver természetes korróziójának, pontosabban, annak részeként (ugyebár az architektúra is változik alatta előbb utóbb, és minden, ami körbe veszi... Egyetlen ajtó sem bírná ki ezt a fajta terhelést, erre mérget vennék).
De nem is vár el senki, szerintem legalábbis, tökéletes programokat, hanem azt, hogy vállalja a hibáiért az érintett fél a felelősséget... Például, az egyszerűség kedvéért, vegye a fáradtságot, és javítsa ki.
Ne új feature-t fejlesszen, hanem csak korrigálja a korábbi hibáit, tévedését. Mert, mindenki hibázhat, és ha van lehetőség, illendő minőségi munkát kiadni, ha nincs, akkor utólagosan tenni érte, hogy kijavítsa...
Am. a szoftver minőségért épp a programozók tehetnék a legtöbbet: Annyi pénzért, amennyiért most fejlesztenek, és annyi idő alatt, amennyit kapnak, szimplán _nem_ vállalják el a munkát... Persze, erre jönne a sírás, hogy "de meg kell élni..." és "más akkor megcsinálja..."...
Amíg viszont ezt nem lépik meg az érintett felek, én azt kell mondjam, szimplán nem veszem komolyan ezeket a mondatokat. Saját fejlesztéseim során egyrészt az idő paramétert úgy határoztam meg, hogy tudjam az általam elvárt (nem a felhasználó, hanem saját magamtól elvárt) normát teljesíteni. Amennyiben ez a megrendelőnek sok volt, szépen elköszöntem... (megint sarkítva, de mindig felmértem inkább a szükséges időt, mintsem belefussak abba a hibába, hogy tákolnom kelljen... Ha csúsztam, akkor sem tákoltam eddig egyszer sem. Inkább leégett az arcomról a bőr, de több időt kértem, és/vagy kár térítettem...)
De, lehet, bennem van a hiba, hogy a szakmámban egyfajta becsületre alapozok, s végül az itt látható érvek a helyesek (az idő/pénz/megamásikakimegcsinálnáhelyettem)... Akkor azonban, sajnos azt kell mondanom, rossz szakmát választottam... De ezt az idő mondja majd meg...
Üdv,
LuiseX

Nem triviális, de jelenleg ez a gyakorlatban nem igazán bizonyítható, tehát aki leteszi a nagyesküt, hogy az övé 100% bugfree, valószínüleg hazudik.
Itt felelösségrevonásról van szó, konkrétan arról, hogy kártérítést kellene-e fizetni a biztonsági bugokért. A frissítés, bugfix kiadása többnyire természetes, és legtöbbször pénzbe sem kerül (nem úgy, mint az asztalos), bár mi van akkor, ha mondjuk lejárt a szerzödésben vállalt támogatási idöszak? Akkor is ingyen javítani kell az idök végezetéig?
A szoftver nem rohad meg állásában, ha valamikor kiderül benne a bug, akkor az már az elkészültétöl benne volt. És ahogyan már korábban írtam, ajtóknál tudsz válogatni a minöségi kategóríáknál, de ha egy szoftverben csak egyetlen lyuk is kiderül, akkor onnantól az jár át rajta, aki csak akar, tehát 0% a biztonsága. Amíg nincs objektív általános kódellenörzés, addig a garantált 100% biztonság csak egy megfizethetetlen álom marad, akármilyen alapos is az ember. Vagy alternatívaként elfogadjuk, hogy bugok elökerülhetnek, és OK, fizetünk kártérítést, de a mértékét korlátozni kell, és a szoftver árát is annak megfelelöen fogjuk megszabni. Tehát ugyanazt adjuk, mint eddig, csak pár nullát még az ár végére kanyarítunk. Ez szerinted jó lenne?

"A szoftver nem rohad meg állásában, ha valamikor kiderül benne a bug, akkor az már az elkészültétöl benne volt."
Oprendszer vagy egyéb szoftver frissítése is simán okozhat hibákat. Ezért is nem támogatnak egy szoftvert a végtelenségig.

"ha egy szoftverben csak egyetlen lyuk is kiderül, akkor onnantól az jár át rajta, aki csak akar, tehát 0% a biztonsága."
Nem igaz. Sok esetben más óvintézkedésekkel megkerülhető a probléma.

Sziasztok,
Igen-t szavaztam, s leginkább amiatt, mert egy programozó legalább annyira felelős az általa kiadott kódért, mint pl. az ács a tetőszerkezetért, vagy autószerelő a kocsiért, amit javított...
Talán még jobban is, ha csak olyan kis dolgokra gondolunk, mint egy repülőgép irányító rendszere,Paks vezérlő rendszere (ez most csak egy elvakult példa, de talán elég érzékletes), vagy mondjuk egy bank háttér rendszere...
Természetesen ilyen esetekben is figyelembe kell szerintem venni a körülményeket, s az alapján megítélni, miért is következett be a hiba, mint bármely más esetben...
De alapvetően úgy érzem, a programozó felelős az általa kiadott kódért, ahogy mesterember a munkájáért...
Üdv,
LuiseX

Szia,
Persze, ahogy egy repülőgép irányítórendszerét teljesen más technológiával ellenőrzünk, mint egy tetőszerkezetet, s ahogy egy repülőgép irányítórendszerét jobban koordinált csapatnak kellene fejlesztenie, mint egy tetőt.
Mert, mások a kritériumai, de mégis egyben hasonlóak: Mindkettő termék, aminek a minőségéért az azt fejlesztők/alkotók/teremtők/akármik a felelősek. Legalábbis addig, hogy standard üzemi környezetében (amit feljebb is írtam, definiálni _kell_ ) tökéletesen működjön, és az elvárható (esetleg pontosan definiált) környezetben ne is térhessen el az általános üzemi működésétől.
Csak ebben az esetben a tető amiatt jó példa, mert kézzel fogható termék, aminek jól definálható a funkcionalitása is... Ez utóbbiban pedig eléggé hasonlít a sw-re is, az előbbi pedig a szükség szerű elvárások képiesítését szolgálja csak, pont ezért csak hasonlatként volt jelen, nem pedig 1-1 ekvivalens megfeleltetésként :)
A felelősség, ami ezekhez megalkotásával jár, arról pedig szerintem belátható, hogy mindkettőben eléggé jelentős (pl. ha a déli vagy mondjuk a nyugati pályaudvar tetőszerkezete leszakadna, az szerintem bőven felérhet egy repülőgép katasztrófával is... Persze ezek nem ács munkák, de teszem hozzá, egy repülőgép irányító rendszere sem átlagos programozói munka...)

Összefoglalva: Szerintem igen is felelősséggel tartozik mindenki a munkájáért, szakmától, kortól, nemtől, fajtól függetlenül. És ez alól a programozó sem kivétel, csak ugyanúgy, mint másnál, figyelembe kell venni az ő hatáskörét a termék kapcsán. Ahogy azt is, hogy feltehetőleg a terméken egy csapat dolgozott, tehát annak egészéből kell kiindulni, hogy hol csúszhat be az érintett hiba...
Ha ez a megközelítés működik egy gyártó sor mellett álló munkacsoporton, nem tudom elképzelni, hogy lehetetlen implementálni az informatikában... Csak, sajnos mindenki szeret/szeretne kicsúszni a felelősségi körből, is inkább a másikra mutogat, hogy márpedig ők is hibáztak...
Üdv,
LuiseX

Igen. Mert van egy rövid fejlesztési tapasztalatom ExtremeProgrammig "metódussal", aminek az eredménye mindenki számára megdöbbentő tisztaságú, gyorsaságú és gyakorlatilag kódolási hiba mentes programot eredményezett valamivel több mint a tervezett fejlesztési idő fele alatt...

(És egy kicsit "nem", mert ha egy környezetbe kell belefészkelődni, akkor a környezet hibáin csak az üzemeltetési doksiban lehet uralkodni - ha lehet egyáltalán.)

A linuxot amatőrök vagy profik fejlesztik? Linux esetében a hibái miatt felmerülne kártérítési igény vagy sem? Dokumentáció, kódtesztelés a linuxnál rendben van? Akkor most komoly project a linux vagy sem?
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ha baleset történik, ott valaki hibázott (hiszen a szabály az, hogy nem szabad balesetnek történnie), a kérdés csak a felelős személye.
A félreértés ott van köztünk, hogy szerintem a hibák ritkán keletkeznek semmiből. Ha leegyszerűsítjük, akkor egy szoftverhiba lehet szándékos, gondatlanságból elkövetett, vagy a mágneses vihar átfordított egy bitet. Más variációt egyszerűen nem látok. Az első és a harmadik remélem nagyon ritka, tehát mondjuk a hibák 99%-a gondatlanságból elkövetett, valakin, valakiken elméletben leverhető. A szakértő itt is max a konkrét felelős megállapításában vehetne részt. A kérdés az, hogy ezt szeretnénk-e.

Persze, hogy felelősségre. Lehet, hogy ingyen dolgozott egy nyílt forrású projekten. Ültessük le, mit képzel ez magáról.

Hülyeség az egész kérdést így általánosságban feltenni. Inkább abban az irányba kellene elindulni, hogy legyenek-e komolyabbak a szoftverfelhasználói szerződések, és legyen-e több joga a felhasználóknak. Erre igent mondanék, de ez így egy hatalmas NEM.

Szerintem nem róható fel gondatlanság annak a fejlesztőnek, aki tisztában volt azzal, hogy amit csinál a problémás, azt jelezte és azt igazolni is tudja. Erről szól a gondosság. Gondoskodott arról, hogy a felettesei tudomást szerezzenek arról, hogy amit elvárnak tőle, az nem helyes. Tehát, te itt megint másról beszélsz.

--
trey @ gépház

Többnyire mindenki felismeri, hogy tökéletes munkát senki sem képes csinálni, és ezt le is írják a doku, liszensz azon részében, ahol az ilyen irányú felelősségek elhárításáról van szó. Ott jelzik, hogy amit csinál az problémás lehet. Minden szoftvernél. Így a felettes és a felhasználó is értesítve van a tényről, hogy a fejlesztő is ember, és mint ilyen, esendő.

"s ezt le is írják a doku, liszensz azon részében, ahol az ilyen irányú felelősségek elhárításáról van szó."

Pont ezt szeretnék megszüntetni.

"Így a felettes és a felhasználó is értesítve van a tényről, hogy a fejlesztő is ember, és mint ilyen, esendő."

Ez így van, de más szakmákban nem mentesül az ember az általa végzett munka közben elkövetett gondatlanságért. Vagy tudsz még egy szakmát mondani, ahol elnézik a szar munkavégzést arra hivatkozva, hogy "hagyd, ő is csak ember?". Szerintem nem azt szeretné Clayton, hogy a gondatlan programozót akasszák fel, hanem azt, hogy az általa okozott kárt térítse meg, vagy vállalja a következményét a munkájának.

--
trey @ gépház

Ha elmész orvoshoz, felelősséget vállal azért, hogy amit felír, az hatni fog? Hogy 5x egymás után felír krémet lábgombára, miközben ekcéma? Vagy hogy a dió méretű daganatot nem veszi észre? Lehet, hogy észre kéne vennie, mégsem vette, mégis azóta is ott dolgozik

---
Ubuntu one tárhely: https://one.ubuntu.com/referrals/referee/1503/
Dropbox: http://db.tt/XMk0ssk

nem feltétlenül arról beszélek, ha meg is halsz, én még nem haltam meg, de minden második orvoslátogatásom alkalmával hibás az eredmény, és csak azért ilyen jó az arány, mert a másik fele megfázás vagy allergia gyógyszer
---
Ubuntu one tárhely: https://one.ubuntu.com/referrals/referee/1503/
Dropbox: http://db.tt/XMk0ssk

Szerintem ez egy komplex kérdés.

Amikor a programozó egyszemélyes cég formájában fejleszt és ő maga szabja meg a munkájának feltételeit, akkor jogosan vonható felelősségre a munkájának minőségével kapcsolatban.

Amikor a programozó csak egy beosztott és a cég diktálja a minőségi szintet különféle eszközökön keresztül (pl. határidők megszabásával, anyagi források és ezáltal alkalmazható eszközök meghatározásával, általános céges filozófián keresztül, stb.), akkor sokkal kevésbé múlik a programozón, hogy milyen lesz a végtermék minősége.

De persze bármilyen helyzetről is legyen szó, valamekkora döntési szabadsága általában van a programozónak arra vonatkozóan, hogy mennyi időt fordít hibakeresésre (tesztelésre) és javításra. Ha nem tesz meg minden tőle telhetőt a legjobb minőség elérésére, akkor az az ő sara.

Elég nehéz meghúzni a határt (főleg céges/csapat munka esetén), hogy mely esetben egy konkrét fejlesztő hibája az, ha bent maradt a kódban egy ilyen v. olyan hiba.

Ez innentől elég darázsfészek jellegű. A mindenféle linkelt könyvtárak hibáival mi a helyzet? Mi a helyzet ha a PHP kód jó, de Apache (nem is PHP, hanem Apache) hibán keresztül okoskodnak valamit még a legparanoidabb PHP beállítások mellett is?

Az pedig egy külön téma, hogy mennyire kell néha kutyafuttában "hátműködjön" megoldásokat összehozni, amivel utána senki se foglalkozik csak megy valahogy.

Adott szoftvert nem lehet kiragadni a környezetéből, hiszen hozzá tartozik az is.

Konkrét példa: kaptuk folyamatosan a panaszt, hogy lassú a rendszerünk. Egy eleve terhelt gépről futott 2x320G mezei _desktop_ diskről úgy, hogy a többi rendszer sem spórolt DB műveletekben.

Érdekes módon, átrakva másik gépre, amin nem voltak az egyéb "szemetek", egyből nem volt probléma. (Arról nem is beszélve, hogy a szerződés eleve úgy szolt, hogy dedikált gép lesz normális 10K RPM-es RAID10 tömbbel.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Biztos, hogy nem függ a kettő össze?
Tegyük fel, hogy írtam neked egy szoftvert mondjuk xp alá.
Futtattad rajta, jól működött. Lejárt a garanciális időszak, én már nem kellek. Múlik az idő, frissíted a windows verziókat, és már a W7-nél tartasz. Tőlem nem rendeltél az újabb rendszerekre való verziót.
Az elavult, de a kívánt célnak elvben tökéletesen megfelelő programom biztonsági rést okoz a rendszereden és/vagy nem működik a kért pontossági tartományban. Ebből neked károd lett.
Hibás vagyok? Mennyire?
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -> Kérjük a humoros aláírást itt elhelyezni. <- - -

Inkább olyan határeset.
Csak arra akartam rávilágítani, hogy a szoftver, és az azt futtató környezet nem idegeníthető el egymástól a felelősség teljes megítéléséhez.
Mi van akkor ha írok W8 alá egy programot, és majd W8 SP1 alatt hibássá/veszélyessé válik?
Vagy saját példámat felhozva XP SP3 net .NET3 alatt megy a ZBoardom extra billentyű kezelése, a billentyűzetpanelek on-fly cseréje, különböző játékok billentyűkiosztásának profilozása. .NET4 alatt, meg újabb wineken már nem. Ki a hibás, ha nekem még a hardver garanciás, de a gyártó már nem támogatja? :)

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -> Kérjük a humoros aláírást itt elhelyezni. <- - -

Az van, hogy az 5 percig tartó per - már ha a nyomozati szakasz után egyáltalán perig jutna az ügy - első percében, azután a kérdés után, hogy "felmerült-e gondatlanság az ügyben", jön egy "nem" válasz és a tárgyalást le is zárták.

Tedd már meg, hogy elolvasod lassan az eredeti kérdést...

--
trey @ gépház

Majd ha a szoftver felhasználó profitjából is arányosan részesedik a szoftver előállítója, akkor jogos lesz az igény, hogy az esetleges okozott kárért is feleljen. Addig nem.

Itt ha jól értem arról van szó, hogy általában véve, minden szoftvernél legyen felelősségre vonható a szoftver fejlesztője biztonsági hibáért. Ezt én csak úgy tudom elképzelni, hogyha a nyereségből is részesül, nem csak a veszteségből...

Ha a konkrét szerződésben van csak ilyen kitétel és ezt vállalta az eladó, akkor az az ő dolga. Gondolom megfizetik érte.

Egy informatikai portálon, amit sok programozó, vagy időnként programot író ember olvas az eredmény előre sejthető. Kb. olyan, mint ha az orvosokat arról kérdeznénk, szeretnék-e, hogy a műhibákért felelősségre vonják őket. Esetleg a bírókat arról, felelősségre vonhatóak legyenek-e, ha kiderül, hogy ártatlan embert ítéltek el korábban. Lehetne még sorolni a példákat.

Ettől függetlenül a szavazásnak van értelme, de a végső eredmény értelmezésénél nem szabad elfelejteni a „szavazótábor” összetételét.

-----
A kockás zakók és a mellészabások tekintetében kérdezze meg úri szabóját.

Egyéb, leírom:
Igen, amennyiben az elvárások jól definiáltak és betarthatók. Ez viszont projektenként eltérhet, mivel eltérő környezetben eltérő veszélyekre kell figyelni. Ha mindig, minden veszélyre figyelni kéne, akkor az a programok teljesítményének is ártana. A lényeg, hogy a megrendelőnek jól definiálnia kell az elvárásait.

Hat, ebbe azert igy ebben a formajaban bele lehet kotni. Peldaul nem gondolom azt, hogy a bevitt adatok ellenorzesenek benne kell lennie a specifikacioban, ugyanakkor kutya kotelessege a programozonak ellenorizni a bevitt adatokat (lasd meg: SQL injection, XSS temakore). Ha nem teszi, nem takarozhat azzal, hogy hat nem volt benne a megrendelo elvarasai kozt.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Nem értek egyet. Van ahol fontosabb a teljesítmény és a bevitt adatokat előbb kell ellenőrizni. Ha a dokumentációban benne van ez a viselkedés akkor nincs ezzel semmi gond. A hiba az ha a kívánt és a valós viselkedés eltér. Ha a kívánt viselkedés dokumentációja hiányos akkor nincs miről beszélnünk. Egészen más ez mint pl. egy villanyszerelő esetében aki előre meghatározott szabályok szerint dolgozik.

Igent választottam, de leginkább csak viccből.

A mai eszközeinkkel szerintem nem lehet bizonyíthatóan biztonsági hiba mentes programot írni. Egyszerűen nem tart ott az informatika.

Az építészettel való összehasonlítás nem korrekt: az építészet többszáz éves tudomány kialakult szabványokkal. Aki ezeket a szabványokat betartja, annak a háza nem fog leomlani és agyonütni a benntartózkodókat. Abban a pillanatban, hogy valaki tud mutatni ilyen szabványokat informatikában, be lehet vezetni, hogy a programozó feleljen a hibákért.

A probléma nem a hanyag programozó, hanem az, hogy az informatikát játszáson kívül másra is használjuk. Mert egyelőre az érettségi foka csak arra teszi igazán alkalmassá :-)

Trey, no offense, de nehez egy temaban ugy itelni, hogy nem ertunk hozza.

En sem vagyok programozo, de azt tisztan latom, hogy a gondatlansag/szandekossag az nem egy baromi nagy kapcsolo amit csak fel meg le lehet kapcsolgatni. Egy szoftver fejlesztese soran nagyon sok minden tortenik, es nem biztos, hogy teljesen egyertelmu a helyzet.

Eleve nem mindig dontheto el, hogy egy adott kodsorert ki a felelos. De ha meg el is dontheto, akkor sem biztos, hogy egy ember hibajarol beszelunk. Itt nem az van, mint az epiteszetben, hogy ha gorbe a fal, osszedol a haz. Lehet, hogy ket, egymastol tobbe-kevesbe fuggetlenul dolgozo ember munkajanak kolcsonhatasa az, ami a hibahoz vezet. Ilyenkor ki a felelos? Az egyik? A masik? Mindketto?
Es mi van az atvett, nem dokumentalt projektekkel? Rengeteg ilyen van. Mivel a kod nem dokumentalt, konnyen eloallhat olyan hiba, ami az eredeti kornyezetben nem jott elo, am a megvaltozott igenyek miatt fejlesztett uj kod elohozta a regi hibajat. Ilyenkor hol kell keresni a felelost, a regi vagy az uj csapatban?

En azt mondom: lehessen felelossegre vonni a programozot, akkor es csakis akkor ha mindenfele ketseget kizaroan valoban o a felelos az okozott hibaert/karert. Ilyen eset viszont nagyon keves lesz, a hibak tobbsege altalaban nem ilyen egyszeru.

Elmondom mi lesz ezutan: a nagykozonseg ugyanugy azt fogja erzekelni, hogy a programozok nem felelnek az altaluk okozott karokert, mert nagyon keves bizonyitott eset lesz, meg kevesebb kap nyilvanossagot. Pedig hat ugye felelossegre vonhatoak.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ezt kérdést arra az esetre kéne értelmezni amikor valaki munkavégzést átveszi.Dokumentációval,irásban,supportal stb.Ott igenis számonkérhető elvárás lenne büntethetőség.Ahol Pista báttya dobta össze programot és odadta neked hogy nah ezt használd ez jó lesz neked kvázi haveri alapon no papír no szerződés,azt hol büntethetnéd meg?:)Letagadja hogy odadta és kész.valamint ugye itt tisztában vagy hogy nincs gari rá hogy megfelően működjön.

Szia,
Bocs a kotnyeleskedésért, de... Egy programozó feleljen csak a saját kódjáért. Én azt mondom, úgy, hogy valaha ezt a végzettséget szereztem meg.
Az én feladatom, hogy az általam elkészített ( ne adj isten, általam is tervezett) kód/kódrészlet eljusson a végfelhasználási helyére, és ott végezze is a tevékenységet. Persze hibás lehet, rajtam kívül álló okokból, de pont ez miatt kell a körülményeket is nézni, nem pedig "védekezni csak".
Amennyiben nem ez lenne a feladatom, hanem, hogy x sort termeljek, ami Y feature-t megold, a megadott sablon szerint, akkor nem programozó vagyok, hanem kódoló. Akkor nem is számít mi az eredmény, de ez másik szakma...
A második esetben a csapat egésze felel a termékért, és annak minőségéért, míg az első esetben mindenki egyaránt, nem osztozva kell, hogy gondoskodjon róla. Az első esetben az a dolgom, hogy elkísérjem a kódomat, ezzel másfajta kvalitást adjak, és az én felelősségem, hogy végigküzdjem, hogy működjön... Ezért vesznek fel programozónak, hogy mindent megtegyek a saját feladatomért...
A második esetben természetes, hogy nem felelek, mert nem is láthatok bele a folyamat többi elemébe, nekem csak x sor minőségét kell garantálnom, amiről eleve megmondták, miképp kell annak lennie...
Természetesen, ezeket figyelembe kell venni, és eszerint értékelni, hogy ki a "programozó". Tekintve kóderek esetén a tervező részleg és a kódoló részleg _egésze_adja_ azt a felelősségi kört, amit különben 1-1 programozó képviselne...
De igazából, ez már abból is ered, hogy a két feladatkör más-más piaci igények kielégítésére szolgál :)
Üdv,
LuiseX

Bakker, programozók között dolgozok, ez a szakmám.

Egy kód jósága és elfogadhatósága marha nehéz kérdés. Szakértő nem tudja megítélni, ha nincsennek szabványok, aminek meg kell felelni...

Ki mondja meg, hogy ezért a kódért börtön jár-e, vagy pedig nem?

void fn(const char *str) {
char buf[200];
sprintf(buf, "%s", str);
..

Írok egy GPL webszervert. Abban oké.
Írok egy lib-et automotive-ba. Akkor viszont hiba esetén tejelnem kell, mihelyst bebizonyosodik, hogy emiatt kell visszahívni a Toyotákat. Ez a mai valóság. Az oka pedig az, hogy az automotive-ban a megrendelő előírt bizonyos szabványok betartását, amiknek ez a kód nem felel meg.

A felelősségre vonhatásnak feltételei vannak. Pl. megfelelő módszertanok és nyelvek használata. Mondjuk ADA.
Az autóiparban erre találták ki a Misrát. Akinek van tapasztalata vele, az tudja mennyit ér. Ér valamit, ha jól használják.

Szóval, ha a szoftvert úgy vetted, hogy ezeket mind előírtad a fejlesztőcégnek, akkor ezek nem betartása manapaság is okozhat kártérítési pereket.

Jogi értelemben mindkettő az.
Gondatlan az, "aki előre látja magatartásának lehetséges következményeit, de könnyelműen bízik azok elmaradásában. Úgyszintén az is, aki e következmények lehetőségét azért nem látja előre, mert a tőle elvárható figyelmet vagy körültekintést elmulasztja."

Látszik, hogy nem fejlesztesz. Amikor jön az ügyfél, hogy "nem érdekel, hogy mennyire szar, két hónapig kell működnie, nem ér annyit, hogy vesződj vele", akkor mi van?

És az a helyzet, hogy sokszor a megrendelő nem akarja kifizetni a magasabb minőségbiztosítást (már csak azért sem, mert akkor már nem érné meg).

És akkor tegyük hozzá: általában így is mindenki túl drágának tartja a szoftverfejlesztést.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem egészen.

http://hu.wikipedia.org/wiki/Sz%C3%A1nd%C3%A9koss%C3%A1g_%C3%A9s_gondat…

Gondatlanságnak létezik tudatos formája és hanyag formája. A tudatos tudja, hogy itt valami probléma lehet, csak bízik abban, hogy nem lesz belőle baj. A hanyag pedig nem látja, hogy baj lehet abból, amit csinál (nem elég körültekintő). De attól még gondatlan.

+1. Ugye elkészül az x funkcionalitású szoftver valamilyen programozási nyelven (A), lefordításra kerül egy fordítóprogrammal (B), használ mások által készített eljárásokat (C), használja majd a futtatókörnyezet/operációs rendszer szolgáltatásait (D), adatokat cserél más szoftverekkel (E)... satöbbi.
Egy hiba esetén az A...E komponensek közül melyik, mennyiben felelős a hiba bekövetkezéséért, illetve annak káros hatásáért? Oké, a szagértők, meg a jogászok jól el tudnának rajta élősködni vitatkozni, de hogy komplexebb rendszer esetén ez sokáig tartana, és sokba kerülne (és akinek több pénze van, annak lenne igaza), miközben a szoftverek minősége nem igazán javulna - mert az árban azt a tesztelést, illetve bizonyítottan helyes működést senki az égadta világon nem fizetné meg.

Ez nem ilyen egyszerű. Szerintem ez nem igen/nem kérdés. Ugyanis:
Egy szoftver fejlesztése során (normál esetben) nem csak egy/több fejlesztő dolgozik egy projecten, hanem tesztelőkön (automata és humán) keresztül megy a fejlesztett termék. Egy fejlesztés során elkerülhetetlen, hogy maradjanak hibák (akár biztonsági rések is), mivel normál esetben a fejlesztő maga (is) teszteli a kódot, de nem tud minden lehetőséget lefedni, mert 1. az képtelenség, 2. pl. nem szerepelt a specifikációban, 3. eszébe sem ju, hogy ilyen hiba felmerülhet. A fejlesztő, a felhasználó és a hekker gondolkodása mind-mind különböző, ezért ami az egyiknek szébe jut, kézenfekvő, a másiknak lehet, hogy pont nem. Ezen felül az is lehetséges, hogy pont az automata tesztelő program nem találta meg a hibát, mert abban is van valami hiba, azt is emberek írták és a humán tesztelés során pedig (megbízva az automatában) csak speciális esetek tesztelése zajlik. Ekkor ki a felelős? A külső cég, aki az automata tesztet írta? Vagy ha belső tesztelő program, akkor egy másik fejlesztő, aki az adott kódhoz nem is nyúlt, csak a tesztelőt írta? Ez sokkal szerteágazóbb probléma.
Véleményem szerint egy fejlesztés esetén egy teljes csapat munkájáról van szó (fejlesztők, tesztelők, managerek) és az ö teljes munkájukat kell venni. Ezen az alapon azt kell, hogy mondjam, hogy a cégnek kell kiálnia és nem egy-egy embert pellengérre állítani egy ilyen esetben. Természetesen az adott hiba tényleges okát, illetve, hogy miért maradt/került be a kódba a hiba, azt ki kell dferíteni és a oflyamaton javítani, de ez már belső ügy.
Ez alapján nem tudok sem a nem-re, sem az igen-re szavazni. Nem fekete/fehér a világ.

Abban az esetben ha ingyenes a cucc és open source akkor nem igazán lenne jogos szerintem.
Amennyiben - akár ingyenes / akár fizetős - closed source ki mást terhelne a felelősség ha nem a fejlesztőket?

Úgyhogy simán.

Üdv. bnv

Hm, lássuk csak:
- A tesztelőt, aki nem vette észre a hibát
- A managementet, aki asz ésszerűtlen határidők vállalásával nem hagyott időt rendesen letesztelni a software-t
- A megrendelőt, aki rosszul specifikálta a funkciót vagy a use case-t
- ...

Azt értsétek meg, hogy egy szoftver fejlesztésnek a kódolás egy rövid szakasza, és a fejlesztési ciklusban bárhol lehet hibát elkövetni. Sőt, lehet rossz akár a fejlesztési módszertan is, vagy a management döntések vagy a minőségbiztosítási rendszer. Akkor miért a fejlesztőt kellene felelősségre vonni mindenért? Ha egy súlyos probléma előjön, akkor lehet elkezdeni feltárni az okokat, és majd ki fog jönni, hogy ki/mi volt a hibás. De szint biztos, hogy a legritkább esetben lesz egy ember a felelős.

Ha egy villanyszrelo gany munkat vegez es ez valakinek az eletebe kerul, akkor bizony felelossegre vonjak (esetleg azt is, aki atnezte a munkajat). Ez a felelosseg tudtommal szemelyes az o eseteben. Meg inkabb, mint egy orvos eseteben. Ha egy villanyszerelot a szabalyok megszegesere kenyszerit a munkaadoja, a torveny ot arra kotelezi, hogy eluasitsa a hozza nem erto fonoke kivansagat. Ha megis teljesiti, akkor o a felelos nem a fonoke. O az a kepzett ember, akinek el kell tudnia donteni, hogy a megoldas megfelel-e a szabvanyoknak. Legalabbis errefele ez a modja. Persze lehet alacsonyabb kepzettsegu villanyszerelo, de akkor az o munkajaert egy masiknak kell felelosseget vallalnia.
Egy auto vezetojenek is ismernie kell a szabalyokat. Ha a fonoke arra utasitja, hogy 150-el hajtson kozuton, azzal meg nem vallalja at a felelosseget ezert a tettert. Az, hogy ez nem igy tortenik egy szomoru dolog. Ha senki sem felne elutasitani az ilyen utasitast a torvenyre hivatkozva akkor egy ido utan nem akadna fonok, aki erre utasitja az embereit.
Egy orvost szemelyesen is felelossegre vonhatnak, ha hanyagsagbol okozza a paciense halalat vagy ront az allapotan. (pl. a sebesz benne felejt egy torlot a beteg mellkasaban) De sokszor megussza, ha csak rossz diagnozist allitott fel. Valamiert a biztosito sem varja el tole, hogy az osszes lehetseges vizsgalatot elvegezzen minden betegnel.
Az elso kettonek a kezeben vannak a pontos szabalyok es szabvanyok. Az orvosnak szamara mar nincsenek ilyen egyertelmu szabalyok, mert olyan komplex problemakat kell oldania, amit nem lehet leirni. Raadasul az ot tamogato tudomanyag is sokkal dinamikusabban fejlodik, mint pl. az epitkezesi ipar.
Hol van itt a programozo es milyen szabalyokat kellene betartania, hogy vedve legyen?

Na ezaz, szoftverfejlesztés esetén milyen szabványokról beszélünk? Ami "szabvány" van, az is jellemzően egy-egy ökoszisztéma konvenciói, best practicei, ajánlásai, amelyet egy cég vagy egy közösség hoz létre. Ráadásul ezek nagyon sok más - akár gyökeresen eltérő - rendszerekkel kell együttműködniük.

Nincs ilyen, hogy ezt csak így csinálhatod, mert ez a szabvány.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A villanyszerelőt vs programozó hasonlat rossz, mivel egy programozó sokkal
nagyobb állapottérben dolgozik, ezért sokkal-sokkal nagyobb a hiba lehetősége,
viszont sokkal diverzebb dolgokat is tud csinálni. Villanyszerelőnél megvannak
a nagyon egyszerű best practice-ok, és bevizsgálat alapanyagok, ha ezeket rakja
össze adott séma szerint, akkor garantálva van, hogy nem lehet probléma. Na,
ez nincs az info-ban.

Nézzünk egy banki szoftvert, amit elszúr a fejlesztő, és ezért becsődöl a bank. Jogosnak tartom, hogy a fejlesztő a saját díjazásának nagyságrendjéig feleljen a kárért. Nyilvánvalóan nem reális viszont, ha milliárdos kárt akarnak a nyakába varrni.
--
ulysses.co.hu

Nem, mert ebben az esetben tíz évente jönne ki friss verzió egy szoftverből, és megfizethetetlenül drága lenne.

És a projektmenedzsert? Az ügyfelet? Amennyiben korbáccsal hajtották a programozókat, lealkudták hugyért-szarért munkára az összeget, és fele programozót állították rá a projektre, korábbi insecure rendszerekhez kellett a fejlesztés során csatlakozni, stb.
Millió eset lehet, ahol nem a fejlesztő a balfasz, hanem mások, vagy együtt mindenki. Ezt egyedül fejlesztőre verni picit felelőtlenség... Angol tudós.... Úgy látom beszabadultak a nevesebb helyekre is. Bár itthon is megkapják már a szakmához nem értők is a doktorit, meg diplomát.

Azzal egyetértek, hogy lépni kellene az ügyben, mert egyre több a rossz minőségű szoftver. Ami ha anyagi kárt nem is, de elpocsékolt időt és bosszúságot biztos okoz a felhasználójának.

Viszont nem a programozót, hanem a céget kellene felelősségre vonni. A konkrét hibáért felelőst (programozó, tesztelő, rossz céges policy stb.), vagy felelősöket pedig majd házon belül lerendezi a cég.
A biztonsági hibákat már más kalap alá venném, mivel itt nem rendeltetésszerű használat esetén a támadó okozza a kárt. Vagyis a támadót kellene büntetni, hiszen nélküle nem merült volna fel a hiba. Illetve a cég akár önként (plusz pénzért, bizonyos feltételek teljesülése esetén stb.) vállalhatná a felelősséget a biztonsági hibákért is.

Páran írtátok, hogy a szándékosságtól, hanyagságtól meg szakértőktől kéne függővé tenni a felelősségre vonást. Ezt gyorsan el kéne felejteni, mert akkor az egész szubjektív véleményen alapulna és a lassú jogrendszernek és a bírók ítélőképességének lenne kitéve. Én nem szeretnék éveket várni egy-egy ítéletre. Meg a szakértők sem tudnak abszolút igazságot képviselni, hiszen egy problémának több megoldása is lehet és ezek elemzése messzire tud vezetni. A kártérítés megállapítását se bíznám a bíróságra. Inkább úgy tudnám elképzelni, mint egy biztosítást: tételesen fel van sorolva, hogy milyen esetben mennyi jár. Te mint felhasználó mondhatod azt, hogy akkor én az X helyett Y szoftvert veszem meg, mert az többet fizet kár esetén.

-=ElveteMedve=-

Szia,
Szerintem nem kártérítésben, meg elítélésben kellene gondolkozni, hanem felelősség körben, s a megszabott felelősségi kör nem teljesítéséről...
Egy programozó, "programozó", kódoló, vagy "programozó csoport" teljesítse a munkáját a megfelelő körben. Amennyiben probléma van, annak megfelelően járjanak el, és annak megfelelően intézkedjenek. Ezt igazából nem perre kell vinni, hanem a felelősségnek megfelelően kiértékelni az ember/emberek munkásságát...
És, ha tényleg mulasztanak, akkor kell felelősségre vonni, mert a saját munkakörében, a legjobb lehetőség szerint senki se kövessen el mulasztást. Se egy orvos, se a kőműves, se az autószerelő...
Természetesen lehetnek hibák, és semmi sem lehet tökéletes, de ezt nem is kell/szabad elvárni. Csak azt, hogy mindenki becsületesen végezze a munkáját, és ne csak tákoljon valamit, amire ráfogja, hogy munka:)
És ez a szemlélet, ami szakma független kellene, hogy legyen...
Üdv,
LuiseX

Na ez az, de mi számít mulasztásnak? Ezt nagyon nehéz kitalálni. Nem gondolt valamire a fejlesztő? Mint már bemutattuk többen, akkor az állapottér, amiben dolgozni kell, hogy lehetetlen, hogy mindenre gondoljon. Hogy szándékosan hagyott benne hibát? Nem igazán bizonyítható. Hogy hanyag volt? Adott időn belül, adott pénzért kell a lehető legjobb szoftert elkészíteni. Nem hibátlant, hanem a lehető legjobbat. Ebben benne van, hogy hibák vannak benne, amiket javítani kell. Ennél többet akkor lehet igérni, hogyha nagy biztonságú szoftvert fejlesztünk, de akkor annak az ára is sokszorosa egy hagyományos termékének..

Szia,
Természetes, hogy nem egyértelműen definiálható. De egy programozót csak egy programozó tud megítélni, szakmailag, ahogy tesztelőt is csak egy tesztelő... Gondolom ezt nem kell túlmagyaráznom :)
És azt sem szabad elfelejteni, hogy egy terméket úgy adsz ki, legalábbis, ha minimális minőségre is törekszel, hogy definiálod, milyen feltételek mellett is működik... Ne adj isten, még rendes dokumentációt is készítesz, nem csak feljegyzéseket, és screenshotokat, hogy hova kell kattintani, egy-egy funkcióért (rendes dokumentáció elég sok mindent tartalmaz: Termék specifikáció, fejlesztői dokumentáció(ha szükséges), működési feltételek, speciális követelmények, ismert hibajelenségek/azok megoldása(akár külső eredetű hibák, pl. hogy a hálózat nem elérhető...), hibajavítási útmutató, bugreport specifikáció, és mindemellett, mellékesen egy user manual is... Legalábbis, én csak ezek jelenlétében mondtam azt eddig, hogy a termék dokumentálva van...)
Nem is a szándékosságát kell vitatni a dolognak, hanem, hogy megtett-e minden tőle telhetőt, hogy a termék megfelelő legyen...
Ahogy a csapat minden tagjára igaz...
De egy programozó csak a saját hatáskörében értékelendő, ahogy a többi csapat tag is.
Egy hiba megjelenéséért, ha konkrétan nézzük, legalább 2-en felelősek: A programozó, és az azt tesztelő... De ezt vagy megfelelő szakmai képzésű szakértő tudja pontosan megítélni, vagy maga a csapat...
Szerintem itt az a legnagyobb gond jelenleg, hogy fejlesztőkre mint egyetlen, vagy több emberből álló kódoló csapatra gondolnak csak többen is, és nem a termék elkészítéséért egészében felelős csapatra...
De abban egyetértek, hogy nem lehet a lehetőségek miatt hibátlan szoftvert készíteni. De senki nem is várja el :) Csak azt, hogy a megadott feltételeken belül működőképes legyen, vagy ha nem, és a környezetét tekintve lehetséges. akkor gondoskodjunk róla, hogy azzá váljon, ha kell és van is rá mód, utólagosan...
Mert, SW esetén azt jelenti a felelősség, szerintem, hogy nem hibátlan, hanem törekszik a hibák elkerülésére, vagy azok javítására mind a fejlesztő, mind az általa generált termék :)
Üdv,
LuiseX

Csak azt az esetet lehet mérlegelni ahol, pénzért, megrendelésre készítenek szoftvereket.
Ott van egy minőségbiztosítási procedúra(jobb helyeken) és az alapján lehet a feltárt hibát számon kérni. Amúgy meg, mind emberek vagyunk és hibázhatunk. Ezért van tesztelés, ezért van folyamatvezérlés a normális cégeknél.
Tehát a véleményem, az, hogy igenis mindenki felelős a munkájáért és azért, hogy azt a lehető legjobban végezze el.

Nem-re szavaztam, mert a felelősség kérdését a fejlesztő/felhasználó közötti alku szerződés dönti el szerintem (ez lehet GPL, kerskedelmi BSD..... amibe az ügyfél belemegy) ha ebben benne van a felelősségvállalás, akkor úgy lesz.

Ezen az alapon miért nem vonják felelősségre a receptoldalakat, mert egy mogyoróssüti megevésébe simán bele lehet halni, ha allergiás vagy.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

gányolásért -> halál :D
SQL injection és más hasonló programozói hibákért -> börtön / munkatábor :))

Lehet ilyen esetre vmilyen felelősség biztosítást kötni?
Ha igen, vajon hány cég él vele?

De amúgy hogy is van ez most a kapitalizmussal? Nem úgy van, hogy ha van rá kereslet és alapvetően nem észbontó baromság, akkor lesz kínálat is?

Pedig ESR megmondta, hogy nem pereskedni szeretnének az emberek, hanem hasznos szoftverekhez jutni.
Egyébként: nem, akinek meg ilyen igénye van, az vegyen olyan szoftvert, amire garanciát vállalnak.

--
http://neurogadget.com/

Talán a másik oldalról is meg kellene vizsgálni a dolgot, a fogyasztó oldaláról. Kicsit olyan ez a helyzet, mintha azt mondanák, "tiltsák be az összes Kínai terméket, mert azok gagyik". Lehet ez mellett jó pár érvet felhozni, mint az adott témában is, de lássuk be, van igény a gagyira, és van igény az olcsó szoftverre is.
Legjobb tudomásom szerint az informatika is azért tudott elérhetővé válni a hétköznapi emberek számára, mert a szoftverekkel szemben kisebb elvárásokat támasztottak és így megfizethetővé vált a nagyrendszerekkel szemben. A Windows előtt is volt élet, csak nem a hétköznapi emberek számára. Hányan használnának ma számítógépet, ha egy egyszerű otthoni gépre is enterprise/gold support/... verziót kellene megfizetni?

Csak a szokásos mondás jut eszembe: "Jót, gyorsan, olcsón. Ön ebből kettőt választhat."

Hogyan szokták ezt mondani a YouTube-on? 88 programozónak nem tetszik a szavazás? :D

--
trey @ gépház

Figyelj... lehet nem lenézned kellene a programozókat, hanem megmutatnod, mi is lenne az egy igaz út. :)

Addig könnyű a partvonalról okoskodni, bár szerintem pontosan tudod jól, hogy kit mikor hogyan és miért vonnak felelősségre.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Van olyan mondás is, hogy "Magyarországon mindenki ért a focihoz". Most ebben a szerepben véllek felfedezni, mivel sohasem tanultad, de nagyon értesz hozzá. Nyilván ezt a kérdést azok tudják legjobban eldönteni, akik értenek hozzá.

Több dolog nem világos abban, hogy miért szeretnéd ennyire felelősségre vonni a programozókat:
1. Általában egy program elkészültéhez nagyon sok ember együttműködése szükséges, közülük miért pont a programozókat kellene felelősségre vonni? Ha más szakmabeli hibázik, akkor azokat nem kellene?
2. 1. pont tovább gondolása. Miért pont csak a programok hibája miatt kellene felelősségre vonni embereket? Miért ne lehetne ezt tetszőleges szakmára kiterjeszteni?
3. Miért nem tartod jónak a mostani helyzetet, hogy a cég felel az általa létrehozott, terjesztett programokért?
(Megjegyzés: Magyarországon a kártérítés elől nem lehet szerződéssel (licencel) kibújni. Ha kár ér, akkor bíróságon ennek megpróbálhatsz érvényt szerezni, akkor is, ha a szerződésben más van. Bár ennek a bizonyítása a legnehezebb dolgok közé tartozik, ezért is nagyon ritkák a kártérítési perek)
5. Milyen felelősségre vonást gondoltál? Tegyék ki a nevét fekete listára, ne vállalhasson munkát adott ideig, pénzbüntetés (mekkora?), vagy ott helyben kövezzék halálra?
6. Támogatnád-e a felelősségre vonást akkor is, ha ez után nem lennének elérhető áron szoftverek, ami magával vonná azt is, hogy gyakorlatilag semmilyen "okos" kütyű sem lenne, mivel azok is tartalmaznak programokat?

"mivel sohasem tanultad,"

Nem mintha számítana, de ezt honnan vetted?

A többi kérdésedre kérlek olvasd el az első hozzászólást. Úgy kezdődik, hogy "Dr. Richard Clayton, a Cambridge Egyetem biztonsági kutatója szerint". Az úriember vetette fel a kérdést. Engem meg az érdekelt, hogy itt mit gondolnak róla az emberek.

Ami engem ebből a témakörből egyedül foglalkoztat, csak annyi, hogy miért gondolják a programozók, hogy ők nem felelősek a tróger munkavégzésért.

A szavazás állása szerint nem vagyok egyedül a véleményemmel. A szavazók közt programozók is feleltek "igen"-nel. Erre varrj gombot.

--
trey @ gépház

"Nem mintha számítana"

Szerintem párszor már kitárgyaltuk, könnyű más farkával verni a csalánt.

"ők nem felelősek a tróger munkavégzésért."

- Figyelj kellene egy ilyen tegnapra
- De...
- Nem érdekel a de, legyen meg tegnapra.

Egyébként egy szóval nem mondom, hogy egyesek nem felelősek a tróger munkájukért és nem is igazán a biztonsági hibák itt a kérdésesek. Csak amikor néha egyesek irreális elvárásokat követelnek, nehéz jó munkát végezni.

Az egészben számomra csupán annyi a zavaró, hogy előszeretettel savazod a programozókat úgy, hogy fittyet hánysz a körülményekre.

"A szavazók közt programozók is feleltek "igen"-nel. "

A probléma az, hogy te most itt az egész szavazással a programozók nyakába akarod varrni a dolgot. Holott tudod nagyon jól, hogy a cégek szokták tartani a hátukat (már, ha erre volt előzetes igény a szerződésben) és ha valamelyik alkalmazott elbasz valamit, akkor nem ráncigálják oda az ügyfél elé, hogy de ő volt, hanem házon belül elrendezik.

Persze, mikor a drága Linuxod kapcsán merült fel az, hogy akkor csesztessük a programozókat, akkor egyből ment a maszatolás, hogy de szakértők így meg úgy meg amúgy:

http://hup.hu/szavazasok/20120826/feleloss%C3%A9gre_vonhatonak_kellene-…

"A többi kérdésedre kérlek olvasd el az első hozzászólást. "

Más véleményével nem kellene elmaszatolni a te véleményed.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

""Nem mintha számítana"

Szerintem párszor már kitárgyaltuk, könnyű más farkával verni a csalánt."

Ne haragudj, hogy egy egyértelműen valótlan állítást meg mertem cáfolni. :D

"és nem is igazán a biztonsági hibák itt a kérdésesek"

De, itt pont csak azokról van szó.

"Persze, mikor a drága Linuxod kapcsán merült fel az, hogy akkor csesztessük a programozókat, akkor egyből ment a maszatolás, hogy de szakértők így meg úgy meg amúgy:"

Nem, nem saxus, nem olvastál el minden kommentet, csak beletrollkodsz a közepébe. A véleményem az, hogy egyáltalán nem kéne különbséget tenni.

--
trey @ gépház

Szerintem aki terel, az te vagy. Próbálsz lavírozni, személyeskedni, a problémáról elterelni a figyelmet. Az, hogy egy-egy esetben a felelősséget meg tudják-e állapítani, az a vizsgálat feladata lenne. Egy vizsgálat lezárulhat eredmény nélkül is. Azonban ha van felelős, lehetne felelősségre vonás is. Gondolod, hogy minden felelőst mindig elmarasztalnak?

--
trey @ gépház

"mivel sohasem tanultad,"
Nem mintha számítana, de ezt honnan vetted?

Csakis ebben a hozzászólásban született hozzászólásaid alapján. A tanulást nem úgy értettem, hogy nem végeztél el akár egy középfokú iskolát, hanem úgy, hogy legalább egy felső fokú iskolát elvégeztél és legalább 3-5 évet aktívan gyakoroltad is a szakmát, ahol ténylegesen meg lehet tanulni, ismerni ezeket a dolgokat. Ha ez így van, akkor elnézésedet kérem, de akkor nem látom, hogy miért úgy tünteted fel, mintha Te nem lennél programozó.

Az összes többi az igazán fontos kérdés, amire nem válaszolsz, pedig úgy látom, hogy nem csak "az érdekelt, hogy itt mit gondolnak róla az emberek", hanem aktívan az egyik álláspont mellett kardoskodsz.

Bizonyítványom van róla, hogy rendszerprogramozó vagyok. Több évig tanultam, ugyanazt a tananyagot, amit a főiskolán oktatnak. Igaz, hogy egy percig nem dolgoztam ebben a szakmában (mert nem érdekel a programozás), de azt állítani, hogy sosem tanultam, az hazugság.

Azt vitathatod, hogy értek-e hozzá (saját bevallásom szerint nem nagyon, nem is nagyon gyakorlom), de annyit azért elmondanék, hogy volt, amikor én segítettem ki szakmailag olyan programozót a saját területén, aki akkor már veteránnak számított a szakmában.

Kérlek ne terjessz valótlan dolgokat. Még akkor se, ha történetesen a véleményünk nem egyezik bizonyos kérdésekben.

Ja, annyit megjegyeznék, hogy a munkám során rendszeresen kerülök kapcsolatba programozókkal és pontos rálátásom van, hogy milyen sumákolások mennek nagyon sok helyen. Arra is, hogy az iskolákból kikerülő programozók milyen hozzáállással, ismeretekkel rendelkeznek és arról is, hogy vannak akik gané munkát végeznek. Olyan gané munkát, amit más területen már lefejezéssel jutalmaztak volna (haggyad' Feri, majd kijavítjuk a másik verzióban).

Olyan elbaszásoknak voltam sokszor tanúja, hogy ihaj. Kár, hogy jelenleg ezekről nem beszélhetek, de majd egyszer nyugdíjasan írok egy visszaemlékezést. Ha még vissza tudok majd emlékezni.

--
trey @ gépház

Lassan 10 éve foglalkozom szoftverfejlesztéssel, dolgoztam mindenféle cégeknél, kicsi magyar ratyi cégtől a nemzetközi nagyvállalatiig, és ha az átlagot nézem sajnos igazat kell adjak neked. De nagyon nagy a szórás, a magyar cégek jóval az átlag alatt teljesítenek, és a külföldiek padig jóval az átlag felett. Ebben benne van az is, hogy a nagyobb külföldi cégek már méretükből is adódóan, jóval szervezettebbek, van céges kultúra és fejlesztési módszertan, és jut pénz a fejlesztők továbbképzésére. A magyar cégeknél, kidolgoztatják a fejlesztők belét, hétvégi munka, napi 10-12 óra túlóra után nem meglepő, hogy mi kerül ki a fejlesztő kezei közül, amiről ő is tudja hogy szar, de a projektvezető bevállalta a határidőt, és valami működőnek látszó dolgot le kell szállítani. Persze a jobb és lelkiismeretesebb emberek ilyenkor otthagyják a céget, ezért van az, hogy ha egy cégnél a fejlesztési kultúrára nem figyelnek idővel ott csak a gányolós emberek maradnak. Volt nekem is olyan munkahelyem ahol csak fél évet dolgoztam. De sajnos ezek is megélnek, de ez nem egyedi ahogy vannak kontár autószerelők, meg festők stb ... De azért megélnek azok is akik igényes munkát csinálnak. Hogy melyikből van több attól függ mire van igény, most válság van csak a pénz számít mindenki spórolni akar, ezért kisebb az igény a minőségre, de ilyenkor meg kell keresni azokat a területeket, ahol ez még számít.

Szerintem nem terjesztettem rólad semmit, feltételesen fogalmaztam. Ha félreérthető voltam, ami velem gyakran megesik, akkor elnézésedet kérem.
Szerintem az első bekezdést alaposan kitárgyaltuk, tehát tanultad főiskolai szinten, de saját bevallásod szerint nem nagyon értesz hozzá.

Akkor immáron válaszolhatnál a többi kérdésre, hogy azokról mit gondolsz.

Igaziból a fent vázolt problémát el sem tudom nagyon képzelni, mivel nekünk az üzemeltetőkkel eddig semmilyen problémánk nem volt. Ha bármilyen problémába ütközik(ött) az üzemeltető, azt nagyon gyorsan próbáltuk vele tisztázni, megoldani, mert nem érdekünk, hogy rossz hírt keltsen a programunkról vagy rólunk.

Viszonylag sűrűbben foglalkozom szerződésekkel, olyan még nem volt, hogy épeszű vállalkozó aláírt volna olyat, hogy teljes felelősséggel tartozik egy hiba esetén az okozott kárért, hiszen ez teljesen beláthatatlan. Olyat már láttam, hogy pl. egy éves díjra lehet kötbérezni. Összefoglalva, szerintem korlátozottan felelőssé tehetők, ha támogatott szoftverről van szó, és teljes mértékben, ha kiderül hogy szándékosan beépített kódrészlet volt.
---
;-(

Mi van ha az ügyfél volt a gondatlan?
Többször előfordult már, hogy mi találtunk hibát a szoftverben (jellemzően tervezési hiba következményeként, vagy nem megfelelő telepítési környezet kialakítása miatt) és mikor szóvá tettük, akkor a megrendelő mondta, hogy jó az úgy. (Ezek jellemzően olyan projektek amit más cég kezdett fejleszteni, de átvettük és mi szupportáljuk.)

Pl. paraméterként átadott szerepkör, ami "nem gond, mert a webalkalmazás egy frame-ben nyílik meg és úgysem látja senki az URL-t"... :(

Vagy SSO úgy, hogy a cégen belül bármely gépről elérhető az éles szerver és a modify headers firefox pluginnal bármelyik ügyfél nevében lehet garázdálkodni. Csak mert elfelejtették rendesen belőni a hálót, hogy a gép csak a proxy-n át legyen elérhető.

Persze ha baj lenne valszeg mi lennénk a hibásak, de kicsit szar, hogy az időnk nagy részét az veszi el, hogy az ügyfél által "nem javítandó"-nak minősített hibákat papírozzuk le vele, hogy övé legyen a felelősség. Csak mert nem akarják kifizetni a javítást/áttervezést.

Meg ugye amúgyis jó kérdés sokszor, hogy a fejlesző vagy a tesztelő a hibás? Elvégre mindent tesztel a fejlesztő, majd a tesztelők, és a végén az ügyfél tesztelői is. Ha senki nem veszi észre a hibát elég csúnya dolog lenne a fejlesztőre verni az egészet.

ha ezt 30 evvel ezelott kitalaljak es bevezetik, ma nem lenne MicroSoft, nem lenne szifon, senki nem akarna programozo lenni, es egyebkent is visszamasztunk volna a fara :D

Nem el szavaztam, pedig nem vagyok programozó.
A gondatlanság az kb hiba, nem szándékos. Márpedig mindenki hibázhat. --és szokott is.
Amennyiben olyan szerződést kötnek amiben ez külön benne van, akkor viszont jogos. Ugyanakkor annak olyan ára is van, mert akkor biztosan átnézeti külön még vagy 15 emberrel átadás előtt, akiket persze meg kell fizetni. :) Valaki hajlandó ezt megfizetni?

Rózsár Gábor (muszashi)

Azé a felelősség, akié a jog.
Majd, ha a fejlesztéskor létrejövő szabadalmak és egyéb jogok (rész)tulajdonosa a programozó, akkor a felelősségvállalásról is lehet beszélgetni.

Ennél összetettebb a probléma.

Ha valaki azt kéri, hogy X dologért vállaljak felelősséget, akkor nyilvánvalóan úgy fogom meghatározni az árat is és aszerint fogom szervezni a projektet.

Ha valaki olyat kér, amelyért nem tudom vállalni (általában rajtam kívül álló okok miatt), akkor jelzem, hogy ezt és ezt tudom vállalni és ezt meg azt nem. Ettől függetlenül a legjobb tudásom szerint fogom elvégezni a munkát.

Nagyobb cégnél, ahol már teljesen biztos, hogy több szintre bomlik a fejlesztés, (mint mondjuk egy kis cégnél, ahol mondjuk 1..5 programozó összeül és alkot valamit), ott eleve van Q&A, amelynek pont az a feladata, hogy az ilyen hibákat kiszűrjék. Másrészt szintén van felelőssége a cégvezetésnek abban, hogy ne vállaljon be irreális dolgot. (Pl. mikor megbecsülik, hogy ez mondjuk 2600 munkaóra és lealkudják 1800-ra anélkül, hogy annak reális műszaki vonzata lenne.)

Arról nem is beszélve, hogy ha valaki sorozatosan hibázik, azt jobb helyeken cégen belül amúgy is felelősségre vonják.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

[troll]Szerintem mar az olvashatatlanul hosszu EULA-ert is birsagot kene kiszabni[/troll]

alapvetően ott a gondom, hogy ha általános modellt akarok alkotni, mindenki perelhető lesz aki egy hello world -nél bonyolultabb dolgot ad ki. A trollkodás melegágya. Valahol viszont el kéne dönteni, hogy lustaságból benne hagyott programhiba utáni adatvesztés érjen kártéritést, de a véletlenül, vagy előre nem látható hiba után ne lehessen perelni.
Nehéz ügy. Szerinte merre értelmes megoldást nem tudunk alkotni.
--

+1

Az USA szabadalmi rendszerét is kihasználják már, akkor mi akadályozza meg a rivális cégeket, hogy egymás szoftvereit nyúzzák, és minden biztonsági résért perelnének?

Az a baj, hogy tényleg el tudnám képzelni (mondjuk egy Apple-Samsung párosról, hogy aktuálisak legyünk :)), hogy ezt megcsinálják.

Hibátlan kód nincs. Csak azt érnék el vele, hogy leállna a sw fejlesztés és újra a nagyvállalatok lennének az egyeduralkodók. Az ügyvédek pedig tovább híznának az idiótábbnál idiótább pereken.

Egy dolgot nem latok: van ezek a PWNIE-gyoztes chrome toresek minek szamitanak?

Bennhagy egy SQL injection-t a figura, kiverem a szemet, rendben van. Ellenorizetlenul, tisztitas nelkul olvas be inputot, megverem, rendben van. De ilyeneket hova, hogyan?

Multkor valamelyik delikvens kozolte (biztonsagi szagerto), hogy milyen gaz mar, hogy egy (amugy sokat hasznalt) jelszot memoriaban tart a rendszer, es ott a memoriaban plaintext, tehat ha sikerul megkerulni az OS memoriavedelmet, akkor ott a jelszo.

Az a baj, a biztonsagrol papolok, meg a konkretan embereknek szolo szoftvert fejlesztok nem alkatnak kozos halmazt. Megprobalok mindent kikerulni, de ilyen chrome-szeru izekkel hagyjanak mar beken, az leginkabb egy NP-teljes problema tanutetele.

Egyértelműen nem. Hiába a programozó legjobb szándéka, egy viszonylag egyszerű
alkalmazásnál is olyan nagy lehet az állapottér, amiben a program dolgozik, hogy
esélytelen minden esetet lefedő tesztelést/fejlesztést végezni, erre egyszerűen
nincs idő. Mindezt úgy, hogy könyvtárakban, virtuális gépekben (jvm, etc.), illetve
operációs rendszerek helyes működésében bízunk, felvállalva, hogy az ezen rendszerek
frissítése (amire fejlesztőként nincs kihatásunk) nem hoz be esetlegesen olyan hibát,
ami a mi termékünket kompromitálja.

Gondoljatok bele, milyen szintű defenzív programozás kellene ahhoz,
hogy az adott rendszer minden egyes hibáját kezeljük? Éppen ezért minden programban
általában sok bug, vagy esetleg hiányosság van, amit józan ésszel elvárhatunk, hogy
a fő lefutások az elvárásoknak megfelelően működjenek.

Van természetesen lehetőség arra, hogy matematikailag bizonyítottan helyes programot
írjunk, azonban ezt kb. senki nem tudná megfizetni.

Van természetesen lehetőség arra, hogy matematikailag bizonyítottan helyes programot
írjunk, azonban ezt kb. senki nem tudná megfizetni.

Nincs. Egy Linux/Windows/MS Word/stb. komplexitasu programot a jelen eszkozeinkkel nem tudunk validalni, nincs ra eleg eroforras a foldon, kb.
----------------------
while (!sleep) sheep++;

Én főleg a PHP-s oldalt látom nap mint nap, amit persze le lehet hurrogni hogy csak scriptnyelv, de a fő problémát abban látom, hogy a megrendelőnek fogalma sincs arról, hogy mit várjon el a fejlesztőtől. A másik probléma egynémely fejlesztő hozzáállása. A következő esetekre gondolok:

- A T. Megrendelő roppant nyomott áron akarja a csillagos eget is, ami rosszabb esetben csak a megrendelés közben derül ki és nincs is értelmes elvárása a szoftverkörnyezetre (esetünkben PHP és MySQL verzió és azokon belül egy-két feature esetleg). Itt nyilván az is bejön a képbe, hogy aki nagyon olcsón dolgozik, annak ez nem a sokadik komoly projektje.

- A fejlesztő(k) szerencsés esetben hajlandóak fél év garit vállalni a kódra, de általában a kérdés felmerülésekor elég bután néznek. Még hosszabb fejlesztési tapasztalatú cégek és fejlesztők is beleestek már ebbe. Például előfordult, hogy a PHP 5.3 update-ről körbement a hírlevél és a Joomlahuszárok elég nehezen vették a levegőt, amikor a bőven 1.5.15-nél régebbi Joomlájuk nem ment. Itt rögtön le is buktak, mert 1.5.26 körül hagyták abba annak a verziónak a supportját talán 1,5 éve. :)

- Ha rendesen halad is a fejlesztés, a T. Megrendelő oldaláról csak minimális funkciónális hibakeresésre van csak kapacitás (akár időbeli, akár tudásbeli). Ehhez rögtön hozzá is kell tennem, hogy elég nehéz lenne egy full biztonsági auditot kérni minden PHP-ban írt rendszerre, de legalább néhány gyakori mintával be lehetne próbálkozni.

- Aki bármilyen opensource CMS/keretrendszer/blogmotor/bármi felhasználásra adja a fejét, legalább tájékoztassa a T. Megrendelőt, hogy bizony ezek ellen hamar lesz célzott exploit, ha találnak valamit, és érdemes időszakosan frissítgetni. Ilyenkor jön a "rosszaszerver" és tsai, tudom tudom modsecurity és egyebek, de akkor meg azért anyáznak és azért "rosszaszerver", tehát ez nehéz kérdés innentől. Ha olyan a bug, akkor pedig hiába van mod_security, főleg egy osztott tárhelyes szerveren.

- Rengeteg csak úgy "csomagból felszórt" és kb. "huhezműködik" PHP telepítés fut, ahol még minimális korlátok sincsenek (pl. open_basedirre vagy a shell hivó függvények tiltása). Ezek nyilván nem oldják meg a hibás kód problémáját, de sokat segítene az általános helyzeten valszin, ha egy kicsit körültekintőbbek lennének ezek. Az is hozzátartozik, hogy a PHP tele van olyan opciókkal, amivel trükkösen elő lehet csalogatni mindenféle funkciót, pl. shell hívást. Ilyenre már sikerült is ráfutnom és nem volt őszinte a mosolyom, DE ami az érdekes, hogy a T. Ügyfél dupla trehánysága is kellett a probléma kiteljesédéhez.

- Mi a helyzet a sima egyszerű jelszó lopásokkal? Elsősorban az itt is rendszeresen előjövő Total Commander és más FTP kliens ini filejából kinyert FTP accountokra gondolok, aminél jobb nem is belegondolni, hogy ebből hány teljes shell account. Igazából ez is programozási probléma, mert a juzernek kell az elmenett jelszó, amit visszafejthető módon kell elmenteni. Ugyanez a gond, minden egyes nem-SSL-t használó protokollal, hiszen aki írta az pontosan tudta (legalábbis tudnia kéne), hogy lehallgathatóak. Az telefonokból esetlegesen kinyerhető jó eséllyel SSO jelegű AD-s Exchange jelszavakra még gondolni sem merek.

A php esetén Péhápé István által írt kód, az abban használt mások által írt kód, az aktuális php futtatókörnyezet, a webszerver, annak beállítása, az os mind-mind lehet hibás - jó kérdés, hogy egy káreseménynél hogyan, miként és ki fogja a felelősséget felosztani az egyes komponensek között?!

Ez teljesen egyszerű, az ügyfél a "fővállalkozóval" van "szerződésben" (tekintsünk el attól, hogy PHP Pistivel szóban kötnek megállapodást), tehát a fővállalkozó a felelős egy személyben. Ő behajthatja az esetleges bírság összegét vagy egyéb ráfordítást az "alvállalkozóitól", ha tudja. Érdeklődve figyelném, mi lenne egy ilyen per eredménye... :-))
---
;-(

Simán működik jogilag a felelősségkizárás és használni is kell. Pl. PHP esetben felhívod a figyelmet arra, hogy ha nem https site-on futtatja az általad készített admin kódot, akkor lehallgathatják és felhasználhatják a jelszavát, de mivel nem Te telepíted a webszervert, ezért nyilván nem terhel felelősség.
---
;-(

Csak ha bizonyítható, hogy rosszindulatból, szándékosan került bele (pl. tipikusan hátsó kapuk).
---
;-(

Végigfutottam a hozzászólásokat. Alapvetően mindenkinek van egy kis igaza, de:

1. sajnos az ember nem assembly-ben fejlesz teljesen elölről egy általa épített hardverre, tehát nem tudhat - láthat át mindent. (Ja persze, de soha nem végezne egy projekttel.),

2. a szoftver tesztelés soha !!SOHA!! nem lehet kimerítő, erre van egy nagyon egyszerű példa: vegyetek 3db 16 bites számot és adjátok össze, a teszt esetek száma 2^48 szóval 2.814749767×10^14. Ehhez kell egy 786432 terabájt teszt adatbázis.

3. ha ez nem csak egy ilyen egyszerű feladat, hanem állapotgépeket is tartalmaz, akkor gyakorlatilag reménytelen a teljes tesztelés.

4. a hibák kikerülése program sorokkal jár. Következésképpen növeli a hibák lehetőségét.

5. a program alaphelyzetben jól viselkedik, de ha kikerül a normál állapotból nem képes hibátlanul teljesíteni a feladatát.
Példa: 2008 október 7 Quantas Airbus A330-301 az állásszögadó hibájából megkergült és a felügyelő szoftver egy valószínűtlen egyidejűség miatt nem tudta helyesen értelmezni az adatokat. (Pedig ez egy repülőgép fedélzeti szoftvere.)

A véleményem:

a. ha valaki szándékosan a szoftverben hagy kiskaput, azt vonják felelőségre,

b. van garancia, törvényileg is van, ha eladod a terméked, akkor gariban javítsd ki,

c. ha valaki csak úgy letölt valamit és felrakja, akkor vessen magára, (én is megteszem, ha emiatt szívok az én hibám, de néhány igen borsos árú sw eszköz is csúnyán hibázik),

d. a szoftvert a lehetőségekhez mértem a lehető legjobban tesztelni kell az összes hozzáférhető és alkalmazható módszerrel, (a legnagyobb probléma az idő, ez az az erőforrás, amivel nem rendelkezünk szabadon /köszönöm Robi/),

e. ha szerződést kötsz írd bele a garanciális feltételeid és az elvárható szolgáltatásokat, (tapasztalat, volt már olyan, hogy 50% plussz szolgáltatást követelt a megrendelő, mondván, ez a szoftvertől elvárható. A szoftvertől az várható el, amit a szerződés és mindkét fél által elfogadott és aláírt specifikáció tartalmaz se több, se kevesebb!!!!!!),

Köszönöm, ha valaki végigolvasta.
Fm

3. ha ez nem csak egy ilyen egyszerű feladat, hanem állapotgépeket is tartalmaz, akkor gyakorlatilag reménytelen a teljes tesztelés.

A szakma mar annyira elfelejtette a formalis ellenorzeseket (LTL, petri-halok) hogy mar ilyeneket irogatnak? Nem azt mondom, hogy mindenhez, de azert egy Airbusnal megeri.

A szakma nem felejtette el, csak annyira nagy az eredendő állapottér, hogy egyszerűen nem lehet minden esetet figyelembe venni.

Azt se felejtsétek el, hogy mindig ott az időkorlát. Persze automatizáljuk a tesztelést, de vajon a teszt automata is figyelembe vesz mindent.

Én a magam részéről nagyon pártolom és használom is a statikus teszteket. Mert kellő tapasztalattal és tudással a hibák 90%-át kiszűrik. Hozzáteszem messze elkerülőm a web alkalmazás fejlesztést, inkább embedded és biztonságkritikus dolgokkal foglalkozom.

Konkurens esetben a dinamikus tesztelés nagyon szépen el tud kritikus hibákat "rejteni" lásd Airbus (tudnék Boing és Bombardier hibát is említeni, nem beszélve a Grippenről, vagy esetleg a Fobosz-Grunt, a Mars Climate Orbiter esete, vagy az első Ariane V felrobbanása).

Miért követtek el elemi hibákat?

-Hülyék lennének? Nem hiszem.
-Elemi hibát vétettek? Igen.
-Mi a hibák elkövetésének oka? Saccolom idő és pénzhiány.
-Felelősségre kellene a fejlesztőket vonni? Baromi nagy kárt okoztak. Szerintem nem, ez számukra a legnagyobb büntetés.

Tanulni kell az esetekből, fel kell tárni a problémákat, őszintén, nem egy fenyegetés árnyékában.

Ne felejtsük el a következő egyszerű "definíciókat":

-Mi a hardver: amibe belerúgunk.
-Mi a szoftver: ami miatt belerúgunk.

Még egy rövid kiegészítés:
A szoftver átadásánál (általános életciklus modell 6. lépés) a megrendelővel részletesen át kell vetetni a terméket, nem csak a nesze itt van, kész, vigyed. Mindenki utálja csinálni, én is, de ne kerüljük ki.

Ha hiba marad a szoftverben, akkor analizáljuk és javítsuk ki. Nem szeretem a zseni gyerekeket, akik egy sort átírnak és ezzel kész is a javítás. A szoftvertörténelem három legnagyobb kárt okozó hibája egy egysoros javítás volt. Ha javítasz - főleg konkures, vagy real-time, vagy mindkettő progit - igen újra kell tesztelni szigorúan.

Valszeg az am a nagy kulonbseg, hogy en mikozben ezeket tanultam, az egyetemi tarsaimmal egyutt dolgoztam sajat kis "webstudioban", igy mindent amit ott tanultunk ki tudtuk probalni mint es hogyan mukodik.

Ha valaki ezt megtanulja egyetemen, majd bemegy egy ceghez, ahol nem hasznaljak, ugy tenyleg csak az marad meg, hogy ez semmire se jo.

Ha elegge leredukalod a problemat, akkor a Petri-halokkal tudsz bizonyitani, mert lehet rajtuk ervelni.

Amugy en nem hibaturon vegeztem, nekem ebbol eleg volt a Form meg amit az 1.1-en leadtak meg.

Szerkesztve...

Nem az a kérdés hogy a program egy kis részét lehet-e bizonyítani (pl. protocol-t) hanem hogy az EGÉSZ programot lehet-e, illetve
ez mekkora effort-ba kerül. Itt buknak meg ezek a dolgok...

Még egy probléma: adott működést tudsz lemodelezni petri hálóval, viszont a kódod az egy másik, független programnyelvben lesz megírva.
Hogy kötöd össze a kettőt? Mi van, ha bár az ALGORITMUSOD helyességét bizonyítottad Petri hálóval, a kód valójában nem az (hiszen bugos)
mint amit a Petri hálóval leírsz?

Nekem eddig a munkaszerződésemben mindig benne szerepelt, hogy felelősséggel tartozom az általam megírt kódokért.

-----------
"640GB sokmindenre elég"

Az a véleményem, hogy így nem lehet álltalánosítani, hogy igen, vagy nem, vannak hibák amik programozóiak, és vannak amiket a tervezéskor találtak ki rosszul. Ha Igne, akkor frankó, minden programozóval börtönbe! Ha meg Nem, akkor kit érdekel mit kódolsz, akkor sem vesz elő senki. Ha meg nyílt forrású, akkor meg rá kell írni, hogy felelősséget nem vállalok, és kakukk. Függ a projekttől nagyon. Teljesen. Egy céges informatikusnak persze kitörik a nyakát ha hibázik, egy külsősnek csak ejnye-bejnye, ha meg magadnak írod, csak a te fejed fő. Ha nyílt, akkor meg mosod kezeid.

megszakertettem.
a C fordito a hibas.
johetnek a ++ -ok.

Azért szavaztam az "igen"-re, mert - bár elvben szépen hangzik - szerintem úgysem valósítható meg.
Mi a véletlen, mi a figyelmetlenség? Satöbbi.

Szerintem egyértelműen "nem" a helyes válasz.
Először is: elvileg minden hiba gondatlanságból marad a szoftverben. (Amelyiknél nem így van, az nem hiba, hanem "backdoor".)
Másodszor az, hogy valamamelyik hiba biztonsági hiba-e, vagy sem, csak akkor fog kiderülni, amikor egy rendszerbe behatolnak az adott hiba kihasználásával. Szerintem senki nem gondolja, hogy a VMWare azon hibája, hogy a virtuális hálókártyáján keresztül le lehet fagyasztani, biztonsági hiba lenne. Viszont ez a hiba elvileg lehetőséget ad a guest-nek, hogy kimásszon a VM-ből, és kártékony kódot hajtson végre a host-on (ráadásul rögtön kernel space-ben).
Harmadszor: egy-egy biztonsági hiba általában nem elég a betöréshez, vagy adatlopáshoz. Ha pedig már az egész rendszer hibás működését vizsgáljuk, akkor nagyon nehéz eldönteni, hogy melyik fejlesztő mennyire vétkes. Illetve vétkes-e egyáltalán, mert lehet, hogy ami az adott esetben hiba, az más esetekben fícsör.
Negyedszer: ezzel csak lehetőséget adunk másoknak, hogy a fejlesztőkre hárítsák saját felelősségüket. A vitaindító cikk példáját továbbgondolva: a bank se lesz felelős ezentúl a számlákon levő pénzekért, mert ő is rákenheti az esetleges gondatlanságot valamelyik fejlesztőre, vagy fejlesztő cégre.
Ötödször: a vitaindító cikkből látszik, hogy az egész csak az ügyvédeknek lenne jó.

"Szerintem senki nem gondolja, hogy a VMWare azon hibája, hogy a virtuális hálókártyáján keresztül le lehet fagyasztani, biztonsági hiba lenne."

Csak erre reagalok: eleg nagy baj, ha szerinted senki nem gondolja biztonsagi hibanak; illetve az, ha egyaltalan van olyan aki nem tekinti annak. Ugyanis amikor szamitogepes biztonsagrol beszelunk, akkor ott szerepel egy ilyen kitetel is: "availability" - azaz elerhetoseg. Marpedig (nem ismerem az altalad idezett hibat, de a leirasodbol ezt szurom le) ha pl. a guestbol romma tudom donteni a host-ot, az ezt az elerhetoseget serti, es mint ilyen, biztonsagi hiba.

(Van erre valami tesztprogram. Ha jól emlékszem, véletlenszeű memória és I/O címekre írkál véletlenszerű értékeket. A VMWare a 6.5-ös verzió magasságában eléggé hamar elfagyott ezen a teszten. Hogy azóta javult-e a helyzet, nem tudom.
De nem kell ilyen durva teszteket csinálni, a Gugli tele van virtuális gépek fagyásának esetleírásaival.)

wow, már látom hogy a szabadalmi perek után milyen kárteritesi perek indulnanak, de eszembe jut, hogy az otp olyan szerzodest akart anno alairatni velem az elektronikus fizetesnel, hogy a beagyazott rendszeruk biztonsagaert is en felelek... kb ez is ilyen vicc

Szerinted mit használok? Wi... neeem! Na, na, na? Hát blackPanther OS v12.0(beta)-t * blackpantheros.eu

acelszerkezeteknel meg a hegesztonek kelljen!!!11

--
NetBSD - Simplicity is prerequisite for reliability

Amugy meg a QA csapat is tartsa a hatat, ha lehet valasztani :)

Trey: melyik hír/szavazás/stb. (értsd: node) rendelkezik a legtöbb hozzászólással? :-) Ez a szavazás hosszúnak számít? Elég heves "vitát" váltott ki a kérdésed. :-)

Egy szoftverfejlesztő cégnek meg kell lennie a felépítésének, illetve a fejlesztés folyamatának, aminek része a tesztelés. Ha mégis kikerül egy hibás, rossz kód, az az egész céget érinti, és nem a fejlesztőt, programozót, mivel az egész cég részt vett a munkában.

--
r@g3
jáTék0s l1NuX [http://www.youtube.com/user/gerig0d]&gt;

Kötelezően és törvénybe foglaltan egyértelműen nem.

Gondoljunk csak bele hogy ezzel azonnal megölnénk az összes ingyenes szoftvert!!!

Úgy gondolom hogy a felelősségnek minden esetben szerződésben foglaltnak kell lennie, és nem szabad hogy ezt kívülről szabályozzuk!

Arról nem is beszélve hogy abszurd példaként egy ilyen törvénnyel például adósok börtönébe lehetne nyomni az összes kezdő programozót (akár diákot, egyetemistát) aki mondjuk közzéteszi az egyetemi háziját. Igen, tudom hogy nem erről van szó, de egy törvénynek _mindenre_ működnie kell, nem csak a nagy szoftvervállalatokra.

Ha az ember megfizeti azt hogy legyen fejlesztői felelősség, akkor vegyen olyan szoftvert amihez a szerződésben ez benne van. De ne akarjuk ezt kötelezővé tenni, mert akkor megöljük az összes hobbiprojektet és olyan olcsó "Tescós" alternatívát aminek a fejlesztési árába ez a felelősség nem fér bele. Ahol a cégnek kell a fejlesztői felelősségvállalás ott vegyenek olyan szoftvert aminek az árában ez benne van.

Összefoglalva: Törvénybe iktatva egy ilyen kötelezettség egészen biztosan rossz!

Esetleg azt el tudom képzelni, hogy ha egy hibát nem javít ki valaki a szoftverében, akkor ki kell adnia a kódját hogy a kliensnek legyen lehetősége kijavíttatni valakivel. De ez meg nem megoldás arra hogy most nem működik és azonnal tűzoltás kéne...

Szerintem ezért kár sírni, abból még megoldás nem született. A szerződéseket el kell olvasni, és ha ez alapján nem vonható felelősségre a fejlesztő, akkor ne használd a programot. Persze akkor nem lesz szolgáltatás meg bevétel se, nade túlórázni se kell a hülye programozók miatt :P

Érdekes ez a cikk, meg a hozzászólások is. Azonban azt hiszem a lehető legrosszabb végéről fogja meg mindenki ezt a problémát. Tény, hogy a szoftverek sok esetben rendkívül gyatra minőségűek, és az is tény, hogy ez rengeteg problémát és kárt okoz. Aki ezen mérgelődik, annak maximálisan igaza van abban is, hogy ez így helytelen, nem lenne szabad a gyártóknak/forgalmazóknak kibújni a felelősség alól.
Itt igazából meg is fogalmazódott az első problémám a felvetéssel kapcsolatban: minden más termék esetén a felelősség ott van, ahol a haszon illetve a jogosultság van. Tehát kereskedelmi termékek esetén itt a copyright birtokosnak, ingyenes termék esetén pedig a fizetős terméktámogatást vállalónak kellene vállalnia a felelősséget. (Igen Trey: oss esetben ez sokszor azt jelentené, hogy az üzemeltetésnek kellene vállalnia a felelősséget).
A másik problémám, hogy (ahogy a valós termékeknél) itt is egy adott feladatra/célra való használhatóságot kellene szavatolni, amit pontosan definiálnia kellene az eladónak. (Hiszen egy alap bejárati ajtónál sem az ajtó gyártóját akarod büntetni, ha lángvágóval szétvágták, hanem azt, aki kipakolt téged. Ha pedig valóban védekezni akarsz a lángvágó ellen, akkor veszel drágábban olyan specifikációjú ajtót.).
Tehát, ha a fentiek szerint a szoftverekből élő cégek/vállalkozások kötelezettek lennének felelősséget vállalni a termékeik után az adott célra való használhatóságig, akkor szvsz. hamar kikopnának a rossz/slendrián programozók, mivel vagy tovább képeznék, vagy kirúgnák őket.
Azt viszont határozottan ellenzem, hogy mások által végzett szándékos károkozás, vagy hibás használat (nem arra használják, amire való) esetén bármilyen felelősséget kellene vállalnia a gyártónak. (Már pedig a felvetés és a párbeszéd is kicsit ebbe az irányba indult el.)
Igazából az egész probléma abból adódik, hogy a szoftvereket (egyébként szerintem teljesen hibás módon) sokkal inkább művészeti alkotásként kezeljük jelenleg, ahelyett, hogy egy konkrét feladat elvégzésére szolgáló eszközként kezelnénk.