Lisensi Open Source dan Kepemilikan Kode di Proyek Software Bisnis: Yang Perlu Diperiksa Sebelum Terlambat

Hampir setiap aplikasi bisnis modern dibangun di atas komponen open source. Kerangka kerja web, pustaka antarmuka, basis data, alat pembangun, hingga bagian kecil seperti pembuat PDF sering berasal dari proyek yang lisensinya terbuka. Itu hal yang baik: biaya turun dan pengembangan lebih cepat. Namun di balik itu ada dua pertanyaan hukum yang sering baru muncul saat terlambat: apa kewajiban kita terhadap lisensi komponen yang dipakai, dan siapa sebenarnya pemilik kode yang dibuat vendor untuk kita?

Pertanyaan itu menjadi sangat nyata ketika perusahaan ingin menjual atau menggandeng investor, menjalani uji tuntas, berpindah vendor, atau sekadar menjual produk software kepada pelanggan. Artikel ini membahas dasar lisensi open source dalam bahasa bisnis, perbedaan kepemilikan dan lisensi, klausul kontrak yang perlu diperiksa, serta kebiasaan sederhana untuk menjaga kode Anda bersih secara hukum. Artikel ini bukan nasihat hukum; untuk keputusan penting, libatkan penasihat hukum yang memahami kekayaan intelektual.

Ringkasan

• Open source bukan berarti bebas aturan: setiap komponen punya lisensi dengan kewajiban yang berbeda, mulai dari sekadar mencantumkan atribusi hingga membuka kode sendiri
• Lisensi permisif seperti MIT, BSD, dan Apache 2.0 umumnya aman untuk produk komersial; lisensi copyleft kuat seperti GPL dan AGPL memerlukan perhatian khusus
• Kepemilikan kode kustom tidak otomatis beralih kepada pembayar, kecuali kontrak menyatakannya; periksa klausul hak kekayaan intelektual sebelum proyek dimulai
• Minta daftar komponen (software bill of materials) dan laporan lisensi dari vendor, dan simpan sebagai bagian dari dokumentasi proyek
• Kebiasaan kecil seperti kebijakan lisensi yang disetujui, pemindaian otomatis, dan pencatatan atribusi mencegah masalah mahal saat uji tuntas

Open source bukan berarti tanpa aturan

Istilah open source sering disalahpahami sebagai gratis dan bebas dipakai untuk apa saja. Yang benar, kode open source dirilis dengan lisensi, yaitu perjanjian yang memberi hak tertentu dengan syarat tertentu. Anda boleh memakainya, sering kali untuk tujuan komersial, tetapi harus memenuhi syaratnya. Melanggar syarat itu dapat berarti kehilangan hak pakai, tuntutan hukum, atau kewajiban membuka kode milik Anda sendiri.

Karena aplikasi modern memuat ratusan bahkan ribuan komponen, termasuk komponen yang dibawa komponen lain (dependensi turunan), tidak ada orang yang dapat mengingat semuanya. Itulah sebabnya pengelolaan lisensi perlu menjadi proses, bukan ingatan seseorang. Pembahasan terkait aspek keamanan dari komponen pihak ketiga ada pada artikel tentang keamanan dependensi dan rantai pasok perangkat lunak; lisensi adalah sisi hukum dari masalah yang sama.

Tiga keluarga lisensi yang perlu dikenal

Ada ratusan lisensi, tetapi untuk keputusan bisnis, cukup memahami tiga kelompok besar dan implikasinya. Uraian berikut bersifat umum; teks lisensi yang berlaku selalu yang menentukan.

1. Lisensi permisif

Contohnya MIT, BSD, dan Apache 2.0. Lisensi ini memberi kebebasan luas: Anda boleh memakai, mengubah, dan mendistribusikan kode, termasuk dalam produk komersial berkode tertutup. Kewajiban utamanya biasanya mencantumkan pemberitahuan hak cipta dan teks lisensi. Apache 2.0 juga memuat pemberian lisensi paten yang melindungi pengguna dari klaim paten kontributor. Kelompok ini umumnya paling mudah dan paling aman bagi bisnis.

2. Lisensi copyleft lemah

Contohnya LGPL dan MPL. Jika Anda mengubah komponen itu sendiri, perubahan tersebut harus dibagikan di bawah lisensi yang sama, tetapi kode Anda yang hanya memakainya sebagai pustaka dapat tetap tertutup, dengan syarat tertentu mengenai cara penautan. Diperlukan kehati-hatian dalam cara komponen dihubungkan ke aplikasi.

3. Lisensi copyleft kuat

Contohnya GPL dan AGPL. Prinsipnya, jika Anda memasukkan komponen ini ke dalam produk yang Anda distribusikan, produk tersebut secara keseluruhan harus tunduk pada lisensi yang sama dan kode sumbernya perlu disediakan. AGPL memperluas ini ke software yang dijalankan sebagai layanan jaringan: pengguna layanan Anda dapat berhak meminta kode sumber. Bagi perusahaan yang menjual produk atau menjalankan platform SaaS, komponen GPL atau AGPL yang masuk tanpa disadari dapat menjadi masalah besar. Bukan berarti dilarang, tetapi harus menjadi keputusan yang disengaja dan ditinjau.

Di luar tiga kelompok ini ada pula lisensi sumber tersedia (source available) dan lisensi dengan batasan penggunaan komersial, yang kadang tampak seperti open source padahal membatasi cara pemakaian. Baca lisensinya, jangan hanya mengandalkan label.

Perbedaan antara kepemilikan dan lisensi

Dua konsep ini sering tercampur dan menjadi sumber sengketa di proyek software kustom.

• Kepemilikan hak cipta: siapa pemegang hak atas kode sebagai karya. Secara umum, hak cipta atas kode pada awalnya berada pada penciptanya, atau pada perusahaan pembuat bila dibuat oleh karyawan dalam hubungan kerja, kecuali ada perjanjian lain
• Lisensi: izin untuk memakai kode, yang dapat diberikan tanpa mengalihkan kepemilikan, dan dapat eksklusif atau nonekslusif, terbatas waktu, wilayah, atau tujuan

Akibatnya, ketika Anda membayar vendor untuk membuat aplikasi, tidak otomatis kode itu menjadi milik Anda. Bila kontrak diam, vendor bisa tetap memegang hak ciptanya dan Anda hanya memperoleh izin pakai yang cakupannya tidak jelas. Itu cukup untuk menjadi masalah ketika Anda ingin mengubah aplikasi sendiri, pindah vendor, atau menjual perusahaan. Topik ini bersinggungan dengan poin penting dalam kontrak pengembangan software dan cara memilih software house.

Klausul kontrak yang perlu diperiksa

Saat membaca atau bernegosiasi kontrak pengembangan, perhatikan hal-hal berikut. Konsultasikan dengan penasihat hukum untuk rumusan yang tepat.

• Pengalihan hak: apakah hak cipta atas hasil pekerjaan dialihkan kepada Anda setelah pembayaran lunas, dan sejak kapan
• Cakupan hasil kerja: apakah termasuk kode sumber lengkap, skrip pembangunan, dokumentasi, desain, dan konfigurasi, bukan hanya aplikasi jadi
• Komponen bawaan vendor: apakah vendor memakai pustaka internal atau kerangka kerja miliknya sendiri yang tidak ikut dialihkan, dan bagaimana lisensi atas komponen itu
• Komponen pihak ketiga: kewajiban vendor menyatakan komponen open source dan komersial yang dipakai beserta lisensinya
• Jaminan: pernyataan vendor bahwa kode tidak melanggar hak pihak lain dan tidak memuat kode yang melanggar lisensi
• Ganti rugi: siapa menanggung bila muncul klaim pelanggaran hak kekayaan intelektual
• Penyimpanan kode: kewajiban menyerahkan kode ke repositori yang Anda kendalikan, bukan hanya di akun vendor
• Keberlanjutan: akses ke kode dan dokumentasi bila vendor berhenti beroperasi atau hubungan berakhir

Jika vendor ingin menggunakan kembali sebagian kode untuk klien lain, hal itu dapat disepakati secara eksplisit, misalnya dengan lisensi ke vendor atas komponen generik dan pemisahan yang jelas dari logika bisnis khusus Anda. Yang penting adalah tertulis, bukan diasumsikan.

Daftar komponen: dasar semua pengelolaan lisensi

Software bill of materials (SBOM) adalah daftar semua komponen yang membentuk aplikasi, lengkap dengan versi dan lisensinya. Dokumen ini makin sering diminta pelanggan korporasi, auditor, dan regulator, karena berguna untuk dua hal sekaligus: menilai kepatuhan lisensi dan mengetahui apakah aplikasi terdampak saat kerentanan baru diumumkan.

Hal yang dapat Anda minta dari vendor atau tim internal:

• Daftar dependensi langsung dan turunan beserta versi
• Lisensi masing-masing komponen, dengan tanda khusus untuk lisensi copyleft dan lisensi yang tidak dikenal
• Teks lisensi dan pemberitahuan atribusi yang wajib dipenuhi
• Catatan komponen yang dimodifikasi atau di-fork
• Pembaruan daftar ini pada setiap rilis besar

Alat pemindai otomatis dapat membuat daftar ini dari kode dan menandai konflik. Menjalankannya sebagai bagian dari alur pengujian otomatis dan CI/CD membuat pelanggaran terdeteksi saat komponen ditambahkan, bukan bertahun-tahun kemudian.

Kebijakan lisensi yang sederhana tetapi tegas

Perusahaan yang memiliki produk software, atau sering memesan software kustom, sebaiknya punya kebijakan satu halaman tentang lisensi komponen.

• Daftar hijau: lisensi yang boleh dipakai tanpa persetujuan, biasanya MIT, BSD, Apache 2.0, dan sejenisnya
• Daftar kuning: lisensi yang memerlukan tinjauan sebelum dipakai, misalnya LGPL, MPL, atau lisensi dengan batasan khusus
• Daftar merah: lisensi yang tidak boleh dipakai pada produk tertentu tanpa persetujuan hukum, misalnya GPL dan AGPL pada produk yang didistribusikan atau dijalankan sebagai layanan
• Proses persetujuan: siapa yang memutuskan untuk daftar kuning dan bagaimana keputusan dicatat
• Kewajiban atribusi: di mana pemberitahuan hak cipta ditampilkan, misalnya halaman tentang atau dokumen lisensi dalam aplikasi

Kebijakan ini tidak perlu rumit. Tujuannya agar pengembang dan vendor tahu batasnya sebelum menulis kode, bukan setelah produk dipasarkan.

Risiko khusus pada era AI

Munculnya asisten penulisan kode berbasis AI menambah lapisan baru. Kode yang disarankan model dapat menyerupai potongan dari proyek open source tertentu, dan status hak cipta serta lisensi atas keluaran AI masih dalam perkembangan hukum di banyak negara. Praktik yang bijak adalah menetapkan aturan penggunaan alat tersebut, mengaktifkan pengaturan penyaringan kecocokan kode publik bila tersedia, dan tetap meninjau serta memindai kode hasil bantuan AI seperti kode lain. Pembahasan lebih luas ada pada artikel tentang pengembangan software dengan bantuan AI, peluang, risiko, dan kendali mutu.

Demikian pula model AI sendiri sering dirilis dengan lisensi khusus, termasuk batasan pemakaian komersial atau ambang jumlah pengguna. Saat memilih model, baca lisensinya sama telitinya dengan memilih pustaka.

Saat uji tuntas: apa yang biasanya ditanyakan

Investor, calon pembeli, atau pelanggan besar sering meminta bukti kebersihan kode. Pertanyaan yang lazim muncul:

• Siapa saja yang menulis kode, dan apakah semuanya terikat perjanjian pengalihan hak, termasuk freelancer dan vendor
• Apa saja komponen open source yang dipakai dan apa lisensinya
• Apakah ada komponen copyleft kuat di dalam produk yang dijual atau dijalankan sebagai layanan
• Apakah ada kode yang disalin dari sumber yang tidak jelas lisensinya
• Apakah kode sumber tersimpan di repositori yang dikuasai perusahaan, dengan riwayat perubahan yang jelas
• Apakah ada klaim atau sengketa kekayaan intelektual yang pernah terjadi

Perusahaan yang sudah memiliki daftar komponen, kebijakan lisensi, dan kontrak pengalihan hak yang rapi menjawab semuanya dalam hitungan hari. Yang tidak, sering menghabiskan berminggu-minggu menelusuri dan memperbaiki, kadang dengan biaya dan penurunan valuasi.

Langkah praktis untuk bisnis

1. Periksa kontrak vendor yang sedang berjalan: apakah klausul pengalihan hak dan penyerahan kode sumber tercantum.

2. Pastikan kode proyek tersimpan di repositori atas nama perusahaan Anda, dengan akses yang Anda kendalikan.

3. Minta daftar komponen dan lisensi dari vendor, dan jadikan bagian dari serah terima.

4. Susun kebijakan lisensi satu halaman dengan daftar hijau, kuning, dan merah.

5. Aktifkan pemindaian lisensi otomatis pada alur pengembangan.

6. Pastikan semua kontributor, termasuk freelancer, menandatangani perjanjian pengalihan hak atau lisensi yang jelas.

7. Tampilkan atribusi yang wajib di dalam aplikasi atau dokumentasi.

8. Tinjau ulang setiap tahun, atau sebelum penggalangan dana dan penjualan perusahaan.

Untuk bisnis yang berencana memindahkan proyek ke vendor lain, langkah-langkah ini juga mempermudah proses serah terima seperti yang dibahas pada artikel tentang menyelamatkan proyek software yang macet dan pindah vendor.

Pertanyaan yang sering diajukan

Apakah memakai open source membuat aplikasi kami wajib terbuka? Tidak otomatis. Lisensi permisif tidak mewajibkannya. Kewajiban membuka kode muncul terutama pada lisensi copyleft kuat dan hanya dalam kondisi tertentu, misalnya saat produk didistribusikan atau, untuk AGPL, saat dijalankan sebagai layanan jaringan.

Apakah kami otomatis memiliki kode yang dibuat vendor yang kami bayar? Tidak selalu. Kepemilikan bergantung pada kontrak dan hukum yang berlaku. Karena itu, tuliskan pengalihan hak atau lisensi secara eksplisit sebelum proyek dimulai.

Bagaimana jika kami baru sadar ada komponen bermasalah setelah rilis? Nilai seberapa besar masalahnya, lalu pilih jalur: mengganti komponen, membeli lisensi komersial bila ada, atau menyesuaikan arsitektur. Libatkan penasihat hukum. Makin awal ditemukan, makin murah memperbaikinya.

Apakah artikel ini cukup sebagai pegangan hukum? Tidak. Ini panduan umum untuk memahami isu. Keputusan dan rumusan kontrak sebaiknya ditinjau penasihat hukum yang memahami hukum kekayaan intelektual di yurisdiksi Anda.

Kesimpulan

Open source memberi akses ke teknologi kelas dunia dengan biaya rendah, tetapi setiap komponen datang dengan syarat. Kepemilikan kode kustom pun tidak bisa diasumsikan. Dengan kontrak yang jelas tentang pengalihan hak dan penyerahan kode sumber, daftar komponen beserta lisensinya, kebijakan lisensi yang sederhana, dan pemindaian otomatis, perusahaan dapat menikmati manfaat open source tanpa kejutan hukum. Biaya melakukannya di awal kecil. Biaya memperbaikinya saat uji tuntas atau sengketa jauh lebih besar.