Anda menemukan library yang pas di GitHub, memakainya di aplikasi klien, lalu berencana menjual aplikasi itu ke banyak pelanggan. Pertanyaannya: apakah Anda boleh melakukannya, dan apa kewajiban Anda? Jawabannya ada di file LICENSE yang sering dilewati.
Lisensi menentukan apa yang boleh dan tidak boleh Anda lakukan terhadap kode: memakai, mengubah, menggabungkan, mendistribusikan, dan menjual. Salah membaca lisensi bisa membuat Anda wajib membuka kode produk sendiri atau melanggar hak cipta orang lain. Artikel ini menjelaskan lisensi yang paling sering ditemui developer PHP dan Laravel, cara mengaudit dependensi proyek, serta checklist sebelum menjual produk berbasis kode orang lain.
Catatan: artikel ini adalah panduan praktis, bukan nasihat hukum. Untuk kontrak bernilai besar atau sengketa, konsultasikan dengan konsultan hukum yang memahami hak kekayaan intelektual.
Dasar: Kode Selalu Punya Pemilik
Di Indonesia, program komputer dilindungi sebagai ciptaan oleh UU Nomor 28 Tahun 2014 tentang Hak Cipta. Artinya, kode yang Anda temukan di internet tidak otomatis bebas dipakai. Lisensi adalah izin tertulis dari pemilik hak cipta yang menjelaskan syarat pemakaiannya. Kode tanpa lisensi sama sekali justru paling berisiko: secara default, Anda tidak punya izin untuk memakainya, meskipun repositorinya publik.
Dua Keluarga Besar: Permisif dan Copyleft
Lisensi open source umumnya terbagi dua. Lisensi permisif (MIT, BSD, Apache 2.0) mengizinkan hampir semua penggunaan, termasuk dalam produk tertutup, asalkan pemberitahuan hak cipta tetap disertakan. Lisensi copyleft (keluarga GPL) mensyaratkan bahwa karya turunan yang didistribusikan harus memakai lisensi yang sama dan source code-nya tersedia bagi penerima.
| Lisensi | Boleh dipakai komersial | Boleh dalam produk tertutup | Kewajiban utama |
|---|---|---|---|
| MIT | Ya | Ya | Sertakan teks lisensi dan hak cipta asli |
| BSD 2-Clause / 3-Clause | Ya | Ya | Sertakan pemberitahuan; versi 3-clause melarang memakai nama kontributor untuk promosi |
| Apache 2.0 | Ya | Ya | Sertakan lisensi dan file NOTICE, tandai file yang diubah; ada lisensi paten dari kontributor |
| LGPL | Ya | Ya, jika hanya memakai library tanpa mengubahnya | Perubahan pada library itu sendiri harus dibuka |
| GPL v2 / v3 | Ya | Tidak, bila didistribusikan | Karya turunan yang didistribusikan wajib GPL dan menyertakan source |
| AGPL v3 | Ya | Tidak, termasuk saat disajikan lewat jaringan | Pengguna yang mengakses lewat jaringan berhak atas source code |
| Komersial / proprietary | Tergantung ketentuan | Tergantung ketentuan | Sesuai perjanjian penjual: jumlah proyek, hak jual ulang, dukungan |
MIT: Paling Bebas, Tapi Tetap Ada Syarat
MIT mengizinkan Anda memakai, mengubah, menggabungkan, mempublikasikan, mendistribusikan, memberi sublisensi, dan menjual salinan kode. Syaratnya hanya satu: teks hak cipta dan izin harus disertakan di salinan kode. Laravel sendiri dirilis dengan lisensi MIT, itulah sebabnya Anda bebas membangun dan menjual aplikasi di atasnya.
Contoh teks yang wajib ikut disertakan biasanya berbentuk seperti ini (dipersingkat):
MIT License
Copyright (c) 2026 Nama Pemilik
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
...
Kesalahan umum adalah menghapus header atau file LICENSE dari library yang di-copy ke folder proyek. Biarkan tetap di sana.
GPL: Kapan Kewajibannya Berlaku?
Banyak developer salah paham bahwa memakai kode GPL berarti seluruh bisnis harus open source. Kewajiban GPL terpicu saat Anda mendistribusikan karya turunan, misalnya menjual atau membagikan file aplikasi ke pihak lain. Jika aplikasi hanya dipakai internal oleh perusahaan Anda, umumnya tidak ada kewajiban membuka kode.
Untuk aplikasi web, ada nuansa penting. GPL v2 dan v3 tidak menganggap "menyajikan aplikasi lewat server" sebagai distribusi. Karena celah inilah AGPL dibuat: jika Anda memodifikasi kode AGPL dan menjalankannya sebagai layanan yang diakses pengguna lewat jaringan, pengguna tersebut berhak meminta source code-nya. Jika Anda membangun SaaS, berhati-hatilah dengan dependensi AGPL.
Contoh: misalkan Anda menjual source code aplikasi kasir kepada klien. Jika di dalamnya ada plugin berlisensi GPL yang tergabung erat dengan kode Anda, klien berhak menerima source lengkap dengan lisensi GPL, dan mereka juga berhak membagikannya lagi. Model bisnis "jual lisensi per instalasi" jadi sulit dipertahankan.
Apache 2.0: Permisif dengan Perlindungan Paten
Apache 2.0 sebebas MIT dalam praktik, ditambah dua hal. Pertama, kontributor memberikan lisensi paten atas kontribusinya, sehingga Anda terlindungi dari klaim paten oleh kontributor yang sama. Kedua, Anda wajib menandai file yang diubah dan menyertakan file NOTICE jika ada. Banyak proyek korporat memilih lisensi ini karena kejelasan soal paten.
Lisensi Komersial dari Penjual Source Code
Source code yang dijual di marketplace biasanya memakai lisensi khusus. Poin yang perlu Anda cari di ketentuannya:
- Berapa proyek atau domain yang boleh memakai satu lisensi.
- Apakah boleh dipakai untuk proyek klien, dan apakah klien boleh menjualnya lagi.
- Apakah boleh dijadikan produk SaaS yang ditagih bulanan.
- Apakah boleh menjual ulang source code, dalam bentuk asli atau dimodifikasi.
- Apa saja lisensi pihak ketiga di dalamnya, misalnya template admin atau ikon berbayar.
Jika ketentuan tidak tertulis jelas, tanyakan dan minta jawabannya secara tertulis sebelum membayar. Panduan menilai source code secara umum ada di beli atau bikin sendiri source code.
Cara Mengaudit Lisensi Dependensi Proyek Laravel
Aplikasi Laravel modern bisa punya ratusan paket Composer dan npm. Anda tidak perlu memeriksanya satu per satu secara manual. Composer sudah menyediakan perintah bawaan:
# Daftar lisensi semua paket PHP yang terpasang
composer licenses
# Format JSON, berguna untuk diolah skrip atau CI
composer licenses --format=json > licenses-php.json
# Ringkasan lisensi paket npm (memakai paket license-checker)
npx license-checker --summary
Langkah audit yang bisa Anda ulangi:
- Jalankan perintah di atas dan simpan hasilnya bersama dokumentasi proyek.
- Cari lisensi GPL, AGPL, atau paket tanpa lisensi ("none" atau "UNKNOWN").
- Untuk setiap temuan, tentukan apakah paket itu ikut didistribusikan ke klien atau hanya dipakai saat development (dev dependency).
- Ganti paket bermasalah dengan alternatif berlisensi permisif bila produk Anda tertutup.
- Buat file
THIRD_PARTY_LICENSESyang mencantumkan nama paket, lisensi, dan pemberitahuan hak ciptanya. - Ulangi audit setiap kali menambah paket besar atau sebelum rilis versi baru.
Kesalahan yang Paling Sering Terjadi
- Memakai kode GPL dalam produk tertutup yang dijual. Perbaikan: ganti dengan library berlisensi permisif atau ubah model bisnis.
- Menghapus teks lisensi dan hak cipta asli. Ini melanggar syarat MIT, BSD, dan Apache sekaligus. Biarkan file LICENSE dan header tetap ada.
- Menganggap kode tanpa lisensi bebas dipakai. Tanpa lisensi, izin tidak ada. Hubungi pemiliknya atau cari alternatif.
- Copy-paste potongan kode dari forum tanpa mengecek ketentuannya. Banyak situs tanya-jawab memakai lisensi Creative Commons yang mensyaratkan atribusi.
- Membeli source code tanpa memastikan hak jual ulang. Baca bagian redistribusi di ketentuan lisensinya.
Checklist Sebelum Menjual Produk Berbasis Kode Orang Lain
- Lisensi setiap komponen utama sudah diketahui dan dicatat.
- Tidak ada komponen GPL/AGPL di produk tertutup yang didistribusikan.
- Semua teks lisensi dan pemberitahuan hak cipta ikut dalam paket produk.
- Ketentuan lisensi komersial mengizinkan model bisnis Anda (jual putus, SaaS, atau proyek klien).
- Aset non-kode seperti font, ikon, dan gambar juga punya lisensi yang sesuai.
- Produk Anda sendiri punya file LICENSE yang menjelaskan hak pembeli.
Lisensi juga menentukan seberapa leluasa Anda mengubah dan mengemas ulang kode. Jika rencana Anda adalah menjadikan source code sebagai layanan berlangganan, baca juga mengubah source code jadi produk SaaS agar keputusan teknis dan legalnya sejalan.
