Jika bisnis Anda bergantung pada perangkat lunak yang tidak Anda tulis, Anda bergantung pada perusahaan yang membuatnya. Anda memegang kode objek dan lisensi; pemasok memegang kode sumber, alur kerja pengembangan, dan pengetahuan. Asimetri tersebut dapat ditoleransi selama pemasok masih mampu membayar dan kompeten, dan berhenti menjadi demikian saat tidak lagi. Pengaturan escrow perangkat lunak adalah solusi standar, tetapi hanya berfungsi jika dirancang dengan mempertimbangkan hukum kepailitan Belanda — dan sebagian besar pengaturan tidak demikian.
Apa itu escrow dan risiko yang ditanganinya?
Pemasok menyimpan kode sumber dan materi pendukungnya pada pihak ketiga independen, yang akan menahannya hingga suatu peristiwa tertentu terjadi dan kemudian melepaskannya kepada pelanggan, yang dapat menggunakan dan memodifikasi kode tersebut agar perangkat lunak tetap berjalan. Risikonya adalah keberlanjutan, bukan kepemilikan: pelanggan yang menjalankan pemrosesan pesanan, catatan pasien, atau perencanaan produksi pada produk satu pemasok tidak dapat beralih dalam semalam, karena migrasi membutuhkan waktu berbulan-bulan dan biasanya membutuhkan bantuan pemasok sebelumnya. Sistem escrow memberikan waktu untuk keluar secara teratur. Tiga situasi penting:
- Keadaan bangkrut. Pemasok dinyatakan bangkrut, seorang wali amanat ditunjuk, cuti dan dukungan karyawan dihentikan. Skenario inilah yang menjadi dasar pembuatan perjanjian escrow, dan di sinilah hukum Belanda berperan paling besar.
- Penghentian. Pemasok menarik produk, menghentikan versi Anda, atau diakuisisi oleh seseorang yang tidak tertarik dengan implementasi Anda. Hal ini lebih umum terjadi daripada kebangkrutan, dan seringkali tidak tercantum dalam klausul pelepasan.
- Kegagalan pemeliharaan yang terus-menerus. Pemasok tersebut masih ada dan masih menerbitkan faktur, tetapi tidak lagi memperbaiki kerusakan, mengirimkan patch keamanan, atau menjaga kompatibilitas produk dengan dependensinya.
Pengaturan dua pihak dan tiga pihak
Kesepakatan dua pihak adalah janji dalam kontrak utama bahwa pemasok akan menyerahkan kode sumber jika suatu peristiwa tertentu terjadi. Kesepakatan ini murah dan lemah: tidak ada pihak independen yang memeriksa apakah ada sesuatu yang telah diserahkan atau diperbarui, dan — yang terpenting — jika terjadi kebangkrutan, Anda meminta kurator untuk melaksanakan kewajiban harta pailit, yang sebenarnya tidak wajib dilakukannya.
Pengaturan tiga pihak menambahkan agen penjamin sebagai pihak yang berkontrak. Agen tersebut mengambil alih, memeriksa deposit, menyimpannya, dan memiliki kewajiban langsung kepada Anda untuk melepaskannya. Itulah alasan utama untuk membayar jasa agen penjamin: pelepasan menjadi pelaksanaan oleh pihak ketiga yang mampu membayar berdasarkan kontraknya sendiri, bukan oleh harta pailit. Agen tersebut juga memutuskan apakah peristiwa pelepasan telah terjadi, sehingga menghilangkan wewenang dari wali amanat yang tidak memiliki insentif untuk membantu Anda.
Apa yang sebenarnya disetorkan
Kegagalan yang paling umum bukanlah masalah hukum. Itu adalah deposit yang hanya berisi kode sumber dan tidak ada yang lain. Kode sumber saja tidak dapat dikompilasi: jika diberikan kepada pengembang tanpa instruksi pembuatan dan tanpa daftar dependensi, basis kode yang besar dapat memakan waktu berminggu-minggu untuk rekayasa balik sebelum menghasilkan biner yang dapat dijalankan — waktu yang tidak Anda miliki ketika sistem tersebut sudah tidak didukung. Deposit tanpa instruksi pembuatan tidak berharga.
| Komponen | Mengapa itu dibutuhkan |
|---|---|
| Kode sumber, lengkap dan terverifikasi. | Harus sesuai dengan rilis yang benar-benar digunakan di lingkungan produksi, bukan cabang pengembangan. |
| Petunjuk pembuatan dan penyebaran | Versi kompiler dan runtime, skrip build, variabel lingkungan, langkah-langkah deployment. Tanpa semua ini, kode tidak dapat menjadi perangkat lunak yang berfungsi. |
| Dokumentasi teknis dan fungsional | Arsitektur, model data, antarmuka, cacat yang diketahui. Menentukan apakah pihak ketiga dapat memelihara kode atau hanya menjalankannya. |
| Komponen pihak ketiga dan sumber terbuka | Daftar dependensi beserta versi dan ketentuan lisensi. Beberapa komponen komersial memerlukan lisensi terpisah dari pemasoknya. |
| Kunci lisensi, sertifikat, kredensial | Perangkat lunak yang terhubung ke server lisensi yang mati bukanlah sebuah kontinuitas. |
Tambahkan kewajiban pembaruan. Deposit yang dilakukan sekali pada saat penandatanganan akan kedaluwarsa dalam satu atau dua siklus rilis. Kaitkan deposit dengan jadwal rilis — setiap rilis utama, atau interval tetap — dan berikan hak untuk diberitahu jika ada keterlambatan.
Verifikasi: apa yang Anda bayar
Beli opsi menengah di bawah ini sebagai standar, dan uji coba lengkap di mana gangguan akan berdampak fatal. Pemeriksaan tingkat file saja hampir tidak memberikan manfaat apa pun.
- Pemeriksaan tingkat berkas. Agen tersebut mengkonfirmasi bahwa deposit tersebut dapat dibaca, bebas virus, dan sesuai dengan daftar file. Ini membuktikan bahwa sesuatu telah sampai, bukan berarti sesuatu itu berfungsi.
- Kelengkapan dan peninjauan dokumentasi. Agen memeriksa instruksi pembuatan dan dependensi terhadap deposit dan melaporkan kekurangan. Opsi menengah ini tepat untuk sebagian besar pelanggan: opsi ini menangkap kegagalan umum — langkah pembuatan yang hilang, dependensi yang tidak terdokumentasi, komponen yang tidak berhak Anda gunakan — dengan biaya yang jauh lebih rendah daripada pengujian lengkap.
- Proses build dan pengujian berjalan sepenuhnya. Agen tersebut menyusun deposit dalam lingkungan yang bersih dan menjalankannya terhadap data uji. Ini adalah satu-satunya level yang membuktikan bahwa deposit tersebut berfungsi, tetapi lebih lambat, lebih mahal, dan membutuhkan pengulangan karena perangkat lunak terus berubah.
Acara peluncuran, dirancang sedemikian rupa sehingga tidak dapat diperdebatkan.
Klausul pelepasan adalah pemicu yang harus diterapkan oleh agen escrow di bawah tekanan dan tanpa nasihat hukum. Setiap peristiwa harus dapat dibuktikan dari sebuah dokumen atau berjalannya waktu, bukan dari penilaian tentang perilaku pemasok.
| Acara peluncuran | Bagaimana cara membuatnya dapat ditentukan secara objektif? |
|---|---|
| Kebangkrutan pemasok | Putusan pengadilan, atau catatan dalam register kepailitan. |
| Penangguhan pembayaran atau prosedur restrukturisasi | Pengangkatan administrator atau ahli restrukturisasi, sesuai dengan catatan dalam register. |
| Pembubaran atau penghentian usaha | Pencabutan pendaftaran dari daftar perdagangan, atau resolusi untuk membubarkan diri. |
| Penghentian produk atau versi yang digunakan | Pemberitahuan tertulis tentang penghentian produksi, atau berakhirnya jangka waktu tertentu setelah pemasok berhenti mengeluarkan rilis. |
| Kegagalan terus-menerus dalam pemeliharaan | Kegagalan untuk memperbaiki cacat dengan tingkat keparahan yang telah ditentukan dalam waktu respons kontraktual, setelah pemberitahuan dan masa perbaikan, yang diulang sejumlah kali dalam jangka waktu tertentu. |
| Pengalihan perangkat lunak ke pihak ketiga | Tidak ada pengalihan kewajiban pemeliharaan secara tertulis oleh pihak pembeli dalam jangka waktu tertentu. |
Dua poin ini memainkan peran penting. Pertama, beban pembuktian ada pada pemasok: pelanggan memberi tahu agen dengan bukti, pemasok memiliki jangka waktu tetap yang singkat untuk mengajukan keberatan, dan jika tidak ada keberatan, agen akan melepaskan tanggung jawab. Kedua, tetapkan jalur penyelesaian sengketa terlebih dahulu — penentuan oleh ahli atau arbitrase dalam jangka waktu singkat — sehingga keberatan hanya memberi waktu beberapa hari, bukan berbulan-bulan.
Masalah kepailitan Belanda
Semua hal di atas adalah rancangan kontrak. Apa yang selanjutnya akan menentukan apakah rancangan tersebut tetap berlaku jika pemasok mengalami kebangkrutan.
Apa yang dapat ditolak oleh wali amanat
Berdasarkan pasal 37 Fw, jika suatu kontrak timbal balik belum sepenuhnya dilaksanakan oleh salah satu pihak pada saat penetapan kepailitan, pihak lawan dapat memberikan jangka waktu tertulis yang wajar kepada kurator untuk menyatakan apakah ia akan melaksanakan kontrak tersebut; jika tidak, ia kehilangan hak untuk menuntut pelaksanaan kontrak sebagai imbalannya. Yang tidak dilakukan oleh pasal 37 Fw adalah mengakhiri kontrak atau memberikan wewenang kepada kurator untuk mengakhiri kontrak tersebut. Kontrak tetap berlaku; kurator hanya tidak berkewajiban untuk melaksanakan kontrak, dan pihak lawan tetap memiliki klaim dalam kepailitan berdasarkan pasal 37a Fw.
Untuk perangkat lunak, ini berarti wali amanat dapat menolak pemeliharaan, dukungan, pembaruan, hosting, dan deposit lebih lanjut: tindakan aktif yang membebani harta warisan. Harapkan penolakan. Pertanyaannya adalah apakah hal itu dapat berlanjut lebih jauh dan menghentikan Anda menggunakan apa yang sudah Anda miliki.
Nebula, berzona dan Credit Suisse/Jongepier
Selama satu dekade, hal ini benar-benar tidak pasti. Dalam kasus Nebula (Hoge Raad, 3 November 2006, ECLI:NL:HR:2006:AX8838), Mahkamah Agung memutuskan bahwa meskipun kebangkrutan itu sendiri tidak mengakhiri perjanjian yang ada, pihak lawan yang memegang hak penggunaan tidak dapat terus menggunakan hak tersebut terhadap kurator seolah-olah tidak terjadi kebangkrutan; hal itu akan memungkinkan satu kreditur untuk mengabaikan kebangkrutan dengan mengorbankan kreditur lainnya. Hal ini secara luas ditafsirkan sebagai mengizinkan kurator untuk mengesampingkan hak penggunaan yang sudah ada sebelumnya, dan hal itu membuat para pemegang lisensi khawatir.
Interpretasi tersebut tidak bertahan lama. Dalam kasus ABN AMRO/Berzona (Hoge Raad, 11 Juli 2014, ECLI:NL:HR:2014:1681), Mahkamah Agung memutuskan bahwa kepailitan tidak berpengaruh pada perjanjian timbal balik yang ada atau kewajiban yang timbul darinya, dan tidak memberikan wewenang kepada kurator yang tidak diberikan oleh hukum atau kontrak — misalnya, kurator tidak dapat mengakhiri perjanjian sewa yang masih berlaku.
Posisi tersebut telah ditetapkan dalam kasus Credit Suisse/Jongepier qq (Hoge Raad, 23 Maret 2018, ECLI:NL:HR:2018:424). Kurator dapat secara pasif menolak untuk melakukan kewajibannya, tetapi kepailitan tidak memberikan wewenang kepadanya untuk membatalkan kewajiban yang telah dilakukan oleh debitur sebelum kepailitan, atau untuk mengakhiri kewajiban yang berkelanjutan sejauh kewajiban tersebut berupa toleransi atau penahanan diri dari sesuatu.
Frasa itulah yang penting untuk perangkat lunak. Pada dasarnya, lisensi adalah sebuah komitmen dari pemegang hak untuk mentolerir penggunaan yang jika tidak akan melanggar hak cipta — sebuah kinerja berkelanjutan yang terdiri dari toleransi. Oleh karena itu, berdasarkan hukum yang berlaku saat ini, lisensi yang diberikan secara sah sebelum kebangkrutan tetap berlaku, dan kurator tidak dapat mencabutnya. Kurator dapat menolak semua yang aktif, tetapi tidak dapat mematikan hak penggunaan yang Anda miliki.
Apa artinya itu bagi kesepakatan Anda?
Ada dua hal yang perlu diperhatikan. Pertama, pertahankan kewajiban pelepasan pada agen escrow, bukan pada pemasok: karena diatur sebagai penyimpanan independen yang dipegang oleh pihak ketiga, pelepasan tersebut merupakan kinerja agen itu sendiri, dan kekuasaan wali amanat berdasarkan pasal 37 Fw berlaku pada kinerja yang harus dipenuhi oleh harta warisan, bukan pada agen yang mampu membayar, sedangkan janji dua pihak membutuhkan kinerja dari harta warisan, yang dapat ditolak oleh wali amanat. Kedua, berikan lisensi di muka, bukan pada saat pelepasan — poin penyusunan yang paling penting, yang akan dibahas di bawah ini.
Dalam restrukturisasi, bukan kebangkrutan, pasal 373 Fw membatasi ketergantungan pada klausul ipso facto — ketentuan yang memungkinkan pihak lawan untuk mengubah, menangguhkan, atau mengakhiri kontrak hanya karena prosedur restrukturisasi telah dimulai. Pembatasan itu berlaku dalam prosedur skema, bukan dalam kebangkrutan, dan jawabannya sekali lagi bersifat struktural: jika pengaturan tersebut dirancang sebagai penitipan independen oleh pihak ketiga, pemicu pelepasan berlaku pada kewajiban agen itu sendiri dan tidak sama dengan ketentuan ipso facto yang dapat dibatalkan, baik dalam restrukturisasi WHOA maupun dalam kebangkrutan.
Bagaimana lisensi tersebut harus disusun
Layanan escrow memberi Anda salinan kode sumber, bukan hak untuk melakukan apa pun dengannya. Kode sumber adalah karya yang dilindungi; mengkompilasinya, memodifikasinya, dan menjalankan hasilnya adalah tindakan yang dibatasi. Tanpa lisensi yang mencakupnya, deposit yang dilepaskan hanyalah sebuah folder yang tidak boleh Anda buka. Gabungkan layanan escrow dengan lisensi yang secara tegas mengizinkan pelanggan, setelah pelepasan, untuk menggunakan, mengkompilasi, memodifikasi, dan mengembangkan lebih lanjut kode sumber tersebut, dan untuk meminta pihak ketiga melakukannya — dalam praktiknya Anda tidak akan melakukan pekerjaan itu sendiri.
Kemudian soal waktu. Lisensi yang diberikan saat pembebasan itu rapuh. Jika peristiwa pembebasan itu adalah kebangkrutan itu sendiri, pemberian lisensi harus dilakukan oleh debitur yang, sejak hari penetapan perintah kebangkrutan, telah kehilangan wewenang untuk mengelola aset dalam harta kekayaan; pasal 23 Fw dan pasal 35 Fw menghalangi, dan kurator tidak akan memberikan lisensi untuk Anda. Credit Suisse/Jongepier berarti kurator tidak dapat mencabut lisensi yang sudah Anda miliki — tetapi tidak ada yang perlu dicabut jika Anda tidak pernah memilikinya.
Berikan hak tersebut dalam kontrak itu sendiri, sebelum terjadi kepailitan, dengan syarat pendahuluan: diberikan sekarang, dan berlaku setelah terjadi peristiwa pelepasan. Hak tersebut ada sejak tanggal kontrak; hanya efeknya yang ditangguhkan. Hukum Belanda umumnya menerima struktur ini. Dalam kasus Rabobank/Reuser (Hoge Raad, 3 Juni 2016, ECLI:NL:HR:2016:1046), Mahkamah Agung menerima bahwa jika hak bersyarat dibuat sebelum kepailitan, pemenuhan syarat tersebut kemudian berlaku tanpa tindakan lebih lanjut dari debitur. Kasus tersebut menyangkut pengalihan barang bersyarat dan gadai atas hak bersyarat tersebut. Menerapkannya pada lisensi hak cipta yang diberikan secara bersyarat merupakan ekstrapolasi yang didukung dalam literatur hukum dan bukan poin yang telah ditetapkan oleh pengadilan, dan harus disajikan sebagaimana adanya.
Konfirmasikan juga bahwa penggunaan materi yang dirilis tidak memerlukan persetujuan lebih lanjut dari pemasok atau walinya, dan bahwa pemberian sub-lisensi kepada pengembang penerus diperbolehkan.
SaaS dan komputasi awan: kode sumber saja tidak cukup.
Untuk perangkat lunak yang Anda jalankan sendiri, kode sumber ditambah petunjuk pembuatan ditambah lisensi sudah hampir menjadi solusi lengkap. Namun untuk layanan, tidak demikian. Jika platform penyedia layanan mengalami gangguan, Anda akan kehilangan aplikasi, lingkungan tempat aplikasi tersebut berjalan, dan data Anda — dan kode sumber hanya memulihkan yang pertama, itupun secara perlahan. Pengaturan keberlanjutan SaaS harus menambahkan tiga hal:
- Lingkungan operasional. Citra kontainer, definisi infrastruktur sebagai kode, konfigurasi, pengaturan jaringan dan keamanan, dependensi runtime — cukup untuk membangun platform di tempat lain.
- Datanya. Ekspor data Anda sendiri secara berkala dalam format yang terdokumentasi dan bukan milik pribadi, beserta skemanya. Data yang tidak dapat Anda baca bukanlah data yang Anda miliki, dan ekspor harus dilakukan selama masa kontrak, bukan hanya saat rilis.
- Hubungan tuan rumah. Suatu cara untuk masuk ke dalam kontrak pemasok dengan penyedia hosting-nya, atau pemberitahuan kepada penyedia tersebut bahwa Anda dapat mengambil alih akun dan membayar langsung.
Alternatif, dan siapa yang membayar
Layanan escrow tidak selalu memberikan nilai terbaik, terutama untuk produk standar di mana Anda adalah satu pelanggan di antara ribuan pelanggan lainnya dan risiko realistisnya adalah penghentian layanan daripada kegagalan. Tiga opsi yang lebih ringan seringkali lebih bermanfaat: hak keluar data — ekspor berkala dalam format terdokumentasi, diuji setidaknya sekali — mencakup sebagian besar risiko dengan biaya yang hampir nol; hak atas salinan yang berjalan , citra yang dapat Anda jalankan untuk periode transisi, memulihkan layanan jauh lebih cepat daripada membangun ulang; dan pembayaran langsung ke penyedia hosting , menjaga lingkungan tetap berjalan saat Anda bermigrasi — kontinuitas cloud termurah, dan paling sering diabaikan.
Jika Anda menggunakan layanan escrow, perkirakan akan ada biaya pengaturan satu kali, biaya penyimpanan tahunan yang berulang, dan biaya terpisah per verifikasi yang meningkat sesuai dengan kedalaman pemeriksaan. Biaya ditanggung oleh siapa pun yang menginginkan perlindungan, biasanya pelanggan, meskipun pemasok yang menawarkan escrow sebagai nilai jual mungkin menanggungnya, dan pengaturan multi-penerima manfaat yang mencakup beberapa pelanggan dari satu produk akan menyebarkannya—titik akhir yang biasanya membuat pemasok menolak. Jadikan gagal bayar sebagai sesuatu yang harus diberitahukan agen kepada Anda, dengan hak untuk membayar sebagai gantinya.
Daftar periksa untuk menegosiasikan pengaturan escrow
- Apakah ini merupakan kesepakatan tiga pihak yang sah dengan agen independen yang memiliki kewajiban untuk memberikan persetujuan langsung kepada Anda?
- Apakah lisensi untuk menggunakan, mengkompilasi, memodifikasi, dan mengembangkan lebih lanjut kode sumber telah diberikan? sekarang, dengan syarat tertentu terlebih dahulu, bukan dijanjikan saat rilis?
- Apakah daftar deposit mencakup petunjuk pembuatan, dependensi, kunci lisensi, dan dokumentasi, bukan hanya kode sumber, yang diperbarui pada setiap rilis?
- Tingkat verifikasi apa yang dikontrakkan, dan seberapa sering verifikasi tersebut diulang?
- Apakah peristiwa pelepasan dapat ditentukan dari dokumen atau berlalunya waktu, dengan periode keberatan yang singkat dan jalur penyelesaian sengketa yang cepat?
- Untuk SaaS: apakah lingkungan, data, dan hubungan hosting tercakup, atau hanya kodenya saja?
- Siapa yang membayar, apa yang terjadi jika pemasok berhenti membayar, dan apakah perjanjian escrow sesuai dengan hukum yang berlaku dan klausul kekayaan intelektual dalam kontrak utama?
Bisakah kurator kepailitan Belanda menghentikan agen penjaminan untuk merilis kode sumber?
Tidak secara langsung. Dalam pengaturan tiga pihak, kewajiban pelepasan terutang kepada Anda oleh agen penjamin berdasarkan kontraknya sendiri, dan agen tersebut tidak bangkrut. Kekuasaan wali amanat berdasarkan pasal 37 Fw adalah untuk menolak pelaksanaan kewajiban yang terutang oleh harta warisan, bukan untuk menginstruksikan agen. Itulah alasan utama untuk lebih memilih pengaturan tiga pihak daripada janji pemasok.
Apakah lisensi perangkat lunak saya tetap berlaku jika pemasoknya bangkrut?
Lisensi yang diberikan secara sah sebelum kebangkrutan tetap berlaku, dan kurator tidak dapat mencabutnya. Dalam kasus Credit Suisse/Jongepier qq (Hoge Raad, 23 Maret 2018, ECLI:NL:HR:2018:424), Mahkamah Agung menegaskan bahwa kurator tidak dapat mengakhiri kinerja berkelanjutan yang terdiri dari toleransi atau penahanan diri, dan lisensi adalah kinerja tersebut. Kurator dapat menolak semua hal yang aktif: pemeliharaan, dukungan, pembaruan, hosting.
Apakah putusan Nebula masih menjadi ancaman bagi para pemegang lisensi?
Bukan dalam bentuk yang pernah dikhawatirkan. Nebula (Hoge Raad, 3 November 2006, ECLI:NL:HR:2006:AX8838) secara luas ditafsirkan sebagai mengizinkan wali amanat untuk mengabaikan hak penggunaan yang ada. Berzona dan Credit Suisse/Jongepier membatasi penafsiran tersebut. Wali amanat dapat menolak untuk melaksanakan kewajibannya, tetapi tidak memiliki kekuasaan yang tidak diberikan oleh hukum atau kontrak, dan pencabutan lisensi bukanlah kekuasaan tersebut.
Mengapa pemberian lisensi hanya pada saat rilis menjadi masalah?
Karena pemberian izin harus dilakukan setelah kebangkrutan, ketika debitur telah kehilangan wewenang untuk mengelola aset harta kekayaan dan kurator tidak memiliki kewajiban untuk bertindak atas nama Anda. Yurisprudensi melindungi izin yang sudah Anda miliki; yurisprudensi tersebut tidak menciptakan izin baru. Berikan izin tersebut sekarang, dengan syarat adanya ketentuan pendahuluan yang berlaku setelah pelepasan izin.
Apakah layanan escrow membantu dalam berurusan dengan pemasok SaaS?
Hanya sebagian. Kode sumber tidak dapat mengembalikan layanan yang sedang berjalan. Pengaturan SaaS yang layak juga harus mencakup lingkungan operasional — citra kontainer, definisi infrastruktur, konfigurasi — ekspor data Anda secara berkala dalam format yang terdokumentasi, dan jalur untuk mengambil alih atau membayar penyedia hosting. Tanpa itu, Anda hanya akan mendapatkan proyek pembangunan ulang, bukan keberlanjutan.
Apakah verifikasi benar-benar layak dibayar?
Ya, di tingkat menengah. Pemeriksaan tingkat file hanya mengkonfirmasi bahwa sesuatu telah sampai. Tinjauan kelengkapan terhadap instruksi pembuatan dan daftar dependensi menangkap kegagalan yang penting — langkah pembuatan yang hilang, dependensi yang tidak terdokumentasi, komponen yang tidak berhak Anda gunakan. Pembuatan dan pengujian lengkap adalah satu-satunya pilihan yang meyakinkan, sepadan dengan biayanya jika terjadi gangguan yang dapat berakibat fatal.

