Fel kell-e tüntetnem, hogy egy eszköz milyen hosszú ideig kap szoftverfrissítéseket?

A szoftveres támogatás még nem kötelező

A szoftverfrissítések kötelező időtartama még nem rögzített. Az ESPR-keretalaprendelet (az Európai Unió 2024/1781 rendelete) ugyan jogi alapot biztosít arra, hogy ezt termékkategóriánként kötelezővé tegyék, azonban a tényleges követelmény — meddig kell a gyártónak frissítéseket biztosítania, és azt az időtartamot kötelezővé kell-e tenni a digitális termékútlevélben — csak a konkrét termékcsoportra vonatkozó delegált jogi aktusban kerül rögzítésre. Az elektronika és az ICT-eszközök esetében ez a jogi aktus még nem létezik. Amíg nem létezik, nem áll fenn általános, kikényszeríthető kötelezettség az update-időtartam rögzítésére az útlevélben, még akkor sem, ha a szoftveres elavulás lényegében pontosan az a fenntarthatósági téma, amelyre az ESPR irányul.

Releváns a szoftverrel rendelkező termékekre, nem minderre

Ez a téma olyan eszközöket érint, amelyek funkciója szoftvertől függ: intelligens funkciókkal felszerelt háztartási gépek, ICT-eszközök, és szélesebb körű elektronika firmware-rel vagy operációs szoftverrel. Tisztán mechanikai, szoftver nélküli termékek esetén a kérdés egyszerűen nem releváns. Az elektronikai szektor keretében is igaz: az ESPR delégatáris jogalkalmazásokkal dolgozik termékkategóriánként, így egy követelmény, amely az okostelefonoknál érvényes lesz, nem automatikusan vonatkozik a mosógépre vagy az útválasztóra. A keretalaprendelet maga (5–7. cikk) felsorolja a kitűzendő követelmények típusát — beleértve a fenntarthatóságot, a megbízhatóságot és a javítás és felújítás alkalmasságát —, de ezt még nem fordítja le konkrét évszámra konkrét termékhez. Aki most konkrét időtartamot keres egy adott eszközhöz, azt az ESPR jelenlegi szövegében nem fogja megtalálni.

Még nincs dátum: delegált jogi aktusok kategóriánként

Nincs rögzített dátum, amikor ez az elektronika és az ICT-eszközökre vonatkozni fog. Az ESPR 2025–2030 munkaprogramja szerint delégatáris jogalkalmazásokat dolgoznak ki termékkategóriánként, azzal a várakozással, hogy az első közülük 2027-től várható. Ez a munkaprogram által adott jelzés, nem ígéret és nem törvény. Amíg egy konkrét termékcsoportra vonatkozó delegált jogi aktus meg nem jelenik, az adott csoportra az ESPR általános rendelkezései érvényesek (5–7. cikk az anyagi követelményekre, 10. cikk arra, hogy mit kell tartalmaznia a digitális termékútlevélnek), anélkül, hogy ebből már konkrét update-időtartam következne. Amint az elektronika vagy az ICT-eszközökre vonatkozó delegált jogi aktus megjelenik, itt láthatóvá válik a dátum és az adott követelmény tartalma.

Mit jelent ez: a megközelítés sorrendje

Aki erre fel akar készülni, először a saját termékkategóriáját tekinti meg az ESPR munkaprogramban, és onnan nyomon követi a hozzá tartozó delegált jogi aktus közzétételét — ez az a pillanat, amikor világossá válik, hogy szükséges-e és meddig az update-időtartam és azt kötelezővé kell-e tenni a digitális termékútlevélben. Ez a közzététel előtt nincs jogi kötelezettség az információ útlevélben való elhelyezésére, de semmi sem tartóztathatja vissza a gyártót abban, hogy belsőleg már most is nyilvántartsa, meddig kerül garantálásra a szoftvertámogatás termékvonalonként — ez akkor saját, önkéntes ígéret, nem ESPR-kötelezettség. Akik digitális termékútlevelet készíttetnek, számára ez gyakorlatban azt jelenti: a jelenlegi útlevél-szerkezet még nem kell, hogy tartalmazza ezt a mezőt, de amint a bejelentett delégatáris jogalkalmazás ezt előírja, a mező hozzáadódik az útlevélhez, és kitöltésre kerül az adatokkal, amelyeket a gyártó vagy importőr akkor biztosít. Aki már most is nyilvántartást vezet a szoftvertámogatásról — mely modellek, mely időtartamok, mely frissítési szabályzatok — azzal előnyt szerez arra a pillanatra, amikor a követelmény konkrét lesz, mert ezek az adatok akkor már rendelkezésre állnak az útlevélbe való beépítéshez.

Az alap: az 5–7. és 10. cikk

A szoftveres támogatásra vonatkozó követelmények lehetősége az ESPR (2024/1781 EU rendelet) 5–7. cikkeiből adódik, amelyek az ökológiai tervezés keretét képezik: teljesítményi követelmények, például tartósság, megbízhatóság és frissítésre való alkalmasság, valamint ezekre vonatkozó információs követelmények. Ezek a cikkek a követelmények azon kategóriáit nevezik meg, amelyeket delegált aktusok útján termékenként még részletezni lehet, de nem állapítanak meg konkrét frissítési időszakot. Az ugyanez rendelet 10. cikke azt szabályozza, hogy mit kell felvenni a digitális termékútlevélbe; itt is igaz, hogy a konkrét adatmezők termékkategóriánként kerülnek meghatározásra, az adott kategóriára vonatkozóan megállapított követelmények alapján. Amíg az elektronika és az IKT terén nincs olyan delegált aktus közzétéve, amely a szoftveres támogatást kifejezetten nevezi meg, ez a tárgy a keretrendelet szerint lehetőség marad, nem konkrét kötelezettség.

Aki most már ezzel a kérdéssel foglalkozik, legjobb, ha figyelemmel követi az adott termékkategóriájára vonatkozó delegált aktus közzétételét, és közben rendbe hozza saját szoftveres támogatásra vonatkozó adatait, hogy azok készen álljanak, amint az útlevél erre vonatkozó adatot kér.

Erre alapozva

A rendelet maga az EUR-Lex webhelyen található. Érvelésenként hivatkozunk; nem kell bennünket hinni.

Mit kell konkrétan tennie

Mit várnak el Önöktől

A szoftveres támogatás ökológiai tervezési követelmény lehet

Az ESPR lehetővé teszi, hogy a delegált jogi aktusok a termék fenntarthatóságára vonatkozó követelményeket tartalmazzanak, és ezen belül a szoftverrel kapcsolatban is: meddig kap egy eszköz funkcionális és biztonsági frissítéseket, és mi történik az eszköz funkcionalitásával, amint az ilyen támogatás befejeződik. Az ESPR 5. és 7. cikke (2024/1781/EU rendelet) ezt az átfogó teljesítményi és információ-nyújtási követelmények részének nevezi, amelyeket termékcsoportonként lehet meghatározni. Az elektronikai és ICT-eszközök esetében ez az egyik témakör, amely relevánsnak tekintendő, tekintettel a szoftvernek az eszköz élettartamára gyakorolt hatására — egy olyan mosógép vagy laptop, amely technikailag még működik, de már nem kap frissítéseket, a gyakorlatban gyakran mégis le lesz cserélve. Egy 10 és 100 közötti alkalmazottal rendelkező vállalat számára ez azt jelenti, hogy a termékinformációért felelős részleg (gyakran ugyanaz, amely jelenleg már a garanciaidőszakokat és felhasználói kézikönyveket összeállítja) egy új adatot kell, hogy figyelemmel kísérjen: azt az időszakot, amikor a frissítések szállítása történik, termékmodellekre vagy szoftververziókra vonatkozóan.

Az információnak a termékiratban kell megtalálhatónak lennie

Az ESPR 10. cikke (2024/1781/EU rendelet) azt írja le, hogy mely információkat kell az elektronikus termékiratba beépíteni, amint egy delegált jogi aktus azt egy termékcsoportra meghatározza. Amint a szoftveres támogatás időtartama a villamos készülékek követelménye lesz, az információ tehát nem csak egy kézikönyvben vagy weboldalon jelenik meg, hanem magában az irattöltésben is — strukturáltan, és összekapcsolva a termékre helyezett QR-adathordozóval. Egy középvállalkozat számára ez azt jelenti, hogy a frissítési időszak nem határozható meg önállóan a szoftveres részleg által, és nem kommunikálható önállóan a marketing által: az információnak végül abban az adathalmazban kell lennie, mint például az energiafogyasztás és a javíthatósági pontszám. Az irattöltésbe pontosan mit kell beépíteni, az termékcsoportonként eltérő; a mely adatok kerülnek az elektronika termékalkalmazás-útlevélébe? a kategóriaadatok áttekintését tartalmazza, amelyek benne vannak.

A megadott időszaknak meg kell egyeznie a valósággal

A támogatás időtartamának meghatározása az egyik lépés; annak teljesítése azonban más. Ha egy gyártó az eszközhöz egy frissítési időszakot ígér meg, akkor az a várakozás, hogy ezt az időszakot ténylegesen teljesítik — és hogy a változások (a frissítési ciklus korábbi leállítása, egy felvásárlás során egy szoftvercsoport leépítése) dokumentálva lesznek. Ez az a kérdéshez kapcsolódik, hogy az eszköz adatait milyen gyakran kell aktualizálni; lásd milyen aktuálisnak kell lenniük az adatoknak? erről, hogy mit tudunk. Egy ilyen méretű cég számára ez gyakran azt jelenti, hogy a frissítési időtartamra vonatkozó ígéret nem csak a termékmenedzser által történik, hanem a szoftvvert ténylegesen fenntartó fél — belső csapat vagy külső szállító — is bevonódik az egyeztetésbe.

Hol megy félre a gyakorlatban

Első eset: egy gyártó a marketinganyagban frissítési időszakot említ ("öt év biztonsági frissítés"), de ez az ígéret sehol nincs rögzítve egy kezdő és végdátummal rendelkező belső dokumentumban. Amint ezt az információt az eszközhöz fel kell venni, nincs egyértelmű forrás.

Második eset: az eszköz szoftvere egy beszállító által szállított (chipgyártó, platformszállító), és az importőr, aki az eszközt összeállította, nem tudja, hogy a beszállító meddig garantálja a támogatást. Az eszköz adatainak helyességéért felelős fél az, aki az eszközt összeállítani kéri, még akkor is, ha az alapul szolgáló információ harmadik féltől származik.

Harmadik eset: egy eszközt több verzióban értékesítenek (különböző chipset-ek, különböző szoftververziók régiónként), de a frissítési időszak az egész modellszámra egyetlen számként kerül meghatározásra. Egy később végzett ellenőrzésnél kiderül, hogy egyes verziók rövidebb ideig kapnak támogatást, mint mások.

Negyedik helyzet: egy már eladott készülék stratégiamódosítás miatt a tervezett időpontot megelőzően már nem kap frissítéseket, de ezt a változást nem közlik azzal, aki a passzportot kezeli. A passzport adatai az eredeti, túl optimista időszakot mutatják tovább.

Ötödik helyzet: egy vállalat úgy gondolja, hogy a "szoftveres támogatás" csak biztonsági frissítéseket jelent, míg a funkcionális frissítések (új funkciók, új kiegészítésekkel való kompatibilitás) külön kezelendők – és a vásárlóval kapcsolatos kommunikáció erre vonatkozóan inkonzisztens, nincs világos, hogy a kettő közül melyik tartozik a passzportba.

Amit rögzíthet

Egy termékmodelenként készített belső dokumentum a szoftverfunkciók támogatására és a biztonsági frissítések támogatására vállalt időszakokról, mindegyikhez egyértelmű kezdési dátummal (például piaci bevezetés) és, ha ismert, végdátummal.
Megállapodások szoftverforgalmazókkal vagy beszállítókkal a általuk garantált minimális támogatási időtartamról, beleértve azt, hogy mi történik felvásárlás, csőd vagy platform bezárása esetén.
Az eszköz funkciójának áttekintése, hogy mely összetevői függenek szoftverfrissítésektől, és mi történik ezzel a funkcionalitással, amikor a támogatás véget ér (például: az eszköz alapfunkcióit továbbra is ellátja, de elveszti az alkalmazásokkal való kapcsolatot).
Egy folyamat, amely lehetővé teszi az update-ütemezés módosításainak (korai leállítás, meghosszabbítás) közlését a terméktermék-passzportot kezelő részlegnek, hogy az adatok ne maradjanak el a valóságtól.
Megkülönböztetés a termékmodell végrehajtása vagy változata alapján, ha a szoftver-támogatás chipset-ként vagy piaci régió szerint eltérő.
Az információ forrásának rögzítése: az adott időszak saját ígéret, vagy a beszállító által közvetített garancia? Ez akkor releváns, amikor valaki megkérdezi, hogy a termékpasszportban szereplő adat mire alapul — lásd még Hibát fedeztem fel a termékpasszportban, mi a teendő? hogyan lehet kezelni a helytelen vagy elavult adatokat.

Amint az elektronika és az IKT delegált jogi aktusa közzé lesz téve, itt konkrétan bemutatásra kerül, hogy pontosan mely adatok kötelezőek és milyen formában. Addig az update-periódusok feletti saját, ellenőrizhető dokumentáció felépítése egy olyan módszer, hogy később ne kelljen rekonstruálni, amit korábban ígértek.

Ez nem jogi tanács. Ez az oldal általános információt nyújt az érvényes szabályozásról. Mi nem ismerjük az Ön helyzetét. Ha bizonytalansága van saját ügyében, konzultáljon ügyvéddel vagy a hatáskörrel rendelkező felügyelettel.

Mesterséges intelligenciával írva a fenti források alapján, 2026-08-22-én embernek végignézve. Nem stimmel valami? Jelezze — a javítások elsőbbséget kapnak.