Siapa Pemilik Kodenya? Klausul IP yang Wajib Ada di Kontrak Klien

Siapa Pemilik Kodenya? Klausul IP yang Wajib Ada di Kontrak Klien

Lima klausul mencegah nyaris semua sengketa kepemilikan kode: model kepemilikan yang disebut eksplisit, carve-out toolkit (bagian yang dikecualikan dari penyerahan hak), aliran kewajiban open-source, escrow atau padanannya (titipan kode di pihak netral), dan transfer yang terikat pembayaran. Tanpa lima ini, kontrak diam soal siapa pemilik apa — dan diam itu yang paling mahal ujungnya. (Catatan standar: ini panduan praktik engineering, bukan nasihat hukum. Minta pengacara menyusun redaksi finalnya.)

Setiap proyek software freelance menghasilkan kekayaan intelektual. Kebanyakan kontrak yang saya review entah tidak menyebut siapa pemiliknya, atau menyebutnya terlalu luas sampai salah satu pihak dirugikan berat. Sengketanya bisa ditebak: klien menemukan konsultan memakai ulang "kode mereka" di proyek lain, atau konsultan sadar sudah menyerahkan toolkit yang ia bangun bertahun-tahun.

Keduanya kegagalan kontrak. Keduanya bisa dicegah dengan segelintir klausul.

Assignment atau license — putuskan dengan sadar

Ada dua model yang bersih, dan kontrak harus menyebut salah satunya.

Full assignment (work-for-hire). Klien memiliki copyright sepenuhnya; konsultan tidak menyimpan hak apa pun atas kode yang diserahkan. Ini yang diasumsikan kebanyakan klien saat membayar. Untuk logika bisnis yang dibuat khusus, ini biasanya jawaban yang benar — mereka membayarnya, kode itu memuat proses mereka, mereka pemiliknya.

License grant. Konsultan memiliki kodenya dan klien menerima lisensi — perpetual dan irrevocable kalau kliennya bijak, kadang eksklusif di industri mereka. Model ini cocok untuk konsultansi terproduktisasi: engine yang sama dikirim ke banyak klien, dikonfigurasi per proyek.

Kontrak bermasalah bukan karena memilih salah satu model, tapi karena tidak memilih. "Konsultan akan mengembangkan software untuk Klien" tidak berkata apa-apa soal kepemilikan. Default hukumnya berbeda-beda antar yurisdiksi, dengan cara yang tidak ingin ditemukan kedua pihak di pengadilan.

Carve-out untuk toolkit

Bayangkan tukang bangunan yang bawa kotak perkakas sendiri ke tiap proyek. Rumah yang ia bangun jadi milik pemilik rumah, tapi gergaji dan bornya tetap miliknya, dibawa pulang untuk proyek berikutnya. Aturan yang sama berlaku untuk kode konsultan.

Tidak ada konsultan yang menulis dari halaman kosong. Setiap delivery memuat material yang sudah ada sebelumnya — library utilitas, scaffolding deployment, modul auth yang dipoles lintas belasan proyek. Klausul naif "seluruh deliverable di-assign ke Klien" ikut meng-assign toolkit itu. Konsultan secara teknis kehilangan hak memakai peralatannya sendiri di proyek berikutnya.

Perbaikan standarnya adalah carve-out: IP yang sudah ada sebelumnya tetap milik konsultan, dan klien menerima lisensi perpetual, non-eksklusif, bebas royalti atas bagian itu sebagaimana tertanam di deliverable. Klien tidak kehilangan apa pun — tetap bisa menjalankan, memodifikasi, dan merawat seluruh sistem. Konsultan tetap bisa berbisnis.

Klausul ini cuma bekerja kalau "pre-existing IP" bisa diidentifikasi. Daftarkan komponennya di lampiran, atau simpan di repository terpisah yang bisa dirujuk kontrak.

Kewajiban open-source ikut mengalir

Sebagian besar isi deliverable modern adalah kode open-source yang tidak dimiliki kedua pihak. Anda tidak bisa meng-assign apa yang bukan milik Anda. Kontrak harus menyatakan tiga hal: komponen pihak ketiga tetap tunduk pada lisensinya masing-masing, konsultan menyerahkan inventaris dependency, dan kewajiban kepatuhannya berpindah ke klien bersama software-nya.

Ini paling penting saat klien akan mendistribusikan ulang atau menjual. Dependency copyleft yang tidak berbahaya di tool internal berubah jadi batasan nyata di produk yang dirilis. Kategori dan jebakannya saya bahas di lisensi open-source di software komersial.

Kalau deliverable-nya sendiri akan dirilis sebagai produk, strategi lisensi klien layak diputuskan, bukan dibiarkan default. Lihat memilih lisensi untuk produk Anda.

Escrow untuk ketakutan vendor menghilang

Klien yang berpengalaman melontarkan pertanyaan yang tidak enak: bagaimana kalau Anda tutup usaha atau berhenti membalas pesan? Untuk konsultansi kecil, ketakutan itu rasional. Jawaban klasiknya source-code escrow — kode, instruksi build, dan dokumentasi deployment dititipkan ke pihak ketiga netral, dilepas ke klien pada pemicu yang terdefinisi: pailit, proyek ditelantarkan, atau gagal memberi dukungan berkepanjangan.

Untuk kebanyakan proyek freelance, escrow formal berlebihan. Padanan pragmatisnya lebih sederhana: source lengkap plus dokumentasi diserahkan di setiap milestone, ke repository yang dikendalikan klien. Klien sudah memegang semua yang akan dilepas escrow. Tuliskan itu di kontrak — ketakutan berubah jadi fitur yang tercantum.

Ikat transfer ke pembayaran

Assignment sebaiknya berlaku saat pembayaran lunas, bukan saat kode diserahkan. Sebelum itu, klien memegang lisensi untuk evaluasi dan pengujian. Ini klausul yang adil, bukan agresif: klien yang sudah membayar penuh memiliki semuanya begitu ia membayar, klien yang belum membayar tidak memiliki pekerjaan yang belum ia beli.

Bagi konsultan, ini juga satu-satunya daya tawar nyata terhadap gagal bayar yang tidak melibatkan pengacara. Kepemilikan mengikuti uang, otomatis, ke arah mana pun.

Lima klausulnya, ringkas

1. Model kepemilikan yang disebut eksplisit — assignment untuk pekerjaan bespoke, license untuk pekerjaan terproduktisasi.
2. Carve-out toolkit — pre-existing IP tetap milik konsultan, dilisensikan ke klien.
3. Aliran kewajiban open-source — inventaris diserahkan, kewajiban upstream diakui.
4. Escrow atau padanannya — source dan dokumentasi di tangan klien di setiap milestone.
5. Transfer terikat pembayaran — kepemilikan berpindah saat uangnya berpindah.

Tidak satu pun klausul ini memihak. Semuanya ada karena alternatifnya — diam — pada akhirnya lebih mahal bagi kedua pihak daripada biaya menyusunnya.