Kepemilikan Source Code Aplikasi: Klausul yang Harus Ada Sebelum Kontrak Ditandatangani

Pertanyaan soal kepemilikan source code biasanya baru muncul ketika hubungan dengan vendor sudah tidak baik: vendor sulit dihubungi, biaya perubahan kecil terasa mahal, atau aplikasi harus dipindah ke tim lain. Pada saat itu jawabannya sudah ditentukan oleh kontrak yang ditandatangani berbulan-bulan sebelumnya, dan sering kali kontrak itu tidak mengatakan apa-apa.

Jawaban singkatnya: membayar pembuatan aplikasi tidak otomatis menjadikan Anda pemilik kodenya. Pasal 36 UU Nomor 28 Tahun 2014 tentang Hak Cipta menyatakan bahwa, kecuali diperjanjikan lain, pencipta dan pemegang hak cipta atas ciptaan yang dibuat berdasarkan pesanan adalah pihak yang membuat ciptaan. Program komputer termasuk ciptaan yang dilindungi (Pasal 40 ayat 1 huruf s). Jadi kepemilikan source code harus ditulis dengan jelas di kontrak. Artikel ini merangkum apa yang perlu ditulis, apa yang memang tidak bisa Anda miliki, dan cara memeriksa serah terimanya.

Catatan: tulisan ini adalah panduan praktis dari sisi proyek, bukan nasihat hukum. Untuk kontrak bernilai besar, libatkan konsultan hukum Anda.

Mengapa kepemilikan source code menentukan nasib aplikasi

Aplikasi yang kodenya tidak Anda kuasai sebenarnya bukan aset, melainkan langganan yang tidak tertulis. Dampaknya terasa di beberapa tempat:

• Berganti vendor. Tanpa kode dan hak untuk mengubahnya, pindah vendor berarti membangun ulang dari nol.
• Perbaikan keamanan. Celah keamanan hanya bisa ditutup oleh satu pihak, dengan jadwal dan harga yang ditentukan pihak itu.
• Pengembangan berikutnya. Fitur baru, integrasi dengan sistem lain, atau perpindahan server selalu harus lewat vendor yang sama.
• Penilaian usaha. Investor, mitra, atau calon pembeli usaha akan menanyakan siapa pemilik sistem inti perusahaan.

Kepemilikan, lisensi, dan akses: tiga hal yang sering dicampur

Banyak sengketa berawal dari anggapan bahwa ketiga hal ini sama.

Kepemilikan berarti hak ekonomi atas kode beralih kepada Anda. Anda boleh mengubah, memperbanyak, dan menyerahkan kode itu ke vendor lain untuk dirawat.

Lisensi berarti Anda boleh memakai kode dengan batas tertentu, sementara haknya tetap pada pembuat. Lisensi bisa sangat longgar atau sangat sempit, tergantung bunyinya.

Akses berarti Anda memegang salinan kode. Memegang salinan tanpa hak untuk mengubahnya tidak banyak menolong, dan memegang hak tanpa salinan yang lengkap juga sama saja. Kontrak yang baik mengatur ketiganya sekaligus.

Bagian aplikasi yang memang tidak bisa Anda miliki

Tidak semua baris kode dalam aplikasi ditulis khusus untuk Anda. Wajar jika sebagian hanya dilisensikan, asalkan jelas.

• Komponen open source. Hampir semua aplikasi modern memakai pustaka open source. Komponen itu tunduk pada lisensinya masing-masing. Minta daftar komponen beserta jenis lisensinya, karena beberapa lisensi membawa kewajiban tertentu bila aplikasi didistribusikan.
• Kerangka kerja milik vendor. Vendor sering memakai modul yang mereka bangun sendiri dan pakai di banyak proyek. Modul seperti ini wajar dilisensikan, bukan dialihkan. Pastikan lisensinya permanen, tidak bisa dicabut, dan boleh dipakai oleh pihak lain yang merawat aplikasi Anda kelak.
• Layanan pihak ketiga. Payment gateway, layanan peta, API pesan, atau model AI bukan milik siapa pun di antara Anda dan vendor. Yang perlu dipastikan adalah akun dan kontraknya atas nama perusahaan Anda.

Klausul kepemilikan source code yang perlu ada di kontrak

Gunakan daftar ini saat membaca draf kontrak dari vendor mana pun.

1. Pengalihan hak atas kode yang dibuat khusus. Tulis bahwa hak ekonomi atas kode kustom, desain basis data, dan dokumentasi beralih kepada klien, serta kapan peralihan itu terjadi.
2. Daftar pengecualian. Komponen open source dan modul milik vendor disebutkan, lengkap dengan lisensinya.
3. Lisensi atas modul vendor. Permanen, tidak dapat dicabut, mencakup hak modifikasi, dan boleh dipakai oleh pihak ketiga yang ditunjuk klien.
4. Isi serah terima. Repositori lengkap dengan riwayat perubahan, skrip build dan deploy, konfigurasi, skema dan migrasi basis data, serta dokumentasi teknis.
5. Akun atas nama klien. Domain, server atau akun cloud, akun toko aplikasi, dan akun layanan pihak ketiga didaftarkan atas nama perusahaan Anda sejak awal.
6. Jaminan orisinalitas. Vendor menjamin kode yang diserahkan tidak melanggar hak pihak lain dan bertanggung jawab bila ternyata melanggar.
7. Kondisi bila vendor berhenti beroperasi. Misalnya kewajiban menyerahkan kode lebih awal, atau penyimpanan kode pada pihak ketiga yang netral (escrow) untuk sistem yang sangat kritis.
8. Batas pemakaian ulang. Vendor tetap boleh memakai keahlian umumnya, tetapi tidak boleh menjual ulang logika bisnis atau data yang khas milik Anda.

Kapan hak beralih: sejak ditulis atau setelah pelunasan

Praktik yang umum adalah hak beralih setelah pelunasan. Ini adil bagi kedua pihak: vendor terlindungi dari klien yang tidak membayar, dan klien tahu persis kapan kode menjadi miliknya.

Agar Anda tidak menunggu dalam gelap sampai akhir proyek, minta akses baca ke repositori selama proyek berjalan. Dengan begitu kemajuan bisa dilihat di setiap termin, dan serah terima di akhir hanya memindahkan hak, bukan membuka kotak yang belum pernah Anda lihat.

Sebagai contoh, pada lini Enterprise Software Etzal Group, source code menjadi milik klien saat pelunasan, diserahkan bersama dokumentasi dan garansi 30 hari, lalu dilanjutkan dengan masa maintenance. Apa pun vendor yang Anda pilih, minta urutan seperti ini ditulis di kontrak.

Checklist serah terima source code

Serah terima yang baik bisa diuji, bukan sekadar ditandatangani.

• Repositori dipindah ke akun organisasi milik Anda, bukan dikirim sebagai file zip.
• Orang di luar tim vendor bisa membangun dan menjalankan aplikasi dari nol hanya dengan mengikuti dokumentasi.
• Semua kata sandi, kunci API, dan token dipindah ke pengelolaan Anda, lalu diganti dengan yang baru.
• Skema basis data, skrip migrasi, dan cadangan terakhir tersedia dan pernah dicoba dipulihkan.
• Dokumentasi memuat arsitektur, cara deploy, daftar integrasi, dan daftar komponen beserta lisensinya.
• Anda memegang akses admin ke server, domain, dan semua layanan pihak ketiga.

Jika satu poin di atas belum terpenuhi, catat di berita acara sebagai kekurangan dengan tenggat penyelesaian.

Kesalahan yang sering terjadi

Kontrak hanya berbunyi "aplikasi menjadi milik klien". Kalimat ini tidak menyebut source code, dokumentasi, maupun akun, sehingga mudah ditafsirkan sempit.

Server dan domain atas nama vendor. Ini paling sering menjadi masalah ketika hubungan berakhir, karena aplikasi bisa berhenti meski kodenya sudah Anda pegang.

Serah terima tidak pernah diuji. Kekurangan baru ketahuan ketika vendor sudah pindah ke proyek lain dan tidak lagi punya waktu.

Tidak membedakan kode kustom dan modul vendor. Akibatnya kedua pihak sama-sama merasa berhak atas bagian yang sama.

Untuk menyiapkan semua ini sejak awal, mulailah dari brief yang rapi. Panduan menulis brief proyek software membantu agar klausul kepemilikan ikut dibandingkan saat Anda menerima penawaran.

Jika aplikasi Anda sudah telanjur tanpa klausul ini

Masih ada jalan. Selagi hubungan dengan vendor baik, ajukan addendum yang mengatur pengalihan hak dan isi serah terima. Paling tidak, minta akses baca ke repositori dan dokumentasi yang memadai. Jika vendor sudah tidak bisa dihubungi, jalurnya adalah mengambil alih sistem secara bertahap; langkahnya kami bahas di panduan migrasi sistem lama.

Bila Anda sedang menimbang kontrak pembuatan aplikasi dan ingin pembacaan dari sisi teknis, gunakan sesi konsultasi gratis kami.